Vulnerability research on IoT and OT devices is one of the primary activities at Nozomi Networks Labs. This unique focus allows us to make a valuable cybersecurity contribution to the industry. Our main goal is to increase device security in critical OT and IoT infrastructure, such as power grids, manufacturing plants, transportation systems, smart cities, health care, etc. To be successful in this challenge, we focus research on both hardware and software components, trying to discover vulnerabilities that could give a hacker an attack vector to disrupt real-time processes.
One of the most challenging activities for cybersecurity research is getting access to the underlying file system in OT devices to perform a complete analysis of device operations and potential attack vectors. Device firmware is not usually publicly available on the internet and, even when provided by vendors, is often compressed with proprietary algorithms, or even encrypted. This blog describes techniques for extracting the firmware directly from the hardware, and reading the flash content, a critical skill in a structured research team. This information may also help IT and OT engineers obtain security information that helps protect network devices.
In part one of this two-part blog series, we describe the basic concepts behind the flash memory firmware dump, giving practical examples that cover a large variety of use-cases and processors.
Types of Flash Memory Packaging
Every electronic component installed on a PCB has a hardware interface that allows the soldering of that component to the PCB. In this blog, we will present the three most common package designs used for PCB mounted memory devices.
The Small Outline Integrated Circuit (SOIC) package (Figure 1a) is the most common, especially in small, embedded devices. The standard form is a flat rectangular body, with leads extending from two sides. The leads are formed in a gull wing shape to allow solid footing during assembly to a PCB. This kind of package simplifies the process of firmware dumping, since the pins can be probed easily by grabbing them with a tool, called grabbers (shown later in the blog).
The Very-very-thin Small-Outline No-lead (WSON) package (Figure 1b) is slightly thinner compared to the SOIC design. Instead of having the leads extending from the rectangle, it has some conductive pads. For a vulnerability researcher, this package presents some difficulty in reading the memory content, since we cannot use the grabber. Instead, we have to solder some jumpers or desolder the memory from the PCB.
The last package is the Ball Grid Array (BGA) (Figure 1c). It is a type of surface-mounted packaging used for integrated circuits which can provide more interconnection pins than can be put on a dual in-line or flat package. Unlike the SOIC and the WSON, the BGA package can use the whole bottom surface of the device, instead of just the perimeter.
The pins of this package are the hardest to probe, since they are not accessible from the top of the PCB. Unless they are reachable from the back side of the PBC, the only way to get access to the package pinout is to desolder the memory from the PCB and put it in a socket adapter.
Where is the Firmware? How to Recognize the Flash Memory
Now we know what a flash memory looks like, we can start analyzing the PCB of our target device to find the memory among the hundreds of components on the PCB. Usually, the flash memory containing the firmware communicates with the CPU through Serial Peripheral Interface (SPI). SPI uses an 8-pin interface, so we need to look for a flash memory chip with eight pins.
Figure 2, below, shows the PCB of the Annke N48PBB, which we will analyze and find the flash memory.
Let’s start looking for 8-pin components: a good candidate is highlighted in the red circle. Looking closely at this component, we can see that it is a Macronix MXIC MX25L12835F flash memory. From its manual (found on the internet), we can read that it supports SPI as the communication protocol. Together with the fact that there are no other memory components on the PCB, we can be quite sure that this is our target. In part two of this blog series, we will see how to read its contents.
Pro tip: Sometimes it’s hard to read the label of a component on the PCB because of wear. Try to recover it by cleaning the component surface with some alcohol-soaked cotton, dry it, and then dust with some chalk. After removing the excess chalk dust, you should be able to read it!
Once we have opened the box and reached the PCB, we notice that every component soldered on the PCB is very small, and the labels are hard to read. A good magnifying lens can help read information printed on the components. Here are some examples of magnifying lenses:
Soldering and de-soldering station
When dealing with WSON or BGA packages, we need to solder some jumpers or completely desolder the flash memory from the PCB. A good soldering station with a hot air desolder is recommended. Always buy a soldering/desoldering station that allows setting the temperature of the solder tip and the desolder tool to not damage the components.
A good multimeter can be very useful, especially when you solder jumpers on the flash memory pads, to check that the soldering points are properly connected and there are no contacts between the pads.
Grabbers and SOIC Clips
As mentioned before, when dealing with SOIC packages, there are some tools that could save a lot of time in probing the pins of the flash memories.
Figure 7a shows some examples of grabbers. They can probe a single pin of a pin-mounted integrated circuit, so, we need enough grabbers for each pin we need to probe. Since the pins are close to each other, it may be easier to use a SOIC clip (shown in Figure 7b). SOIC clips have a small end, which fits the pin distance perfectly. At the other end, it has terminals that can be used, along with jumpers, to connect the clip to the bus interface or to the digital analyzer.
The bus interface is a fundamental tool for hardware hacking. It reads the memory contents from our chip by connecting the pins/pads of the memory package to the input/output of the interface. The bus interfaces can be used when dealing with pin or pad packages; however, without a proper adapter, it’s not feasible with BGA memories.
Looking on the internet, we can find several models of these bus interfaces. Each model differs in the communication protocols it can support. Usually, devices with small firmware memory embed memory communicating through SPI protocol; thus, we need to find a bus interface supporting at least that protocol.
Here are some examples of bus interfaces we have in our laboratory:
Pinout: How to Get the Correct Pinout Even Without a Datasheet
Sometimes we have to deal with flash memory chips which have no documentation on the internet. In this case, we don’t have the package pinout specs to know how to connect our bus interface card.
Let’s consider the Annke N48PBB use case we looked at earlier. Assume there is no datasheet for the Macronix MXIC MX25L12835F memory. We know that this flash memory has an 8-pin SOIC package, but we don’t know either its pinout or the communication protocol it supports. So, we might have to make some guesses to start: Let’s see if it communicates through SPI, and the pinout is the standard one for generic SOIC-compliant packages.
The figures above represent the supposed pinout of our flash memory (Figure 9a), with a closer look at it (Figure 9b), to highlight the correct orientation.
Pro tip: One corner of every PCB-mounted component has a small circle. It’s important to orient the circle in the same position for both the schematic and the real component to correctly identify the pinout.
Since this pinout is just a hypothesis, we need to confirm our assumption by measuring the switching activity of each pin. To do that, we can use a logic analyzer.
Now that every pin of the flash memory is connected to the logic analyzer, we can start measuring the voltage values to have an initial idea of the pinout.
Figure 11 shows the first capture of the logic analyzer. For this first analysis, all the channels have been set in analog mode, so that we can understand the voltage the memory uses. The vertical red line represents the moment when the device was turned on.
Let’s start doing some tests. From Figure 9a (above pinout schematic), we assume Pin #4 to be the GND: now we have a good confirmation of it, since the channel A3 (Pin #4) is always 0V.
Similarly, Pin #7 and Pin #8 are always 3.3V. This can confirm both that Pin #8 is the VCC and that Pin #7 is the RESET (active low). Note that the sampling frequency of the logic analyzer with eight active channels is too low to see the few cycles delay of the RESET signal.
Furthermore, if we set channel 5 (Pin #6) in digital mode, and we zoom into it, we will get what is shown in Figure 12 above. Here, we can confirm that pin number 6 is the SCLK (serial clock) pin.
Now we have enough elements to confirm our hypothesis. Before going on with the actual content reading, let’s do a double check. Most logic analyzer applications offer the capability of debugging a set of protocols, among them SPI.
So, we can feed the SPI protocol analyzer with the information we have up to now (SCLK, RESET, VCC, GND), and those we are now assuming (SI, SO, CS). The write protect signal, like the SI, are inputs, so we cannot detect them as outputs.
As we can see from Figure 13 above, the SPI analyzer tool confirms our assumptions. In fact, it can read what the SPI memory is sending out.
Now we are finally ready to read the memory contents and dump the firmware! In the next blog we demonstrate some examples of complete memory dump methodologies based on real use-cases.
You can read Part 2 here: “Methods for Extracting Firmware from OT Devices for Vulnerability Research.”