Part I: An Overview of Firmware Storage Options

Show left menu  
Hide left menu  
Firmware storage options

By Scott Lester and Steven Day, 09 Aug. 2017

The security of a device’s firmware, as the first or an early part of a trusted chain, can have implications for the security of the whole system. At Context we often obtain the firmware for a device so that we can extract it and take a good look at the underlying code for both the operating system and applications. For a recent example see our blog on the Virgin Media SuperHub

This blog is the first in a series of blogs on how firmware is commonly stored on embedded devices, and the techniques for extracting it. This first blog covers how and where firmware can be stored on a device. Future blogs will focus on some of the cheap, and not-so-cheap, methods of extraction.

Identifying Components

Before we cover the kinds of components available for storing firmware, let's first discuss how to identify components on a printed circuit board (PCB). The obvious one is the markings on a chip; these can include the manufacturer name, the model number and the chip package description. Later sections cover the typical packages for different kinds of chips, which can help us guess at the chip's function.

If you can’t read or look up the serial number on a chip, the circuit design can often give you a clue as to the chip’s functionality. For example, the photo below shows the PCB for a Siemens Programmable Logic Controller (PLC). Without looking up the chips we can instantly guess that the System-on-Chip (SoC) is on the right (it’s the biggest), the RAM is in the middle (the wiggly traces connecting it to the SoC are designed to be exactly the same length, because high-speed RAM needs accurate signal timing), and the Flash is on the left (the many parallel lines suggests lots of data signals).

PLC

The above is a good example of how to identify the likely function of a chip based on its surroundings and connections, which can help with unmarked or unidentifiable chips. However, stating the obvious, in this case it is possible to fully identify all of the three chips by their markings.

The large chip on the right can be identified from the part number and the Siemens logo. The logo on the other two devices indicates that they are both produced by Micron. Due to space constraints on smaller packages Micron do not print the part number, and instead print a FBGA marking which takes up less space.

Fortunately Micron provides an online decoder to obtain the full part number, which reveals that the chip on the left is an ECC NAND Flash (MT29F1G16ABBDAHC) and the one in the middle is a 512Mb SDRAM (MT46H16M32LFB5-6).

Possible Locations for Firmware

There are a number of places that firmware can be stored on a circuit board, and it may indeed be stored in more than one place on some devices. Assuming we can now locate and identify the likely memory chips on a board, let's cover the different types of storage, and what they are typically used for.

NOR Flash/EEPROM

EEPROM

The terms NOR and EEPROM are often used interchangeably; what we mean here is low-density storage that may be integrated in System-on-Chips (SoC), or may be in its own chip package. There are many other sources that cover the differences between Flash storage types, but the main advantage of NOR Flash is that it is byte-addressable and erasable, which means you can execute code straight from NOR, one instruction at a time (eXecute in Place or XiP). This makes NOR Flash ideal for storing low-level, first stage code, as you don’t need any drivers or Flash management to read it.

NOR Flash typically comes in one of two types: serial and parallel. Serial NOR Flash usually comes in small packages, such as SOIC-8, which look like the picture on the left.

Other common package formats are WSON (package types often have great/tortured acronyms, in this case: Very Very Small Outline No-lead), DIP-8, SOIC-16 and BGA-24. These small chips are accessed by a serial protocol such as SPI or I2C, and are often used to store small amounts of data, for example the system settings on a SoHo router.

Large capacity NOR typically come in larger packages that have parallel data lines for increased speed. These devices are more likely to come on a Thin Small Outline Package (TSOP) package with 48 or 56 pins, such as the Spansion chip shown below.

NOR

These, continuing our example, could be used to store the file-system image on a SoHo router.

NAND Flash

BGAWhereas NOR is perfect for storing relatively small amounts of data, larger data storage is typically found on NAND Flash chips. NAND is block addressable (you read it a block at a time) and writes are much quicker than with NOR, but it is slower to read. As NAND isn’t byte addressable it cannot be used to execute code directly, and instead program code needs to be copied elsewhere (usually RAM) before it can be run.

NAND is more complicated to interface with than NOR memory, and is normally accessed via a parallel interface. You would therefore want to use a standalone chip reader for reading or writing the contents when it isn’t in circuit.

NAND flash commonly comes as a TSOP (either 48 or 56 pin) or Ball Grid Array (BGA) package, which makes removal from the PCB more challenging than with packages that have leads. It can sometimes be included in a Multi-Chip Package (MCP) along with RAM, which saves on PCB space when compared to having two discrete chip packages.

Managed NAND

Both NOR and NAND Flash require a lot of management to compensate for the limitations of their operation; specifically to implement error correction, wear leveling, performance optimisation, and to perform the translation of physical storage to logical storage. This can be implemented in the hardware that manages the Flash memory in a Flash controller, in the file system driver, or in some combination of the two. In addition, Flash chips from different manufacturers typically aren’t interchangeable, as they come in a range of sizes and pin configurations.

To reduce this burden eMMC is a form of managed NAND memory, and consists of a MultiMediaCard (MMC) controller and some NAND Flash within the same physical package. They’re effectively an SD card in a chip package. They are also more interchangeable, with most conforming to the JEDEC standard pin-out and package sizes. This makes them more desirable to manufacturers, who can change to a different supplier without having to redesign anything.

The photo of a BGA package above is of a Kingston eMMC chip, the KE4CN3H5A, which is on an Android-based teleconferencing device we looked at.

The nicest thing about eMMC is that you can interface with a chip with only three connections: data0, clock and command. Plus most of them have a standard (JEDEC defined) pinout. As a recent BlackHat talk showed, this means that if you can find those three signals on the PCB you can dump the chip in-circuit. More on this in a later blog.

Universal Flash Storage (UFS)

We were recently attempting to unbrick a Samsung Galaxy S6 (GT-i920F), and found some service manuals that mentioned it has a Samsung KLUBG4G1BD Flash memory chip. This, it turns out, uses UFS 2.0, which is a successor to eMMC. It uses a different physical interface that offers quicker speeds than eMMC. See this post on Anandtech for a more detailed analysis on UFS compared to eMMC.

Mixing Storage Types

The above section introduces the different types of Flash storage media, and their relative advantages and disadvantages. Often a device will use one or more types of memory for different kinds of storage.

Continuing our example of a SoHo router device, the diagram below shows how different storage locations can be used on a single device, and where they’re loaded in a generalised boot process. In this case there are three different storage locations that are used to store the Primary Boot Loader (PBL), the secondary bootloader, the program code and the system settings.

storage_types

The following blogs in the series will show cheap and not-so-cheap ways of getting at the different storage types.

Contact and Follow-Up

Steven and Scott both work in Context's Research team, from our Cheltenham and London offices respectively. See the contact page for ways to get in touch.

Back to Top