• CommentTimeMay 12th 2012 edited

    I found my way over at the Digital Summer event a couple of days ago where Kingston were showing off their latest wares. I had a Wi-Drive thrust into my hands to have a play. My curiousity got the best of me and I wasted a good working day playing around / hacking with it. (Invoice is in the post Maggie...)

    The Device

    Fairly pretty to look at, it's light and about the same size as a phone. I can't help but feel they would have been better off making it fatter and shorter, but its curved edges means it fits into pockets nicely.

    So, plug it in by USB and it's a 32GB flash drive with middling performance. Unplug it and switch it on and it becomes a wireless hotspot for accessing your content. You can then connect to this using up to three devices. It's designed with phones/tablets in mind with an Android/iPhone app freely available on the market that makes copying to/from the device as well as streaming fairly painless.

    Using a fixed IP address, it doesn't have to do any scanning and is up and running quickly.

    Looking at some other reviews – for watching videos (which would be my intended use) it will last around 4 hours. Not bad considering the weight.

    If you're on a PC it's limited to the web interface only which is read only. You can however configure the devices SSID/Encyption etc.

    Obviously if you connect to the Wi-Drive's AP, you lose your Wi-Fi connection to the Internet. Unfortunately, Android isn't smart enough to realise this WiFi has no gateway and route through to 3G – your phone just becomes unusable for anything that requires net access.

    Kingston's solution to this is the ability to connect to a secondary wireless network and piggy back this through the connection. This is using a virtual bridging on a single wireless interface and from what I've seen on DD-WRT this has a negative effect on throughput.

    Unfortunately for me, I couldn't get this to work using my fairly standard WPA2 setup. It went as far as getting an IP address and no further. It does mention in the manual that it doesn't support mixed encryption modes, but I'm not using these. Strange.


    So the device itself works as intended – I happily played some videos at the gym on my tablet, which is what I thought it might be handy for. The question is, why would someone buy this?

    The obvious initial answer is to iPhone/iPad users who can't expand storage through microSD. For myself, my Xoom has a microSD slot, as does my mobile phone – so expansion is easy.

    However with the Wi-Drive being a separate device – it does mean I can share a single resource of videos across the two devices.

    Another alternative to this, would be, for instance, to store all your media content on one of the devices (probably my tablet) and set up a DLNA server instead.

    I believe the MiFI dongles have microSD slots, which allow you to share data (as well as provide a Internet connection) across WiFi.

    The Problems

    Other than the fact I couldn't get the wireless passthrough to work, the first obvious problem is that you can't charge it and use it at the same time. As soon as you plug it in via USB, the wireless switches off and it becomes a dumb drive.

    Being on a PC, it's frustrating that there's no way for me to transfer files to it wirelessly. I have to use the USB cable, and this disconnects my other devices.

    The annoying thing is, is that from what I can tell – the whole system is built upon using WebDAV on port 8888. WebDAV is an open standard supported on PC/Mac/Linux – if Kingston simply gave us the login credentials we could do exactly what we wanted.

    Digging into the code, the web interface is also bound specifically to the IP of the device on its own AP, rather than all interfaces. This means that when using the wireless passthrough, even though it has an IP address on my internal network – I can't access the web interface.

    Hacking It

    So I had a great time fiddling around with this device. There are a couple of different ways you can hack it. Unfortunately, for the life of me – I tried forever to get a Telnet daemon up and running but kept failing. Perhaps the information I provide here can help someone else as I couldn't see any information on the net from other people trying.


    The device is using embedded Linux (no surprise there) – a form of Debian running Kernel. It uses a Realtek RTL8196C MIPS processor. From what I can see it's using the Realtek SDK version 2.4-r4188. It shows 58MB of memory.

    There a 4MB block of flash memory that contains the root file system. This is split into two, mtd0 for “boot+cfg+linux” and mtd1 for “root fs”.

    The 32GB drive has a small, read only portion that comes up as a CD-ROM when you insert the device. This contains Apache and all the web files related to the web interface.

    Running Commands

    The Apache install has server side includes with exec enabled. This means, you can put any command into a .shtml file and it will run these, from *anywhere* on your drive. I believe Apache is running as root.

    For example, this copies the entire rootfs onto the FAT drive so you can analyse it later.

    <!--#exec cmd="cp /* . -R" ?

    It was slow progress with this approach as I had to plug the device back into my PC to edit the scripts and then wait the 60 seconds it takes to reboot. In hind sight, I should have edited the files on my tablet and copied them over using the app.

    The version of busybox compiled and installed does not have the Telnet daemon. I found a pre-compiled static binary and tried this. I still had no luck and had no error messages either, so it was tricky to diagnose.

    This method did however allow me to get a good look at how the system works.

    Replacing the root filesystem

    Using the above method, I was able to make a backup of the flash memory block. Unfortunately, I had a lot of trouble mounting this on Ubuntu – with consistent errors about my kernel being too new or not being able to read the super block. Other sites suggested it was an issue with little / big endian JFFS2 partitions. Frankly, by this stage I felt enough was enough – but this may well be the best/simplest approach to getting a terminal up and running.

    The web interface has a built in ability to flash the firmware, which I believe could be taken advantage of if someone can tweak the root filesystem.

    Replacing the CDROM partition

    There are two kinds of firmware update for this device – the root filesystem (a true firmware update) and then the CD partition. The current CD updater on the Kingston website updates this partition to have the latest web interface – it also contains the Apache binaries and configuration.

    I'm not sure how it updates the CD partition (/dev/sr0), so I opted to manipulate the updater instead.

    On the CD partition there is a script called kdi.sh that is called during init. This launches Apache and does a few other last minute things. This is an ideal place to inject some custom code such as launching Telnet. I unfortunately had just the same luck trying to get Busybox to work.

    The simplest way to add instructions in here, is to load the entire installer up in a hex editor, where the script can be easily edited. Then simply run the updater to flash this on to the device.

    However, if you want to make more drastic changes (add/remove files) – there is another method.

    The filesystem is essentially an ISO 9660 Joliet .ISO file that is included in the installer as a resource. First, extract the contents of the installer to a folder using something like RAR or 7-Zip. Then make all your desired changes to the file system.

    When you're ready, select your files and output them to an ISO. A simple tool for Windows is IsoRecorder.

    Then you need to open the updater in a piece of software called Resource Hacker. The ISO is stored in BIN 135. Replace this resource with your newly created ISO and this will be flashed to your device when the utility is run.


    So what went wrong? With two effective methods of executing root level code – why couldn't I get Telnet running? After reading up, the only thing that made sense is that there was no terminal running for Telnet to bind to. /dev/pts existed, by /dev/ptmx did not.

    It was at this point, after spending most of my Friday and Saturday fiddling, that my head ache was suggesting I was a little out of my depth and should retreat in defeat and open my research up to the eyes of more experienced embedded Linux people.


    I'm quite interested to see what could be done with this device once hacked. Quite a few applications run around my mind – but without getting a terminal up, I'm some what beaten.

    As far as the device goes – assuming that is my own wireless network causing issues with the wireless pass through, it seems a good solution to the expansion concern. I don't think it's something I would have purchased – but that's no reflection on the product, but merely that is solves a problem I simply don't have!

    • CommentAuthornilz
    • CommentTimeMay 30th 2012

    The source code is available for download from their site here

    • CommentAuthorrvdm
    • CommentTimeJun 3rd 2012

    I managed to get quite a bit further. I now have an SSH daemon running on the wi-drive, and have full root access. The web interface is not running as root - the shtml trick gives you nobody:root access. I'm now looking for the firmware updater (not the cd-rom updater) that you refer to in your post. Do you still have a copy or link ? I'll write up a little post on how to get full access, but would like to include a patched rootfs.

    • CommentAuthorjash08
    • CommentTimeJun 17th 2012 edited

    remember, early last year, thinking to myself,
    "Self, it would be totally awesome if they made an external hard drive that was battery operated and could connect to a WiFi network.
    No more USB cables!...

    well, thanks for the info.....goodluck! :)


    @rvdm: Could you post the howto? Firmware updater doesn't seem to be on the site. So you'd have to dump mtd1 to the storage.
    I'm wondering if it'd be possible to run samba on it.

    • CommentAuthorjeisom
    • CommentTimeDec 6th 2012

    running samba should be fine. it has 32Megs of ram, as much as some routers with NAS support, I personally added linux ext2 support to my cd image. Allows files larger than 4GBs. I am running lighttpd on it now and it starts up to sharing files in about half the time. Personally I don't think Apache 2 is cut out for such a embedded device. But that is what they decided to use. you may notice that is has port 8888 open that will ask for a password from a browser. Just a configuration system for the Chipset that it is based on btw.

Copyright Andrew Miller (Spode), 2008