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!
Hardware Hacking Workshop is Now Live!
Registration for our three day Hardware Hacking Workshop is now live! Our first class is February 16, 2016, but other dates are available as well. Be sure to sign up while there’s still room, and enter our contest to win FREE registration!
Until then, here’s a little taste of what we’ll be doing in class:
Binwalk v2.1.1 Stable Release
Binwalk v2.1.1 has been released! If you’re still running v2.0.1, upgrading is highly recommended!
What the Ridiculous Fuck, D-Link?!
As mentioned in an update to my post on the HNAP bug in the DIR-890L, the same bug was reported earlier this year in the DIR-645, and a patch was released. D-Link has now released a patch for the DIR-890L as well.
The patches for both the DIR-645 and DIR-890L are identical, so I’ll only examine the DIR-890L here.
Although I focused on command injection in my previous post, this patch addresses multiple security bugs, all of which stem from the use of
- Use of unauthenticated user data in a call to
system (command injection) - Use of unauthenticated user data in a call to
sprintf (stack overflow) - Unauthenticated users can execute privileged HNAP actions (such as changing the admin password)
Remember, D-Link has acknowledged all of the above in their security advisories, and thus were clearly aware of all these attack vectors.
Hacking the D-Link DIR-890L
The past 6 months have been incredibly busy, and I haven’t been keeping up with D-Link’s latest shenanigans. In need of some entertainment, I went to their web page today and was greeted by this atrocity:
I think the most “insane” thing about this router is that it’s running the same buggy firmware that D-Link has been cramming in their routers for years…and the hits just keep on coming.
Reversing Belkin’s WPS Pin Algorithm
After finding D-Link’s WPS algorithm, I was curious to see which vendors might have similar algorithms, so I grabbed some Belkin firmware and started dissecting it. This particular firmware uses the SuperTask! RTOS, and in fact uses the same firmware obfuscation as seen previously on the Linksys WRT120N:
DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 Obfuscated Arcadyan firmware, signature bytes: 0x12010920, see https://github.com/devttys0/wrt120n/deobfuscator 666624 0xA2C00 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 454656 bytes
Being a known obfuscation method, binwalk was able to de-obfuscate and extract the compressed firmware image. The next step was to figure out the code’s load address in order to get a proper disassembly in IDA; if the code is disassembled with the wrong load address, absolute memory references won’t be properly resolved.
Reversing D-Link’s WPS Pin Algorithm
While perusing the latest firmware for D-Link’s DIR-810L 80211ac router, I found an interesting bit of code in
I first began examining this particular piece of code with the hopes of controlling part of the format string that is passed to
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:
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:
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.
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?
Binwalk v2.0 Released!
Binwalk v2.0.0 has (finally) been released. Grab it from the github page!