Adventures in home data backups: Part 2 – hacking the La Cie Etherdisk Mini V1

From Part I, I now have a working backup device sitting in the closet, that is running rsync, just waiting to connect to the NAS. Time to hack the Mini.

1. The basic instructions are extremely well-written here. My model is, I think, the Etherdisk Mini V1 and these instructions are for the V2, but for the most part they work.
2. As I don’t have a full-time Linux desktop PC sitting around, I used my Knoppix 5.1 LiveCD to run Linux on the box I am using to mount and hack the Mini drive. It mounted the drive just fine, but I did have to switch the /dev/hda7 partition to be mounted read/write.
3. I extracted the tarball (with startup scripts and the rsync and dropbear binaries) located conveniently at the link above, and added the cgi-bin exploit described in the article to /www/cgi-bin/admin/. I suggest also adding it to /www/cgi-bin/public/ (see below).
4. Now a few more steps while the drive is open (will save you some headaches):
   1. I thought I was done hacking at this point. I put the drive back into the case, rebooted twice (it seemed to make some odd noises) and was able to access the exploit: http://192.168.2.34/cgi-bin/admin/exploit?ls –l
   2. Sadly, though, I was ultimately unable to get dropbear configured to use SSH keys. I tried
      http://192.168.2.34/cgi-bin/admin/exploit?dropbearkey -t dss -f /etc/dropbear/dropbear_dss_host_key
      which gave an output of
      Will output 1024 bit dss secret key to '/etc/dropbear/dropbear_dss_host_key'
Generating key, this may take a while...
Public key portion is:
ssh-dss XXXXXXXXX...long key string...XXXXXXXXXXXXXXXXX
Fingerprint: md5 XX:XX:XX:XX:...
      But I was unable to successfully use this to connect.
   3. So I was forced to use a password to log in. I figured that I could log in via SSH with my existing, usual Etherdisk Mini user (created with the factory web interface), but that fails because its shell is set to /bin/false automatically upon creation. I suppose this is to prevent you from doing what I am doing – but given no SSH daemon is normally running on the device anyway, what’s the point?
   4. Thus I needed to have a user account (with a password I knew – turns out empty passwords would get rejected) who had a shell set to /bin/sh. Since I was afraid of changing the root password for fear of bricking the drive, I tried to create new accounts as newuser/secret via
      http://192.168.2.34/cgi-bin/admin/exploit?(echo secret; echo secret!)|adduser -H -D newuser
      But that didn’t work for me since the desired password was not getting set. Didn’t work either if I tried to make it into a shell script.
   5. So in the end, I reopened the case, remounted the drive, and edited the /etc/passwd file directly. I changed, for my known user, the shell from /bin/false to /bin/sh as follows:

      root:x:0:0:root:/root:/bin/sh
bin:x:1:1:bin:/bin:/bin/sh
daemon:x:2:2:daemon:/sbin:/bin/sh
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
operator:x:11:0:operator:/var:/bin/sh
nobody:x:65534:65534:Nobody:/:/bin/sh
admin:x:500:100:LaCie Ethernet Disk mini Admin:/home:/bin/sh
visitor:x:501:100:rw,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:/home:/bin/sh
myknownuser:x:502:100:rw,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:/home:/bin/sh
      I did this for both /dev/hda7/etc and /dev/hda8/etc.

5. I install the drive back into the case, a boot up, and bingo, it worked. I can log in with WinSCP and PuTTy. I get an error upon login:

   Command 'groups'
failed with return code 127 and error message
-sh: groups: not found.

   But it works. I now have SSH access!

6. I check to make sure rsyncd is running on the Mini, and indeed it is. I log into the FreeNAS box, and it’s the moment of truth:
   
freenas:/mnt/data/docs# rsync -avzn --progress --stats myknownuser@192.168.2.34:'"/home/docs/"' .


Enter the password for the Mini user, and bam: it works. For some reason I have to connect to the Mini via IP address rather than hostname, but who cares!

Now all I need to do is write a backup shell script based on the above, set it to run on boot of the FreeNAS box, set the FreeNAS BIOS to wake up every night at 2am, and then I can forget about this whole episode.

Epilogue

I hope that some product marketing guy for a hardware company happens across this post, and sees the lengths to which a normal person will go to prevent their data from being lost again in the future. The hardware already exists on the market capable of doing what I want to do with it. As I showed, I’m willing to buy it too. So why are you unnecessarily blocking me from using it as I see fit, and instead forcing me into a free open-source alternative?