These days many vendors, like IoT vendors, use Linux running on top of ARM CPU for their embedded solutions. Some of these vendors use a tool called buildroot (https://buildroot.org) to produce a root filesystem for the device. This becomes obvious when grepping through binaries on the filesystem of certain embedded devices. At the same time many binaries useful for security research can be missing on the device. In this post I will show you how to use buildroot to add tools necessary for doing security research on an embedded device.
Imagine we have shell access to the router and while looking at binary strings we've spotted "Buildroot 2012.02" string:
strings â wget | grep -i buildroot GCC: (Buildroot 2012.02) 4.5.3
This means we can try to reproduce the build environment used by developers using discovered Buildroot version.
Download ubuntu-12.04.5-server-i386.iso from http://releases.ubuntu.com/12.04/
Why use legacy version 12.04? Buildroot 2012.02 most likely was built on that version, so less likely there will be some conflicts with newer versions of dependencies. Why 32-bit? Again, target ARM CPU binaries are 32-bit.
Create a VM and bring it up to date with:
sudo apt-get clean sudo rm -rf /var/lib/apt/lists/* sudo apt-get update sudo apt-get upgrade
Followed by installing necessary components:
sudo apt-get install build-essential libncurses5-dev bison flex gettext texinfo unzip
Download buildroot-2012.02 and unpack it:
curl -O https://buildroot.org/downloads/buildroot-2012.02.tar.gz tar -zxvf buildroot-2012.02.tar.gz cd buildroot-2012.02 make menuconfig
Select desired utilities to build under the
"Package Selection for the target": lsof, ltrace, strace, and then under
"System configuration" select
"Build gdb server for the Target" and save the config. Finally complete the compilation with:
Give it some time to download required components and do the work (may take an hour or so). Once it is done, you can grab just baked binaries from the
./output/target/ directory. For example, the gdb server is at:
How can we use them? Well first you need to upload the binaries to the embedded system. In our case, the router has USB slots so it is a matter of copying the binaries to a thumb drive and plugging it into the router. At that point you should have binaries ready to use to research the embedded device.
Here are a few examples that I found very useful:
- Trace process starts via the
/path/to/usb_drive/strace -f -s 4096 -f -e execve -p <PID>
- Remotely debug a process using Hex-Rays IDA:
/path/to/usb_drive/gdbserver --attach 192.168.1.1:9000 <PID>
Now on the IDA machine configure the "Debugger - use remote GDB debugger". Under
Debugger->Process options specify proper path to the binary on embedded system, IP and port (192.168.1.1 and 9000 in the example above). Finally use
Debugger->Attach to process menu item to actually connect via the network and debug.
lsofto get mappings of TCP/UDP ports to processes. Otherwise it can be done manually by examining
/proc/net/tcpfile and then looking for file descriptors.
On a closing note, sometimes vendors will publish source code for some parts of a device if they use some GPL'ed components. This might be another way to produce the binaries we need - we can get kernel version, some sources and so on. Sometimes it is even possible to build entire root filesystem using instructions from the vendor. Buildroot just saves time by doing a lot of the work for us.