Search Results for: VxWorks

Reverse Engineering VxWorks Firmware: WRT54Gv8

Lately I’ve been working on taking apart some VxWorks firmware images. Unfortunately, I could find precious little information available on the subject, so today we’ll be extracting the VxWorks kernel and application code from the WRT54Gv8 firmware image and analyzing them in IDA Pro.

The WRT54G series infamously switched from Linux to VxWorks with the release of the WRT54Gv5. Because VxWorks is a proprietary RTOS, it is a less familiar environment than a Linux based system. Even once you identify the different sections of the firmware image, there usually isn’t a standard file system full of standard ELF executables that can be automatically analyzed by a disassembler.

The overall process for reversing this firmware is pretty straight forward:

  1. Identify and extract actual executable code from the firmware image
  2. Identify the loading address for the executable code
  3. Load the executable code into IDA Pro at the appropriate loading address
  4. Augment IDA’s auto analysis with manual/scripted analysis

Debugging with JTAG or observing debug messages over a serial port can probably be substituted for steps #1 and #2, but since I don’t have any VxWorks WRT54G routers, this will be a purely firmware based analysis.

Continue reading

A Code Signature Plugin for IDA

When reversing embedded code, it is often the case that completely different devices are built around a common code base, either due to code re-use by the vendor, or through the use of third-party software; this is especially true of devices running the same Real Time Operating System.

For example, I have two different routers, manufactured by two different vendors, and released about four years apart. Both devices run VxWorks, but the firmware for the older device included a symbol table, making it trivial to identify most of the original function names:

VxWorks Symbol Table

VxWorks Symbol Table

The older device with the symbol table is running VxWorks 5.5, while the newer device (with no symbol table) runs VxWorks 5.5.1, so they are pretty close in terms of their OS version. However, even simple functions contain a very different sequence of instructions when compared between the two firmwares:

strcpy from the VxWorks 5.5 firmware

strcpy from the VxWorks 5.5 firmware

strcpy from the VxWorks 5.5.1 firmware

strcpy from the VxWorks 5.5.1 firmware

Of course, binary variations can be the result of any number of things, including differences in the compiler version and changes to the build options.

Despite this, it would still be quite useful to take the known symbol names from the older device, particularly those of standard and common subroutines, and apply them to the newer device in order to facilitate the reversing of higher level functionality.

Continue reading

Speaking SPI & I2C With The FT-2232

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…

Continue reading

Exploiting Embedded Systems – Part 1

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!

Continue reading

Mystery File System

Last week Jim posted a comment asking about reverse engineering the firmware for some Chinese routers with the intention of extracting the Web files and translating them to English.

Although I usually work with Linux based firmware, this sounded interesting so I thought I’d investigate. Although I wasn’t able to completely recover the Web files, the process of reversing a file system format seemed like a good subject for discussion.

Continue reading