07 Aug, 2019

Intro to Hardware Hacking - Dumping your First Firmware

by Alex Useche

IoT security is an exciting field that opens up the doors to a lot of interesting research. When you dive into the rabbit hole of hardware security, you’ll encounter a whole array of engaging and varied challenges: Bluetooth sniffing, Software-Defined Radio, ARM exploitation, reverse engineering, and a whole lot of hardware tinkering and breaking. However, knowing where to start can be confusing and difficult, so we will help you get started by showing you how to dump firmware from IoT device.

One of the basic steps when pentesting an IoT device is to analyze the firmware of the device. There are several reasons for doing this, but mainly:

  • Firmware can contain sensitive information, such as encryption keys, API keys, and other hardcoded secrets.
  • We could modify the firmware and flash the device with our patched code to modify interesting logic in the chip.

Often, you can find the firmware for various flash chips online by performing simple Google searches; however, the firmware may not always be available online. This is when things get interesting, as you have to manually extract the firmware from the device by opening it and connecting to the flash chip.

The steps for extracting firmware from an IoT device are relatively simple, but there are a few things along the way that can seem confusing, particularly if you haven’t worked with hardware devices all that much. In any case, even if you are not conducting an assessment, extracting and analyzing the firmware of a device can be a lot of fun. There is something about it that feels very cyberpunk’ish. Is that cliche? Absolutely, but c’mon, all security people have a secret love for all things cyberpunk and 1995 hacker stereotypes. In this blog post, I will guide through the process of dumping firmware from a flash chip. I will not assume that you have any previous experience with hardware.

Locating the flash chip in IoT Devices

In this post, we are going to extract the firmware from an SP009 Sricam IP camera. The Sricam IP camera has a number of vulnerabilities that make it an ideal device for learning IoT exploitation. Note that the same steps we are about to follow would apply to almost any other device.

The first step is to open the device. If you are planning on doing a lot of IoT security research, I’d suggest getting a nice screwdriver kit. Then, with your shiny new screwdriver kit in hand (or the one screwdriver you found in your garage) open the device and examine the different chips on the board. This is what the IP camera looks like when opened up:


Device firmware lives in flash memory chips, which often have eight pins connecting it to the board. They are also relatively small. With those clues alone, we know that the flash memory chip must be the one on the bottom side of the picture above. To make sure we do a thorough analysis, though, let’s identify the model and serial number for each chip.

  • MXIC Chip, part MX25L12835F. We can find info about it here
  • Grain Media chip, part GM8135S-QC.
  • A MediaTek chip, part MT7601UN.

After some quick Googling, we determine that the chip with part number labeled MX25L12835F is the flash chip containing the firmware for the device. The documentation also indicates that this is an SPI (Serial Peripheral Interface) chip. SPI is nothing more than a protocol for communications in an embedded system. SPI allows for fast, synchronous, serial communications between different components on a board, and each pin serves a different purpose for SPI communications. You can learn a lot about SPI and how it works here.

The next step is to figure out what each pin on the chip does. Since we have identified the component number for the firmware chip, we can search for the datasheet for the chip online (linked above). On page 7, we see a diagram for the chip. We want to look for the following pins so that we can connect to the chip and dump the firmware:

  • CS: Chip Select
  • MISO: Master In Slave Out (data output)
  • GND: Ground
  • MOSI: Master Out Slave In (data input)
  • Vcc: Voltage common collector, for powering the chip.
  • SCLK Serial Clock Input

From looking at the datasheet, we identify the following pin numbers:

CS   ----- PIN #1
MISO ----- PIN #2
GND  ----- PIN #4
MOSI ----- PIN #5
SCLK ----- PIN #6
Vcc  ----- PIN #8

Dumping the firmware

Alright, now the question is: how do we know which pin is which in our device? Well, see that dot on the top left corner of the chip diagram? Look for that same dot on the chip to identify pin #1. In the previous picture, you can see the dot in the top-left corner.

To dump the firmware, we need a microcontroller that can communicate with SPI chips. We have a few options, including:

In this case, we will use the Attify Badge.

