Hacking the SanDisk Connect Wireless Media Drive

by ook

So I bought this cool little device called a SanDisk Connect Wireless Media Drive.

It's a cute little thing, weighing in at 76g, and nicely palm-sized at 6.5 cm square by 1.35 cm deep.  It's got solid construction and, depending on the configuration, can produce a 50m Wi-Fi field of up to 320 GB (the 64 GB model with a 256 GB SD card, which is the market maximum at time of writing), accessible to any Android or iOS phone or tablet.

The device creates a Wi-Fi network of your desired configuration, and can even connect to an existing Wi-Fi network.  You connect your phone to it, or to a common network, and you're good to go.  Unfortunately, this little hockey-puck of awesome has a couple of major flaws: first, it's got no SMB server, nor any standard NAS protocol to speak of.  Second, it doesn't support MTP - so if you've got it hardwired into a computer, you can't access it from your phone.  This obviously won't do.

Assuming this is a Linux embedded something, I decided to portscan the little beast.  What was open:

• 21  (FTP)
• 23  (Telnet)
• 79  (Finger)
• 80  (HTTP)
• 113  (AUTH)
• 513  (LOGIN)
• 514  (CMD)

FTP responded immediately to the admin credentials from the Media Drive app for my phone - so it's easy to access that way.  Telnet also worked, giving an option for doing other interesting stuff.

Let's have a look at the system:

$ uname -a Linux Media_Drive 2.6.35.3-899-g9b1a262 #18 PREEMPT Tue May 28 14:14:33 CST 2013 armv7l GNU/Linux

$ cat /proc/cpuinfo Processor : ARMv7 Processor rev 5 (v7l) BogoMIPS : 799.53 Features : swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x41 CPU architecture : 7 CPU variant : 0x2 CPU part : 0xc08 CPU revision : 5 Hardware : Freescale MX50 Platform - Nimbus@QSI(WG7311-2A) Ver: 1.1.8 Revision : 50011 Serial : 0000000000000000

$ cat /proc/meminfo MemTotal: 125496 kB MemFree: 12152 kB Buffers: 1816 kB Cached: 66120 kB SwapCached: 604 kB Active: 27196 kB Inactive: 74268 kB Active(anon): 14664 kB Inactive(anon): 19140 kB Active(file): 12532 kB Inactive(file): 55128 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 125496 kB LowFree: 12152 kB SwapTotal: 151720 kB SwapFree: 150976 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 33096 kB Mapped: 7324 kB Shmem: 276 kB Slab: 6592 kB SReclaimable: 2168 kB SUnreclaim: 4424 kB KernelStack: 1376 kB PageTables: 1008 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 214468 kB Committed_AS: 899888 kB VmallocTotal: 1761280 kB VmallocUsed: 1152 kB VmallocChunk: 1756732 kB

$ cat /proc/partitions major minor #blocks name 179 0 61071360 mmcblk0 179 1 4096 mmcblk0p1 179 2 262144 mmcblk0p2 179 3 204800 mmcblk0p3 179 4 60584960 mmcblk0p4 179 8 125058048 mmcblk1 179 9 125041664 mmcblk1p1

So it's based on an ARMv7-L, specifically a Freescale MX50.  That means a Cortex-A8 running at up to 800 MHz.

Next step is to gain root.  The shadow file actually contained a password hash for root, so I went ahead and brute-forced it with about five minutes of good ol' John the Ripper's time: sqn1351

Telnetting in as root succeeded.  Once I had root, I was able to fix the SSH daemon configuration:

# chmod go-r /etc/ssh/ssh_host_* # ln -s /etc/rc.d/init.d/services/sshd /etc/rc.d/init.d/services/S99sshd

I was also able to set up a little SSH/SCP love:

$ ssh-keygen -t rsa $ mv .ssh/id_rsa.pub .ssh/authorized_keys

I then copied the key into the FTP area for use with PuTTY and WinSCP (removing it later):

# cp .ssh/id_rsa /var/ftp

I wanted the device to have a hostname on the network, too, so I added the appropriate section to /etc/dhclient.conf (wlan0 is the AP, wlan1 is the client):

interface "wlan0" { send host-name "puck"; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, SIP; require subnet-mask, domain-name-servers; } interface "wlan1" { send host-name "puck"; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, SIP; require subnet-mask, domain-name-servers; }

Now that you have working SSH, you can use Dokan (Windows) or SSHFS (Linux) to mount the Wireless Media Drive to your PC.

However, neither of these stream well with the limited bandwidth of the device.  Fortunately, XMBC handles all that nicely.

I also keep a small array of BTSync nodes, managing a gig or two of personal stuff... so I figured, hey, why not one more?

I downloaded the latest ARM build of BTSync (symlinking it to /sbin), and added the following init.d script:

#!/bin/sh if [ ! -x /sbin/btsync ] then if [ ! -f /sbin/btsync ]; then echo "BTSync not found" else echo "BTSync permissions not set" fi exit 0 fi if [ ! -f /root/.sync/config.json ]; then echo "Please create a config.json in /root/.sync/config.json" echo "See http://btsync.s3-website-us-east-1.amazonaws.com/BitTorrentSyncUserGuide.pdf" fi if [ "$1" = "stop" -o "$1" = "restart" ] then echo "Stopping the BTSync server..." killall btsync fi if [ "$1" = "start" -o "$1" = "restart" ] then echo "Starting the BTSync server..." /sbin/btsync --config /root/.sync/config.json fi

In sum, the SanDisk Connect Wireless Media Drive is a neat little headless Linux box.

If you could construct an ARM toolchain for yourself, you could use it for all sorts of personal server applications: Samba, household BitTorrent, household remote control.  Since it has two 802.11n devices, you could probably make a relay out of it.

If you need a tiny mobile media server, this is certainly a good and flexible option for the time being.  Now if you'll excuse me, I'm going to try and get a JRE running on it; I work as a programmer on a Java-based XML CMS for publishers, so obviously, I'd like to try to get it running on everything!