11 Finding Software Bugs in Embedded Devices
187
sets, operating systems, and custom components. This makes the task of compiling
a representative and balanced dataset of firmware packages a difficult problem to
solve. The lack of centralized points of collection, such as the ones provided by
software/app marketplaces, antivirus vendors, or public sandboxes in the malware
analysis field, makes it difficult for researchers to gather large and well triaged
datasets. Firmware often needs to be downloaded from vendor Web pages and FTP
sites, and it is not always simple, even for a human, to tell whether or not two
firmware packages are for the same physical device.
One challenge often encountered in firmware analysis and reverse engineering
processes is the difficulty of reliably extracting meta-data from a firmware package.
This meta-data might include, the device’s vendor, its product code and purpose, its
firmware version, or its processor architecture, among countless other details.
11.2.2 Extracting Firmware from Devices
Obtaining the firmware from an online repository as a firmware package is convenient and thus preferred, however it is not always possible. First, the firmware may
not be available, e.g., because there is no update yet, nor one planned. Sometimes the
firmware is only distributed through authorized and qualified maintenance agents,
e.g., in case of industrial or critical systems. It is also common that the firmware
is not distributed at all in an attempt to prevent counterfeit products, reverse
engineering of the software or protecting its security.
In such cases the best (and sometimes the only) solution is to extract the firmware
from the device itself. There are multiple possible ways to approach this ([529]
and [564] provide a detailed overview of the process), each approach having its
own set of benefits and issues. In the simplest case, the firmware can be extracted
by connecting to a debug interface (e.g., JTAG, and serial ports such as UART,
SPI, I2C). It is important to note that JTAG is a low level protocol and many
different mechanisms can be implemented on top of it. Debug mechanisms allow
dumping some memories (e.g., ROM, RAM or Flash memories behind a Flash
controller), but not necessarily others. When Flash memory is soldered onto a
Printed Circuit Board (PCB) and is independent from the processor, it is possible to
de-solder it and extract its contents using a Flash programmer/reader. Unfortunately,
the variety of Flash memory standards, types and pinouts is huge. One can design
their own Flash chip adapter for reading and dumping the memory contents (e.g.,
code, data) [75]. However, some cheap universal programmers may be sufficient for
dumping sufficiently many models of Flash memories [38]. Finally, the advanced
Flash programmers support even hundreds of thousands of different Flash memory
models [198].
However, when the device is a Flash microcontroller, the Flash memory is
integrated within the microcontroller and is typically not directly accessible. In
such cases, the microcontrollers themselves provide mechanisms to access Flash
memory areas, but often such mechanisms come with some Flash area protection
187
sets, operating systems, and custom components. This makes the task of compiling
a representative and balanced dataset of firmware packages a difficult problem to
solve. The lack of centralized points of collection, such as the ones provided by
software/app marketplaces, antivirus vendors, or public sandboxes in the malware
analysis field, makes it difficult for researchers to gather large and well triaged
datasets. Firmware often needs to be downloaded from vendor Web pages and FTP
sites, and it is not always simple, even for a human, to tell whether or not two
firmware packages are for the same physical device.
One challenge often encountered in firmware analysis and reverse engineering
processes is the difficulty of reliably extracting meta-data from a firmware package.
This meta-data might include, the device’s vendor, its product code and purpose, its
firmware version, or its processor architecture, among countless other details.
11.2.2 Extracting Firmware from Devices
Obtaining the firmware from an online repository as a firmware package is convenient and thus preferred, however it is not always possible. First, the firmware may
not be available, e.g., because there is no update yet, nor one planned. Sometimes the
firmware is only distributed through authorized and qualified maintenance agents,
e.g., in case of industrial or critical systems. It is also common that the firmware
is not distributed at all in an attempt to prevent counterfeit products, reverse
engineering of the software or protecting its security.
In such cases the best (and sometimes the only) solution is to extract the firmware
from the device itself. There are multiple possible ways to approach this ([529]
and [564] provide a detailed overview of the process), each approach having its
own set of benefits and issues. In the simplest case, the firmware can be extracted
by connecting to a debug interface (e.g., JTAG, and serial ports such as UART,
SPI, I2C). It is important to note that JTAG is a low level protocol and many
different mechanisms can be implemented on top of it. Debug mechanisms allow
dumping some memories (e.g., ROM, RAM or Flash memories behind a Flash
controller), but not necessarily others. When Flash memory is soldered onto a
Printed Circuit Board (PCB) and is independent from the processor, it is possible to
de-solder it and extract its contents using a Flash programmer/reader. Unfortunately,
the variety of Flash memory standards, types and pinouts is huge. One can design
their own Flash chip adapter for reading and dumping the memory contents (e.g.,
code, data) [75]. However, some cheap universal programmers may be sufficient for
dumping sufficiently many models of Flash memories [38]. Finally, the advanced
Flash programmers support even hundreds of thousands of different Flash memory
models [198].
However, when the device is a Flash microcontroller, the Flash memory is
integrated within the microcontroller and is typically not directly accessible. In
such cases, the microcontrollers themselves provide mechanisms to access Flash
memory areas, but often such mechanisms come with some Flash area protection