Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: Automatic Root Enabling Plugin

  1. #11
    Join Date
    May 2010
    Location
    In the land of make believe.
    Posts
    501

    Default

    Its not an initialization script. Explaining the underlying cause requires a deep understanding of how embedded device work with Linux. Without going into it too deep, the Javelin's boot-loader loads the Linux root partition into RAM from a compressed section of its internal flash storage every time it boots. Any changes written to the root partition are stored in ram, and vanish when the Javelin reboots.

    The file /etc/shadow is where the root password, and other user accounts are stored. This file is overwritten every time the Javelin boots.

    I have another concept I am working on to make the Javelin accessible without erasing the root pass, by replacing the shadow file with another copy that has your root password stored in an encrypted format. Not quite there yet, as I am working on my YouTube download plugin that Patriot's peripherals manager is keen on getting.

    Editing the rootfs in flash is not a good idea, since even the tiniest mistake will brick the javelin to the point where most people will not be able to recover it.
    I AM NOT A PATRIOT MEMORY EMPLOYEE.

    But they have, on occasion, bribed me with hardware.



    I am happy to help, but don't PM me. Post a thread in the appropriate forum so others may benefit and offer assistance.
    Your lack of planning is not an emergency on my part.

  2. #12

    Default

    Thanks for the info. I was thinking that, in spite of the embedded nature of the OS, that it still wrote some details to the hard drive or flash which were persistent but, given you can remove and replace the drives at will, that does seem to be a shaky proposition in a NAS.

    It's interesting that the Mvix Ultio I have (also using embedded Busybox) *does* save the changed password from reboot to reboot. Not sure where it saves but it definitely *is* saved causing me to assume the Javelin worked in a similar way (thus my previous comments.)

  3. #13
    Join Date
    May 2010
    Location
    In the land of make believe.
    Posts
    501

    Default

    The method you describe, where the mtds are mounted directly, is sometimes used in devices that don't always expect to have a hard drive available. This is generally considered to be less stable, as users mistakes can damage the OS enough that the device wont boot or loses functionality. I prefer it though, as it makes hacking MUUUCH easier
    I AM NOT A PATRIOT MEMORY EMPLOYEE.

    But they have, on occasion, bribed me with hardware.



    I am happy to help, but don't PM me. Post a thread in the appropriate forum so others may benefit and offer assistance.
    Your lack of planning is not an emergency on my part.

  4. #14
    Join Date
    Jan 2012
    Posts
    21

    Default

    Hacking this box is probably similar to working with routers, we probably have to list the nvram settings, change them and commit the changes.
    Im sure all this information is available somewere... And there is probably some sort of brick failsafe built in there too that we can use to restore via TFTP.

    BadIntention, what kind of linux has patriot got running in there? Wasnt it Busybox based? http://www.busybox.net/
    Last edited by thecrazy; 05-31-2012 at 04:28 PM.

  5. #15
    Join Date
    Sep 2012
    Posts
    2

    Default

    Is there a version of the plug-in compatible with the .v2 firmware?

  6. #16
    Join Date
    Sep 2012
    Posts
    1

    Default

    [QUOTE=BadIntentions;42837]
    The file /etc/shadow is where the root password, and other user accounts are stored. This file is overwritten every time the Javelin boots.

    Hi there,

    I'm wondering if you happen to have a copy of the original /etc/shadow file (non blank root pw) so that we could just run a passwd crack against it.

  7. #17
    Join Date
    Sep 2012
    Posts
    2

    Default

    Picked up a Javelin yesterday and tried to install the rooter.ppg on .v2. It fails with the error: "SyntaxError: Unexpected end of input"

  8. #18
    Join Date
    Sep 2012
    Posts
    4

    Default

    Quote Originally Posted by BadIntentions View Post
    I finally managed to hack apart the plugin format,
    Can you share what you learned about the plugin format?

  9. #19
    Join Date
    Aug 2012
    Posts
    1

    Default

    I have 2 drives Volume 1 (RAID 0 x 1) and Volume 2 (RAID 0 x 1). The Volume 1 drive crashed and that's where the default shares are stored. When I removed Volume 1 and restarted the NAS, the default shares (PUBLIC, PICTURES, MUSIC, etc) were auto-created in Volume 2.

    Somehow, my Rooter plug-in stopped working. Does the plug-in make use of one of the default shares/folders and expects to find it in Volume 1?

    The rooter has been an awesome timesaver when I've had to move files across drives or folders within the NAS and would love to have it working again.

    UPDATE: I think I solved my own problem. When Volume 1 broke down, I rebooted with only Volume 2 present. The NAS sees that the default shares are not there and creates the folders in Volume 2. When I re-install rooter, it's added to VOLUME2/PLUGINAPP. But I guess rooter has parts in its code that will expect files in VOLUME2/PLUGINAPP/Rooter

    So what I did was shutdown the NAS, unplug Drive2 and turn on the NAS. It re-creates the default shares in VOLUME1. I shutdown again, plug back Drive2 (with VOLUME2) and I'm now able to install and use the rooter plug-in
    Last edited by one19; 03-17-2013 at 11:50 PM.

  10. #20
    Join Date
    Sep 2014
    Posts
    4

    Default

    is there a way to get root.ppg + Optware.ppg installed onto the Gauntlet Node? trying to activate BusyBox sudo on the node, but no luck so far.

    R

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •