Binary Breakthrough

Extracting Secrets from Linux Binaries

In embedded Linux systems, the filesystem is often accessible to an attacker, even if you didn’t realize it. This article will first demonstrate how sensitive files can be recovered from public update images, then demonstrate how those images could also just be read out from the hardware itself.

It’s an important topic because it often gets to the heart of the most straightforward embedded system attacks. This is especially the case as more systems include embedded Linux, which often makes it easier to recover binaries. In fact, in this column, I’ll show you how exactly you can quickly demonstrate the ease with which you can recover these binaries yourself.

Binary Logic

In cybersecurity, it’s common to talk about “binaries,” which normally means getting a copy of the executable code or image of a flash storage device. Of course, everything in embedded systems is binary, so you might find it a bit confusing to talk about “binaries” like they are a special item. But for cybersecurity, getting a “binary” typically means getting access to executables or data that can be further reverse-engineered to find vulnerabilities in a system.

On a small embedded system, the binary would just be a copy of the code running on the microcontroller. On those systems, you are mostly limited by how well the copy protection of the microcontroller is implemented. I’ve talked in previous articles about, for example, the STM32F1 and LPC1114 copy protection, and how you might break that (Circuit Cellar 384 and 338, respectively) [1][2].

But on larger systems that run embedded Linux or Android, there may easily be hundreds of application binaries. But on these systems, an attacker is often interested in actually getting an image of the system disk. This is interesting for a few reasons:

1. it tells them lots of good information, such as versions of standard applications you are using that might have security flaws if they weren’t updated;
2. it may have secrets such as passwords or encryption keys present;
3. it may be possible for an attacker to extract the binary with very little effort.

In this article, I’m going to demonstrate how an attacker could quickly check on the contents of an image (binary), and also show you a few different techniques for getting the image itself.

Armchair Reverse Engineering

When I talk about hardware hacking, you probably start thinking about soldering irons and probes on a PCB. But it turns out that for lots of devices, you can get access to these binaries using nothing more than a web browser. These binaries are often provided as part of update files for devices, which is the first example I’ll show you. We’ll look at an old (2013 vintage) router. These devices often run Linux, and because they protect the network itself, they can be an interesting target.

If you want to follow along, head over to D-Link’s support web page [3], and search for the model number DSR-150. You might also try a device you’ve got around; the process will be similar. On that page, you’ll find you can select an older firmware. I used the oldest available (1.08), as often older firmware has the most interesting left-over data.

A screenshot of the support website showing that selection is given in Figure 1. Note that sometimes these devices get retired and moved to the legacy website, or old firmware is removed. Most of the devices will follow the procedure I’m about to show you here, so don’t fret if things have changed by the time you read this.

Hopefully, that will download a ZIP file that, when extracted, contains a BIN file. We’ll use a tool named Binwalk to explore it further, so let’s take a look at that.

I Binwalk the Line

Binwalk is an open-source tool started in 2010 by Craig Heffner. It can automatically analyze a binary to detect various structures, and even perform automatic actions such as extracting an embedded filesystem. You can find the easy installation instructions for Binwalk on the Binwalk GitHub repository [4], or on many Linux systems you can install a “recent enough” version with a simple sudo apt install Binwalk.

This will work on Windows Subsystem for Linux (WSL), which will allow anyone with a Windows computer to play along quickly. While I encourage you to install the latest from GitHub to get all the recent changes, the WSL repository is recent enough for the automatic extraction to work with our images.

To run Binwalk and extract any detected filesystems, use the command:

binwalk -e FILENAME.bin

Most of the D-Link firmware update files will contain an image with a known filesystem, and it will spit some new files out in a directory called:

_FILENAME.extracted

An example of the command line and output for the DSR-150 binary is given in Listing 1. Again, you might get outputs with a different version of the binary or a different device. Some filesystems may need additional external tools installed; see the Binwalk repository [4]

Just Looking, Thanks

In this case, we’ll now take a look in the

_DSR-150_xxx.extracted\squashfs-root

directory that was created by the tool (where xxx is a longer string that reflects the exact binary version). In the following filesystem references, I’ll use / to refer to the above root directory.

LISTING 1
An example of the Binwalk output showing detected filesystems.

$ binwalk -e DSR-150_A2_FW1.08B29_WW
DECIMAL	HEXADECIMAL	DESCRIPTION--------------------------------------------------------------------------------512	0x200	Linux kernel ARM boot executable zImage (little-endian)13357	0x342	gzip compressed data, maximum compression, from Unix, last modified: 2013-06-05 09:43:515242880	0x500000      Squashfs filesystem, little endian, version 4.0, compression:gzip, size: 22472353 bytes, 2796 inodes, blocksize: 131072 bytes, created: 2013-06-05 09:43:5827717632	0x1A6F000     Squashfs filesystem, little endian, version 4.0, compression:gzip, size: 847 bytes, 16 inodes, blocksize: 131072 bytes, created: 2013-06-05 09:43:58

Depending on the device you are using, you may find some interesting files and data. A common initial target is to see if the /etc/passwd or /etc/shadow files are present. On older devices, you may find /etc/shadow is a regular file. This is the case on the DIR-665 firmware binary, for example.

On the DSR-150, we don’t find that, however. But you can quickly see some other interesting resources, such as a private key located in /sslvpn/var.default/cert, and details of the firmware update header format in /bin/upgrade.sh (along with a few other interesting binaries in that directory).

