Just added some fun 3D binary visualization features to binwalk. Read more about it here.
Visualizing AVR32 code
For various reasons, I’ve decided to move binwalk away from GoogleCode. Its new home is now at binwalk.org, and the code repository is now hosted on GitHub.
That is all.
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 – mipsrop.py – 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.
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
Identifying zlib compression in an Apple firmware update
Lest anyone think that D-Link is the only vendor who puts backdoors in their products, here’s one that can be exploited with a single UDP packet, courtesy of Tenda.
After extracting the latest firmware for Tenda’s W302R wireless router, I started looking at /bin/httpd, which turned out to be the GoAhead webserver:
Server header string in /bin/httpd
But Tenda has made a lot of special modifications themselves. Just before entering the HTTP receive loop, main calls InitMfgTask, which spawns the MfgThread function as a separate thread:
pthread_create(&var_10, 0, MfgThread, 0);
Hmmm…InitMfgTask and MfgThread? Related to manufacturing tasks perhaps? Iiiiiinteresting…
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.
All right. It’s Saturday night, I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape…let’s hack.
On a whim I downloaded firmware v1.13 for the DIR-100 revA. Binwalk quickly found and extracted a SquashFS file system, and soon I had the firmware’s web server (/bin/webs) loaded into IDA:
Strings inside /bin/webs
Based on the above strings listing, the /bin/webs binary is a modified version of thttpd which provides the administrative interface for the router. It appears to have been modified by Alphanetworks (a spin-off of D-Link). They were even thoughtful enough to prepend many of their custom function names with the string “alpha”:
Alphanetworks’ custom functions
The alpha_auth_check function sounds interesting!
I’m Vegas-bound for my Black Hat briefing, full of all the wonderful security SNAFU’s we’ve come to expect from embedded devices. If you want to see some surveillance cameras getting hacked, stop by my talk, or find me in the DEFCON wireless village if you just want to drink beers and talk shop!
I’ve recently been examining the feasibility of differentiating compressed data from encrypted data based on variations in the entropy of the data. Initial results showed some promise, but were tested against too small of a sample set to draw any hard conclusions. Since then, I’ve been experimenting with larger data sets (more files and more varied types of encryption / compression) with quite satisfactory results.
The TL;DR is that 98% of the compressed files tested were correctly identified as compressed, and 100% of the encrypted files were identified as not compressed (i.e., encrypted).
In general the entropy of compressed data shows significant variances from that of encrypted data, and can be reliably identified with very few false positives. While identification of certain compression algorithms (namely LZMA) still present some practical concerns depending on your situation, even those compressions were reliably distinguishable from encrypted data during testing due to non-random data in the file’s header structure (see ‘Analysis’ below).
What is particularly exciting, at least for me, is that compression formats which would have been otherwise unknown (e.g., files that weren’t signatured by file or binwalk) were easily identified as compressed through entropy analysis.
Registration is open for the July 2013 offering of our Embedded Device Exploitation 101 course. Only two days left for the early bird discount!