In Part 1 of this hardware hacking series, we showed some basic examples of hardware hacking and explained why being able to extract the contents of flash memories is so important during vulnerability research activities. We also describe the main tools needed for hardware hacking activities and the most effective techniques to identify the flash memory among the components of a printed circuit board (PCB). Finally, the previous blog explored different techniques to obtain the correct pinout of an SPI memory chip.
Continuing on that topic, this blog covers how to dump the memory contents for two different kinds of memory packages, WSON and SOP/SOIC.
Understanding the Interface Signals of the SPI Protocol
Most of the flash memory chips for embedded devices leverage the Serial Peripheral Interface (SPI) as a communication port between the microprocessor or microcontroller and the memory itself. The interface was developed by Motorola in the mid-1980s and has become a standard. It is primarily used for interfacing memories with microprocessors but also for Liquid Digital Displays (LCDs) and many other applications.
SPI devices communicate in full-duplex, with a master-slave architecture where, usually, there is only one master and one or more slaves; the master, also called controller, generates frames for reading and writing. The selected slave, identified with the Chip Select (CS) signal, responds to master requests.
Usually, SPI interfaces present eight signals:
- SCLK: Serial Clock (output from master)
- MOSI: Master Out Slave In (data output from master)
- MISO: Master In Slave Out (data output from slave)
- CS /SS: Chip/Slave Select (output from master)
- VDD: Voltage Drain Drain (to power on the slave device)
- GND: Ground Reference
- HOLD: Hold Signal (for multiple slaves’ communications)
- WP: Write Protect
The WP and the Hold signals are worth a deeper investigation about their meaning and behavior.
The Write Protect signal is used to avoid unintended writing on the memory. If the WP signal is active, the memory content cannot be altered, while if it is not active, the memory can be written or erased. Even if this signal seems to control only the writing/erasing operations, it can also be used to protect the memory from unauthorized reading, so during dumping operations this signal needs to be inactive.
The HOLD signal is used with multiple slave communications. Together with the CS/SS signal, the HOLD signal can be used by the master controller to hold the reading/writing operations except for communications from one slave.
During dumping procedures, this signal must be kept non-active.
Wiring up the Memory Chips for Data Extraction
To establish proper communication between the memory and our PC, we need to use a bus interface (see Part 1).
Figure 1 shows the correct wiring between an SPI flash memory and a bus interface. It is important to notice that the MISO and MOSI connections are flipped; in fact, the Master Out becomes the input of the slave (Slave Input) and vice versa.
Furthermore, the WP and the HOLD signal can be connected to both 3V3 (3.3 volts power output, logical 1) or GND (ground reference, logical 0). The datasheet of our target memory helps establish the proper wiring setup of these two signals: in fact, if the WP signal is active high, it must be connected to GND, while if it is active low, it must be connected to 3V3. The same approach is also valid for the HOLD signal.
To connect the bus interface to the memory chip, both grabbers and SOP/SOIC test clips can be used. Figure 2a shows the usage of a SOIC/SOP test clip, while Figure 2b shows the option of common grabbers.
Reading the Flash ROM Data
Everything is ready to start dumping our target memory contents. To do that, software running on our PC is required to correctly handle the SPI communication with the memory. In this blog we will present Flashrom, a software that is able to identify, read, write, verify and erase flash memories. It is an open-source project running on every Unix-based system and supporting a very high number of memory chips.
To check if our target memory is supported by Flashrom, we can look for the chip model in the Flashrom supported hardware list.
For this example, we will consider the Annke N48PBB Network Video Recorder (NVR), which embeds a Macronix MXIC MX25L12835F SPI flash memory.
As we can see in Figure 3, the MX25L12835F is supported by Flashrom, so, we can start reading its content.
To correctly read the contents of flash memory, Flashrom needs two important parameters: the bus interface ID and the target memory model.
The programmer ID parameter depends on which bus interface is adopted. In this case we used the Attify Badge, which is based on a FTDI chip communicating with the memory through SPI protocol. In the Flashrom manual, the programmer name for this kind of bus interfaces is ft2232_spi:type=232H.
The target memory ID, instead, is the model of the flash memory that can be found in the Flashrom list of supported hardware. From the supported hardware list, we identified the name of the chip we are reading from: MX25L12835F/MX25L12845E/MX25L12865E.
The option that enables the setting of the programmer ID is -p, while the memory ID is -c.
The complete Flashrom command will then be:
flashrom -p ft2232_spi:type=232H -c MX25L12835F/MX25L12845E/MX25L12865E -r image.bin
The -r option, on the other hand, tells Flashrom to perform a reading operation.
The output of this command will eventually be a dump of the entire content of the flash chip, which will be saved in file image.bin.
A Sample Analysis of a Verkada IP Surveillance Camera
We have just seen how to dump the content of an SPI memory supported by Flashrom. So, how do we deal with memory chips that are not supported by Flashrom?
Let’s consider a Verkada D40 IP surveillance camera, whose PCB is shown in Figure 4. After an exhaustive analysis of the PCB, we can identify a HeYangTek HYF2GQ4UAACAE flash memory.
A deeper investigation into this memory chip highlights three problems:
- The memory has a WSON memory package, so its pins are not easily reachable;
- No manuals or datasheets are available;
- The memory is not officially supported by Flashrom.
To overcome these problems, we first unsoldered the memory chip from the PCB, soldered a small jumper wire for each pad of the memory and tried to read its content with Flashrom, as we saw before. Since there is not a memory ID for that chip, we tried some common SPI chip IDs, but were not able to read the contents.
At this point, the only way to dump the contents of our target memory is to adopt a dedicated programmer.
By searching the memory model on the internet, we were able to find that the BeeProg2C by Elnec is compatible with our target chip; so, we bought one, together with a socket adapter for WSON memory packages.
Figure 6a shows the programmer with the socket adapter plugged into. The HeYangTek memory was put into the socket (Figure 6b). Finally, we were able to read its contents, through the BeeProg2C dedicated software (Figure 6c).
Summary
Vulnerability research is primarily a study of the software, functions, and systems of complex network-connected devices. Analysis of the device firmware is critical to understand how the device behaves, how it responds to various inputs and how it can affect other peripheral systems. But firmware extraction can be very challenging without proper tools and techniques since this is not a skill required by the average device consumer.
Researchers also need to have some detective skills in cases where firmware chip pin-outs are not well documented and the contents of the firmware are encrypted. In this two-part blog series, we have laid out some techniques for performing these operations on a few widely-used classes of memory chips using some readily available hardware and software tools. Other designs may require slightly different approaches, using these specific instructions as a guideline.
We look forward to your comments on your own firmware extraction techniques and any additional tools that may contribute to the success of the research community.
Note: While Nozomi Networks does not use ‘master’ and ‘slave’ terminology, this blog uses the precise nomenclature of the SPI protocol.
