Hacking Your Portable Linux Server

To start unlocking the multifaceted abilities of this wonderful device, you first need to obtain console access. To be clear, this voids the device's warranty, as Western Digital obviously is not in the business of supporting Linux servers in all their possible configurations and software options, and that kind of flexibility is precisely what we are after. Bear in mind that although these steps were researched and verified conscientiously, the author and Linux Journal accept no liability for rendering your device inoperable as a result of these instructions—proceed at your own risk.

The WD Hacking community was spawned by Martin Hinner's creation of a backdoor process that uses the drive's built-in firmware update process to reset the device's root password, spawn the SSH dæmon and generate the SSH host keys. Just like everyone else, let's head to Martin's Web page (see Resources) and follow the instructions found there. In effect, all you have to do is navigate to a URL on your device. The URL includes a GET parameter for the upgrade script to run. The parameter references a script on Martin's site, but this script, rather than performing an upgrade, generates SSH keys, clears the root password and starts the SSH dæmon.

Once the “upgrade” is initiated, you will not receive feedback on the Web page that it has completed, and you probably should not do anything to your device in this interval, lest you rouse those bricking fairies. Simply wait three minutes, then start attempting to log in via SSH with the user (not administrator and not root) account you created earlier in the Shared Storage Manager. As soon as you see the SSH dæmon respond with a login prompt, you will know the break-in succeeded. If you set up your user account correctly, you will be able to log in. If you are having trouble logging in, take care that your user name is spelled in CAPS (ssh USER@ipaddress), as you will note that the user management Web interface creates all accounts in that fashion. One more troubleshooting tip: the latest firmware revisions actually output a message that the update has failed, although the SSH dæmon has, in fact, been spawned successfully and is ready for your connection.

Once successfully logged in to your device, you can escalate your privileges by switching user to root (su -) as the superuser password is now blank. You will need to carry out a few tasks—the first one of which is adding the SSH dæmon to the default startup list to ensure that your newly gained access lasts past your next reboot. Head to /etc/inittab, and add the following after the system startup section:

# Start a few good daemons
::sysinit:/usr/sbin/sshd

After making your changes, make sure they have been written to disk by doing a “sync”, and fix a few details of your user account, such as granting yourself a home directory and possibly a lowercase user name. Do all your /etc/passwd and /etc/shadow housekeeping before rebooting to verify that the SSH dæmon is now spawning by default and that your user accounts are working as intended.

You're past the most difficult point; now you can proceed to explore the system and tweak it to your heart's content. Unless you plan to use the MioNet service, some recommend switching its dæmon off, as it is a Java process that weighs on both CPU and RAM. As the MioNet service enables wide-area file sharing, I elected to turn off the service, but to do so cleanly, in case I decided I needed the functionality after all. Edit /etc/init.d/post_network_start.sh, and comment out line 17 of the script:

    $SCRIPTS_PATH/crond.sh start
#    $SCRIPTS_PATH/mionet.sh start
    touch $POST_NETWORK_STARTED_FILE

This stops the dæmon from being spawned automatically at boot, but if you need its services, you can start it up from the Shared Storage Manager interface (General Setup→WD Anywhere Access) as needed, giving you the best of both worlds.

The system is built around a 2.6.17.14 kernel, with BusyBox centralizing many of the command-line tools. There are no man pages, but the system is an otherwise reasonable minimal Linux instance, including the majority of the common management levers (ps, top, free, ifconfig, wget and so on) as well as a development toolchain with all the trimmings (gcc 3.4.2, gmake and so on), enabling you to build any software that may be missing. The mounts show a good picture of the device:

# df -h
Filesystem   Size  Used Avail Use% Mounted on
rootfs       2.8G  277M  2.4G  11% /
/dev/root    2.8G  277M  2.4G  11% /
/dev/md3     950M   19M  884M   3% /var
/dev/md4     455G  199M  455G   1% /shares/internal

It also is worth mentioning that on the dual-drive unit, the system partitions are mirrored by default, regardless of the RAID state of the share space:

# cat /proc/mdstat
Personalities : [linear] [raid1]
md1 : active raid1 sdb1[1] sda1[0]
     2939776 blocks [2/2] [UU]

md2 : active raid1 sdb2[1] sda2[0]
     104320 blocks [2/2] [UU]

md3 : active raid1 sdb3[1] sda3[0]
     987904 blocks [2/2] [UU]

md4 : active linear sdb4[1] sda4[0]
     1945407104 blocks 64k rounding

unused devices: <none>

Another important detail is the behavior of the power button: regulated by a small dæmon also controlling the LEDs, it will bring the device down performing a proper reboot if pressed for two seconds, or it will cause a soft shutdown if held for four seconds—train yourself to recognize the light schemes by looking at the device when you issue software reboots (the device has a hard reset button on the back were it to become seriously wedged). Besides looking wicked cool, the LED rings visualize both disk activity and available disk space, as well as RAID failures, joining form and function.