Verbatim Mediashare Wireless Part 1

So today I was casually browsing the internet when I came upon something interesting. A special! The Verbatim Mediashare Wireless. OneDayOnly was selling them for R199 each, which is around US$14.

The device is essentially a wireless access point, with a 3000mAh battery and a USB port and SD card slot. The intended use of the device is to share the content of a connected device (SD card, USB flash drive, external hard disk) with a device connected over wifi (phone, tablet, iPad) in order to watch movies, back-up your pictures, share files etc.

While that’s all fine and dandy, I don’t need that functionality personally. But, having briefly looked at the firmware update file from Verbatim’s site, I managed to confirm that it was fit for my alternative purposes. This is what I found (before having received the device)

Inside the firmware update, inside a gzip file, which was inside a zip file, was a file called initrdup (presumably initrd upgrade?)

$ file initrdup
initrdup: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=121b56b7-4f7c-4243-96ec-5618255c1e33

Great. So it’s just an ext2 image (this already tells us something about the device’s filesystem. We simply mount this image and can read the contents of the filesystem.

$ mkdir fs
$ sudo mount -o loop initrdup fs/
$

No complaints, so we’re in business. You can do this yourself to see the full contents of the filesystem (it’s not a full filesystem – we’ll get to that shortly) but I dug around a bit and was interested in a few files.

Firstly, running file on a binary should hint as to the kind of processor inside the device

$ file busybox
busybox: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped

This is a great start. MIPS is, for the most part, supported by OpenWRT (the architecture is, we’re just not sure which CPU we’re dealing with yet). OpenWRT also uses uClibc, which means that we should be able to pull binaries from the OpenWRT repo and run them on this device.

Secondly, I found some nice things in /firmware.

-rw-r--r-- 1 root root 125K Jul 31 2013 bootloader
-rw-r--r-- 1 root root 47 Jul 31 2013 firmware.conf
-rw-r--r-- 1 root root 1.4M Jul 31 2013 kernel
-rwxr-xr-x 1 root root 4.6M Jul 31 2013 rootfs

firmware.conf contained nothing useful, just 3 lines which give the build of their firmware and the device name “MediaShare”

bootloader was more interesting

$ file bootloader
bootloader: u-boot legacy uImage, SPI Flash Image, Linux/MIPS, Standalone Program (Not compressed), 127892 bytes, Thu Apr 25 03:25:22 2013, Load Address: 0x80200000, Entry Point: 0x80200000, Header CRC: 0xAF04CAC4, Data CRC: 0x3AD2F955

$ binwalk bootloader

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0xAF04CAC4, created: 2013-04-25 01:25:22, image size: 127892 bytes, Data Address: 0x80200000, Entry Point: 0x80200000, data CRC: 0x3AD2F955, OS: Linux, CPU: MIPS, image type: Standalone Program, compression type: none, image name: "SPI Flash Image"
104528 0x19850 U-Boot version string, "U-Boot 1.1.3 (Apr 25 2013 - 09:25:18)"
105008 0x19A30 CRC32 polynomial table, little endian

So the device uses uBoot, which is great, especially if we can find a serial port. Next we have kernel:

$ file kernel
kernel: u-boot legacy uImage, Linux Kernel Image, Linux/MIPS, OS Kernel Image (lzma), 1439550 bytes, Wed Jul 3 05:05:34 2013, Load Address: 0x80000000, Entry Point: 0x8043F000, Header CRC: 0xC9DE2237, Data CRC: 0x1C0EB1EF
$ binwalk kernel

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0xC9DE2237, created: 2013-07-03 03:05:34, image size: 1439550 bytes, Data Address: 0x80000000, Entry Point: 0x8043F000, data CRC: 0x1C0EB1EF, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
64 0x40 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 4599929 bytes

As hinted at by its larger size, and name, this file contains the actual kernel. Extracting the file and running binwalk against the output confirmed this (the name of the output file was 40, as that was the hex offset of the LZMA compressed data):

$ binwalk 40

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
3502148 0x357044 Linux kernel version "2.6.21 (hsq@localhost.localdomain) (gcc version 3.4.2) #258 Wed Jul 3 11:05:22 CST 2013"
3503152 0x357430 CRC32 polynomial table, little endian
3529200 0x35D9F0 CRC32 polynomial table, little endian
3540384 0x3605A0 SHA256 hash constants, little endian
3757172 0x395474 Unix path: /usr/gnemul/irix/
3759772 0x395E9C Unix path: /usr/lib/libc.so.1
3761468 0x39653C Unix path: /dev/vc/0
3800588 0x39FE0C Unix path: /var/run/netswitch.pid
3806752 0x3A1620 Unix path: /var/run/udhcpc.pid
3891576 0x3B6178 Unix path: /etc/Wireless/RT2860AP/RT2860AP.dat
3894008 0x3B6AF8 Unix path: /usr/bin/killall
3897924 0x3B7A44 Unix path: /etc/Wireless/RT2860AP/e2p.bin
3910084 0x3BA9C4 XML document, version: "1.0"
3986835 0x3CD593 Neighborly text, "NeighborSolicitsts"
3986859 0x3CD5AB Neighborly text, "NeighborAdvertisementsmp6OutDestUnreachs"
3987060 0x3CD674 Neighborly text, "NeighborSolicitsirects"
3987088 0x3CD690 Neighborly text, "NeighborAdvertisementssponses"
3988615 0x3CDC87 Neighborly text, "neighbor %.2x%.2x.%.2x:%.2x:%.2x:%.2x:%.2x:%.2x lost on port %d(%s)(%s)"
4356336 0x4278F0 CRC32 polynomial table, little endian
4599808 0x463000 LZMA compressed data, properties: 0x5D, dictionary size: 1048576 bytes, uncompressed size: 512 bytes

So now we know that the device runs a 2.6.21 linux kernel. There are also clues as to the chipset used (RT2860 for wireless). The next file gives us some even more conclusive information: rootfs

This is the biggest file in the directory, and again, the name gives away the purpose of the file. Running file just tells us that it’s data, but binwalk reveals that it’s a squashfs image:

$ binwalk rootfs

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Squashfs filesystem, little endian, non-standard signature, version 3.0, size: 4764598 bytes, 968 inodes, blocksize: 65536 bytes, created: 2013-07-31 07:34:00

The sasquatch utility was able to extract the file, after I moved it out of firmware/ (remember, we’re still inside the mounted filesystem)

I managed to lose the file I found last time, but it was some kind of build config file. I’ll update this post when I find it. Either way, the device has a RT5350 SoC which is supported by OpenWRT. I believe it has 32MB RAM and 16MB flash. (partly based on /etc/versioninfo which includes the string kernel=5350/kernel-rt5350-32M-2013-07-03-11-04)

I sent /etc/passwd to a friend of mine who ran the hashes and came back with a root password of ‘20080826’
I will have to verify this when I receive the device, but the preliminary research looks promising 🙂