To be clear, these aren’t vulnerabilities by themselves—for example, the defaults should be changed, just as the default passwords on these routers should be changed. But they provide a lot of interesting information, and in some cases you find secret keys or passwords in the filesystem that do represent a security vulnerability.

Showing you how easy it is to go from a “raw” binary image to extracted files was part of this article. The second part is to show you how attackers could get this binary image directly from your embedded system.

Reading Flash Chips

For a memory device in an embedded system, there are four likely technologies you’ll use: SPI flash, micro-SD card, eMMC, or parallel flash. I’ll briefly talk about how an image could be extracted from each of those.

The first, an SPI flash chip, is most often holding only a bootloader and not the full Linux system. Because these devices are relatively slow, it’s unlikely that it gets mounted for read/write access as the root Linux filesystem. But on some systems the SPI flash chip may still be the main filesystem and is mirrored to RAM, for example, since the device isn’t designed to store much (or any) persistent data.

Reading an SPI flash chip is done with any SPI interface device such as a Bus Pirate, an FTDI chip, or a Raspberry Pi. The open-source flashrom software is commonly used with one of those interfaces to perform the actual SPI flash read commands. But lots of other solutions exist. For example, I’m partial to using the (commercial) Segger J-Link devices with their J-Flash utility. Either way, the end result is a dump of the SPI flash that can be run through Binwalk.

The second, a micro-SD card, doesn’t require any real effort! Here we can simply image it using standard tools such as dd on Linux to create an exact copy of the contents for us to analyze. The ease of access with a micro-SD card means you probably already thought about ensuring there are no sensitive secrets stored on it, because it’s clear an attacker can easily poke around the filesystem.

An eMMC chip is another common flash memory technology for embedded Linux systems. Unlike the micro-SD card, you might think that it’s a little more secure, since an attacker can’t just plug this into their host system. But the reality is that it is, in fact, almost just that easy. The eMMC devices can be thought of as a soldered down SD card, and they actually implement even a legacy SD card protocol that doesn’t need all the pins.

A good overview of this is in the talk “Hacking Hardware with a $10 SD Card Reader” [5]. It means you can solder an SD card interposer to the lines, and read out the eMMC of an embedded system with an SD card reader. An example of me doing that on an embedded system is shown in Figure 2.

In some systems you’d need to desolder the eMMC to perform the attack, but if the pads are exposed, it may be possible to do this in-circuit. In my example from Figure 2 there was no need to desolder the device, as the device used a “submodule” including the eMMC chip, and it conveniently had castellated pads to which I could solder fine-pitch headers, making my life very easy.

The final device you might find is a parallel flash chip. This is the most complicated option, and the one that was part of some of my most recent work I alluded to earlier. These parallel chips have non-standard pinouts, and non-standard formats, and may use additional layers of error-correcting codes, so it’s not always as simple as reading out the “raw” binary. However, none of these are true security mechanisms, and just means a little more effort than usual.

An example of a recent device I was looking at is in Figure 3, which shows both the board with a chip removed and a simple carrier board I made using “dead-bug” soldering. This particular device is a hybrid LPDDR + parallel flash chip, so it also contains many unused pins, as I don’t need to power up (or interface with) the LPDDR side.

The ongoing work is building the actual interface boards. But once that interface exists, the same sort of binary read-out as above should yield some interesting results. In this case, I need to find the root password of the embedded Linux system, as I already have a serial console but it blocks me from logging in.

Securing Flash Chips

If it’s so easy to read out most flash memory chips, what can you do? The answer here is to select a device with memory encryption. Ideally, the device contains a per-device encryption key inside the device, which is used to encrypt/decrypt the memory. This means reading out the flash chip won’t lead to any interesting results. Linux-based filesystem encryption can be helpful here, which requires minimal hardware support.

Even with that, watch out for where you might be distributing unencrypted files. Firmware updates may still be plaintext or only lightly obfuscated, and if those firmware updates contain an entire copy of the root filesystem, there was little point in using the fancy memory encryption!

Finally, an interesting talk at RECON 2023 entitled “Ice Ice Baby: Coppin’ RAM With DIY Cryo-Mechanical Robot” [6] showed that it’s even possible to dump DDR memory, albeit with a rather complex system. Enabling encryption for your DDR memory is another step you can take, but this requires dedicated hardware support. Examples of devices that support that feature include the Microchip SAMA5D4.

Hopefully, this article showed you how easily one can read out sensitive data from unencrypted flash memory interfaces, and how you can take some steps to prevent an attacker from using these techniques on your own embedded systems. Future articles will explore the parallel memory interface I showed in Figure 3 in more detail. 

REFERENCES
[1] Colin O’Flynn, “Revisiting Code Readout Protection Claims.” Circuit Cellar 384, July 2022.
[2] Colin O’Flynn, “Recreating Code Protection Bypass: An LPC MCU Attack.” Circuit Cellar 338, September 2018.
[3] D-Link Support: https://support.dlink.com
[4] Binwalk repository on GitHub: https://github.com/ReFirmLabs/binwalk
[5] Hacking Hardware with a $10 SD Card Reader. https://www.blackhat.com/docs/us-17/wednesday/us-17-Etemadieh-Hacking-Hardware-With-A-$10-SD-Card-Reader.pdf
[6] Ice Ice Baby: Coppin’ RAM With DIY Cryo-Mechanical Robot. https://cfp.recon.cx/2023/talk/HCJHBW/

Code and Supporting Files

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JANUARY 2024 #402 – Get a PDF of the issue

Sponsor this Article