Defcon 24: Blinded By The Light

I won’t be at Defcon this year in body, but I’ll be there in spirit! I got to design the hardware used in @tb69rr’s and @bjt2n3904‘s Defcon talk, Blinded By The Light.

A walk through of the hardware design is given in the video below; if you’re interested in how the collected infrared data can be used to identify and track your phone, be sure to check out their talk at the wireless village!

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

Mucking About With SquashFS

SquashFS is an incredibly popular file system for embedded Linux devices. Unfortunately, it is also notorious for being hacked up by vendors, causing the standard SquashFS tools (i.e., unsquashfs) to fail when extracting these file systems.

While projects like the Firmware-Mod-Kit (FMK) have amassed many unsquashfs utilities to work with a wide range of SquashFS variations found in the wild, this approach has several draw backs, most notably that each individual unsquashfs tool only supports its one particular variation. If you run into a SquashFS image that is mostly compatible with a given unsquashfs tool, but has some minor modification, you can’t extract it – and worse, you probably don’t know why.

So what are these “minor modifications” that cause unsquashfs to fail?

Continue reading


I’ve previously written some examples of how to exploit MIPS stack overflows using ROP techniques. The problem is that finding suitable MIPS ROP gadgets manually can be quite tedious, so I have added a new IDA plugin – – to my github repository.

This plugin searches the code segment(s) of your IDB looking for potentially controllable jump instructions. You can then search the code surrounding these controllable jumps for useful instructions that you might need in your ROP chain.

“Controllable jumps” are defined as jumps whose destination addresses are loaded from the stack, or from other registers (typically during a stack overflow you control several, if not all, of the MIPS subroutine registers, for example).

The plugin’s searches are “dumb” in that they don’t follow code branches, but none-the-less it has proven to be quite effective. As a quick example, let’s look inside a Linux MIPS libc library for ROP gadgets that will let us call sleep(1) in order to force a cache flush.

Continue reading

Binwalk 1.2.2 Release

Binwalk 1.2.2 has just been released which introduces some useful new features:

  • Binary diffing of an arbitrary number of files
  • Heuristic compression/encryption analysis
  • Identification of zlib compression streams (implemented via a plugin)

Here are three thousand words to demonstrate these new features:

Diffing two firmware headers

Heuristic analysis of firmware with zlib compressed data

Heuristic analysis of firmware with zlib compressed data

Identifying zlib compression in an Apple firmware update

Identifying zlib compression in an Apple firmware update

Some IDA Plugins

I’ve posted a few of my IDA plugins on github. Though simple, I’ve found their functionality quite useful when reversing firmware and RISC architectures:

  • Defining ASCII strings not defined during IDA’s auto analysis
  • Defining undefined bytes in the data segment as DWORDs (allowing IDA to resolve function/jump table pointers, etc)
  • Defining undefined bytes in the code segment as code/functions
  • Finding references to any highlighted text (such as registers and immediate values) within the current function
  • Auto-naming MIPS stack variables generated by the compiler for storing registers ($s0-$s7, $gp, etc)

Hopefully others will find them useful as well.

Finding All Paths Between Two Functions in IDA

A common need that I have when reversing code is to find all possible code paths between two functions. Say for example that I’m looking for calls to dangerous functions, like sprintf, and I want to find all possible code paths that lead from my current function to sprintf. Manually going through the call graph from my starting function can often be, well, tedious:

websReadEvent call graph

Unfortunately I couldn’t find an easy way to make IDA display all code paths between two functions, and only the paths between those two functions. Normal call graphs show everything going to or from a single function, and while proximity view can be told to find a path between two nodes, it only displays the first path that it finds.

So I wrote idapathfinder, a plugin to find all code paths between two functions. This can significantly narrow down the number of paths that require investigation:

All paths between websReadEvent and sprintf

Note that the graphs generated by idapathfinder are solely dependent on IDA’s knowledge of function cross-references, so if for example you have a function that iterates over function pointers in a function table, those relationships will not be identified.

You can download idapathfinder here.