To make our job more comfortable, we can use a SOIC (Small Outline Integrated Circuit) clip to make the connections from the flash chip to our microcontroller. A SOIC clip looks like this:


The way you use a SOIC clip is relatively simple: look for the red cable to identify the end that should make contact with pin #1 of the SPI chip. We then hook jumper cables on the other end of the SOIC clip according to the pin numbering we determined above. Each cable, in turn, is connected to our microcontroller using the following SPI configuration:

Badge        IP Camera
SCK  <--------> SCLK
MISO <--------> SI/SO (MOSI)
MOSI <--------> SO/SI (MISO)
CS   <--------> CS
GND  <--------> GND
3.3V <--------> Vcc

The documentation for whatever microcontrollers you are using should indicate which pins you can use for SPI communications. In this case, we determine the above connections by locating the pin layout for the Attify Badge. Your connections should look something like this:


Ignore the cables soldered to the chip on the top of the camera. Those are connected to a UART chip, which we will cover in a future post.

I must issue a warning regarding the Vcc pin. You connect the Vcc pin to your board if, and only if, you decide not to connect your IP Camera (or any other device you may be pentesting for that matter) to a power source (most likely via a USB cable). If you are connecting your camera to power during this process, you MUST NOT connect the Vcc pin, as you will be supplying the chip with too much power, which could in turn damage the board or USB ports on your computer.

Now, I won’t lie and tell you that the SOIC clip makes everything easy. It is not as easy as hooking the clip on the chip and assume that all the connections are made. You will have to carefully look at the contact pads on the clip and make sure each pad is touching the right pin on the chip. This can be a pain, and if you don’t have an exact hand, you could damage the pins. While this can seem annoying at first, this is also what I enjoy about working with hardware: it requires a type of patience (physical patience perhaps?) that you don’t get to exercise when working with software. Just keep at it and have fun.

If you become frustrated with the SOIC clip, you could try using alligator clips instead, which I have found to be very useful when working with tiny pins. The same connections using alligator clips look like this:

connected with alligator clips

Ok, let’s get back to work. Next, connect your microcontroller to a computer and make sure that your device is detected. I like using a Linux VM where I have all my tools for IoT exploitation. Type the following to make sure your microcontroller is listed:

$ ls /dev/ttyUSB*

Now we will need to use spiflash.py to dump the firmware. Clone this repo and navigate to libmpsse/src/examples. Next, to dump the firmware from the device, run the following:

$ sudo python spiflash.py -s 15000000 -r firmware.bin

Note that if you don’t use sudo, the tool may not be able to detect the USB device. The -s flag indicates the size of the data that we want to dump. The documentation for the chip may also indicate the size of the firmware. In this case, we are using a sufficiently large size to assure we get the entire firmware.

Next, assure that something was dumped from the chip:

$ strings firmware.bin

If you didn’t have your connections set up correctly, the above would output nothing. If you do see a list of garbled characters, then we can move on to the next step.

Next, we will extract the firmware from our resulting binary using binwalk. Download binwalk and run the following command to extract the firmware:

$ binwalk -e test.bin

The output from the above may look something like this:


Now navigate to the created folder.

$ cd _test.bin.extracted/squash-fs  

You may not have a squash-fs folder. In that case, the firmware was probably not extracted correctly, possibly due to a connection issue. Check your connections and run spiflash.py again. I had to run that a few times before I was able to extract the firmware correctly.

As you can see, now you have access to the entire file system from the dumped firmware in the squash-fs directory. SquashFS is a compressed file system commonly used in embedded systems.

file system

Now it is up to you as to what you want to do with it. Explore scripts, look for secret strings, etc. You can even modify files and write back to the flash chip using spiflash.py -w.

If that looked like something you’d enjoy doing you can use the list below to find all the materials you need to dump firmware from flash chips:

You can often find the SP009 Sricam IP camera on eBay, but you may also want to practice with old routers as well. The best way to get started is to open devices and start exploring and researching.

Another way to interact with firmware is via JTAG pin, which we will cover in a different blog post. We will continue writing about IoT security and diving deeper into this exciting field in future posts.