Today we’re going to take a look at an interesting little device, the Linksys WMB54G wireless music bridge.
This is a pretty specialized device, so it’s likely a fairly minimalistic system. Even the administrative interface is small and simple:
WMB54G Administrative Interface
The Linksys support page doesn’t have any firmware updates available, so let’s take a peek at the hardware.
Opening the case reveals an expectedly limited system, with just 2MB of flash, 8MB of RAM and a small processor covered up by a heat sink:
There are two connectors on the right hand side of the board, labelled J5 and J9. J5 appears to be a JTAG connector, while J9 shows promise of being a serial port:
J5 and J9 Connectors
Being able to emulate embedded applications in Qemu is incredibly useful, but not without pitfalls. Probably the most common issue that I’ve run into are binaries that try to read configuration data from NVRAM; since the binary is running in Qemu and not on the target device, there is obviously no NVRAM to read from.
Embedded applications typically interface with NVRAM through a shared library. The library in turn interfaces with the MTD partition that contains the device’s current configuration settings. Many programs will fail to run properly without the NVRAM configuration data, requiring us to intercept the NVRAM library calls and return valid data in order to properly execute the application in Qemu.
Here’s a Web server extracted from a firmware update image that refuses to start under Qemu:
It looks like httpd can’t start because it doesn’t know what IP address to bind to. The IP can’t be set via a command line argument, so it must be getting this data from somewhere else. Let’s fire up IDA and get cracking!
Qemu usually does a great job emulating embedded Linux applications, but as with anything you will occasionally run into bugs. While attempting to debug an embedded application in Qemu the other day, I ran into the following error:
eve@eve:~/firmware$ sudo chroot . ./qemu-mips bin/ls
bin/ls: Invalid ELF image for this architecture
This error is usually indicative of using the wrong endian emulator, but I knew that the target binary was big endian MIPS. The file utility began to shed some light on the issue:
eve@eve:~/firmware$ file bin/busybox
bin/busybox: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), corrupted section header size
Hmmm, a corrupted section header? Let’s take a closer look at the binary.
For a while now I’ve been looking for an easy way to interface with external SPI and I2C devices over USB in a manner that can be easily integrated into future projects as well as used in a simple stand-alone system.
Although there are many existing SPI/I2C interface solutions, most of them are microcontroller based and connect to the PC though a USB to serial converter. This works fine, but I wanted something with a bit more speed while also remaining simple, cheap, and readily available.
After some searching, the FTDI FT-2232 family of chips seemed to fit the bill nicely. Although they are more commonly used to interface with JTAG devices, the FT-2232’s Multi-Protocol Synchronous Serial Engine (MPSSE) also supports the SPI and I2C protocols, clock rates of up to 30MHz, and a full-speed USB interface. Development boards are also cheap – the UM232H is $20 from DigiKey or Mouser in single quantities.
I’ve written libmpsse, a Linux wrapper library around libftdi that provides an easy to use API for interfacing with SPI and I2C devices using C and Python.
So how does this relate to hacking embedded systems you ask? Let’s take a look…
So far in this series we’ve found that we can log in to our target TEW-654TR router by either retrieving the plain text administrator credentials via TFTP, or through SQL injection in the login page. But the administrative web interface is just too limited – we want a root shell!
We’ll be doing a lot of disassembly and debugging, so having IDA Pro Advanced is recommended. But for those of you who don’t have access to IDA, I’ve included lots of screenshots and an HTML disassembly listing courtesy of IDAnchor.
In part 2 of this series we found a SQL injection vulnerability using static analysis. However, it is often advantageous to debug a target application, a capability that we’ll need when working with more complex exploits later on.
In this segment we won’t be discovering any new vulnerabilities, but instead we will focus on configuring and using our debugging environment. For this we will be using Qemu and the IDA Pro debugger. If you don’t have IDA you can use insight/ddd/gdb instead, but in my experience IDA is far superior when it comes to embedded debugging.
In part 1 we used the TEW-654TR’s TFTP service to retrieve the administrative credentials to our target system.
But what if we didn’t have access to the TFTP service? Many embedded devices don’t have a TFTP service, or there may be a firewall between us and the target that blocks traffic to UDP port 69. In this case, we’ll have to take a closer look at the web application running on the target.
So far our tutorials have focused on extracting file systems, kernels and code from firmware images. Once we have a firmware image dissected into something we can work with, the next step is to analyze it for vulnerabilities.
Our target is going to be the Trendnet TEW-654TR. We’ll be examining many different security holes in this device, but for part 1 we will focus on gaining initial access given only a login page and nothing more. We will assume that we do not have physical access to the target device, nor to any other device for testing or analysis.
If you don’t already have them, you will need to install binwalk and the firmware mod kit.
Let’s get started!
Although released under the GPL, DD-WRT is notoriously difficult to build from source. If you want to customize your DD-WRT installation, it is usually easier to extract files from the firmware image, change what you need, and then re-construct the image.
One exception here is the Web GUI. The DD-WRT Web pages (*.asp, *.htm, *.gif, *.css) in each firmware image are protected in order to prevent modification. Being able to customize the Web interface can be advantageous for those wishing to add compatibility with mobile/uncommon browsers, change themes, add links, etc.
And, despite claims to the contrary, that’s exactly what we’ll be doing.
DD-WRT Sporting the Hack-A-Day Logo
SquashFS is a widely used file system in embedded Linux devices; in fact, it is probably one of the most commonly used file systems among Linux based consumer products.
While many devices use standard SquashFS file systems that can be extracted using the unsquashfs tools provided in the firmware mod kit, you will inevitably encounter some implementations that are…special.
Perhaps the vendor simply changed the SquashFS signature, or maybe they modified something in the de/compression code, but for one reason or another, none of the unsquashfs tools will work.
The D-Link DIR-320 is special.