Reverse Engineering MIPS Binaries Had Me Frowning...Then I Tried BOTOX!

3-minute read

Hello.

This is an introduction post about the tools I’m using to hunt for binary exploitations in IoT devices, and why they’re helpful when debugging exploits. I’d like to introduce two common environmental features of IoT devices: the MIPS architecture and .cgi binaries.

A Little About MIPS

When assessing the firmware of IOT devices, it’s very common to run into the Microprocessor without Interlocked Pipelined Stages (MIPS) architecture. It’s popular because it’s useful for simple, fast hardware, and it’s instruction set is reduced, so it’s easy to learn.

Unfortunately, because it’s not a common instruction set for personal computers, it can be a real pain to reverse engineer binaries that are built for it. Emulation is convenient for running the binary, but even if we use tools like qemu, this only aids us in emulating specific services. We can still run into some problems like:

  • The firmware binary commonly expects to be run as root
  • The firmeware binary expects to be run in relation to the root directory of the firmware, not of your host OS, when it goes looking for the libraries of code it depends on in order to run
  • The qemu emulator will also be looking for libraries that probably only exist on an Intel machine (for this reason, we’ll want to use a statically linked version of qemu)

Qemu allows us a lot of flexibility for emulation because it allows us as reverse engineers to redirect and pipe data into the application it runs, set environement variables for the binary, and even set a debugging port to step through the code of the binary being run (more on this in a bit).

But you’ll quickly find several problems when emulating the binary with an emulator like qemu such as:

  • Missing files
  • Broken symlinks
  • Unsupported network features

While it can be helpful to attempt to recreate these files and features manually, it can also be an enormous, time-consuming pain. For the exercise that follows after this article, I’ve settled on running the MIPS binaries while chrooted from their firmware, all while on a MIPS virtual machine. You can find several VMs here.

Unfortunately, even after switching to a VM, we encounter separate problems with…

.cgi Binaries

CGI in this context stands for “Common Gateway Interface”. It’s a type of executable that can be called from a web server that allows the server to execute a separate program. Usually this is done on IOT devices and switches to process user requests.

Unfortunately these requests and their associated processes are tough to debug because of their ephemeral nature. If I want to test one of these executables for a buffer overflow attack, that usually requires me to attach a debugger to the process so I can easily view it’s memory while conducting research. Unfortunately, the process executes so quickly that’s it’s gone before I can attach a debugger.

So I decided to start using botox.

The botox program injects a SIGSTOP into the executable, pausing it long enough for me to attach a debugger to research the process properly. It’s an incredibly useful tool to research memory-related attacks, and I’m going to be using it extensively in the next post where I debug a return-to-libc style attack on the buf the D-Link AC750.

Goodbye.