I recently bought a NAS enclosure with 1TB of storage for my humble home LAN. While I eventually managed to identify the manufacturer as a firm called ‘Sumvision’, the packaging didn’t make this obvious and upon opening it up I got that distinct and familiar feeling of ‘you’re on your own from here’. Of course, none of this came as a surprise (given the price I paid) and I was pleasantly surprised to find a fresh set of firmware available on the website (version 2.4.4-Jul 8 2008). What did upset me, though, was the awful performance I experienced when using it over my wireless connection. A short Google later it became apparent that this is a common problem with NAS devices, caused by the typically higher packet-loss experienced on wireless connections. Briefly put, SAMBA (and NFS) transmission units often default to 8192 bytes or more, whereas IPv4 networks without the relatively new jumbo frame support will fragment anything above the 1500-or-so-byte MTU. The suggested fix, for SAMBA devices such as mine, is to tweak this value in the server’s smb.conf:

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=1024 SO_SNDBUF=1024

Alas, I found no obvious way to modify these values in the enclosure’s web interface. Furthermore, extracting the hard-drive and mounting it locally proved that it is used for content storage only - the OS sits on a ROM, away from the user’s grubby fingers. And so I was out of luck and was at the point of giving up, until curiosity got the better of me. Taking a look at the ‘shares’ page of the admin interface it was pretty clear that this thing was running a Unix-based OS (disclosing local paths such as ‘/mnt/C/Media/Music’), and if their implementation was as flaky as their design there may be another way in.

So I tried what any hacker would have done faced with this input field, and tried to traverse the device-local path using some ‘../’s.

Now I won’t pretend that it was big, clever or original, but to my surprise it worked. Browsing to ‘\nas\Root’ from my computer landed me right in the device’s root, with admin read/write privileges. For those wondering, the OS is BusyBox.

And the rest is history. A couple of words of warning to anybody planning on doing the same:

• In order to access this root share, the device obviously needs to boot and mount successfully. As such I wouldn’t be the slightest bit surprised if any undue alterations to the OS or its configuration result in the device being rendered permanently unusable. I never did brick mine and so haven’t confirmed this, but be very careful what you touch.

• /config/smb.conf is presumably kept open at all times, and so you’ll likely have trouble saving to it. I found that saving as a different file and then renaming them around works fine. Be aware that there is very little excess space to play with (I suspect it’s mounted as a ramdrive).

• The smb.conf, at least, seems quite volatile, in that any changes via the web interface result in the [global] parameters being reset to their defaults. I have observed the alterations to persist across reboots but couldn’t offer a comprehensive list of actions that result in it being wiped clean, so don’t be surprised if you find that your fixes disappear when you’re not looking.