Firmware Acquisition Techniques
Summary
This page describes various methods that can be used to access the firmware from embedded devices. These methods are presented and evaluated here. The Attack-Tree for firmware acquisition can be divided into three main categories[1], which are described in the figure below and the following sections in more detail. It also represents the best order when tying to obtain the firmware.
Background
Embedded Firmware
Firmware usually describes a small footprint software (e.g., bootloader), embedded by the manufacturer, which locates and loads the kernel. In turn, the kernel starts the OS and finally passes control to it, which can later execute applications in userspace. However, in the context of embedded systems, the term firmware usually refers to the system image as a whole, which, if all present, consists of bootloader, Kernel, OS, and applications that together form the embedded system. Firmware can contain several operating system images or, in its purest forms, only consist of a micro-code managing the whole system.
Bootloader are bootstrap software and always loaded first when a device is started. Its main task is to initialize the hardware components and to load the Linux kernel into memory, give it all necessary information for correct execution, and finally transfers control to it. It also allows the system to be updated without the need for special hardware like a JTAG, SPI, or EEPROM programmer and can perform early integrity checks by making sure that no modified image is loaded upon boot. But it could also be used to acquire trusted memory or image dumps. The first-stage bootloader is located in the ROM on the SoC and is bound to it. Whereas the second and third-stage bootloaders are located in the flash memory of the board. For personal computers, the BIOS or EFI forms the first-stage bootloader, and, for example, GRUB, the second and third stage bootloader.
U-Boot (Universal Boot Loader) is the most commonly used bootloader in the embedded world and is a two-stage boot loader which is loaded by the SoC’s first-stage bootloader. It is a quite powerful tool, which provides access to a command-line interface via debug interface (e.g., UART), which allows a user to load alternative images or make changes to an existing configuration. U-Boot offers different numbers of commands depending on version and implementation. From reading memory, changing environment variables, to downloading complete boot images over the serial port or even over the network. The latter is made possible by an FTP server integrated with the bootloader. Alternative bootloaders for embedded systems are Redboot, BareBox, and Ubicom bootloader.
Serial Busses
On-Chip Debug (OCD) Interfaces can be multiple or none on one board. These were used during the development and testing phases of a device and are now leftover. They can be used to access the microcontroller or memory devices. In the following, the most important interfaces are introduced and are further elaborated in Chapter On-chip Debug Interfaces as necessary. However, it should be noted that there are other interfaces, such as I2C and USB, but also more specific, Serial Wire Debug (SWD) for ARM and Background Debug Mode (BDM) in automotive processors. In the case of an Android-based operating system, debugging is done via the Android Debug Bridge (ADB).
UART (Universal Asynchronous Transmitter/Receiver) is the standard serial interface for most microcontrollers. This interface is used to send and receive data via two serial data lines. Receive Data (Rx) and Transmit Data (Tx), besides multiple control lines. This serial interface is used with various other interfaces (e.g., RS-232 or EIA-485) while the UART controller performs serial-to-parallel conversion on data send and received between the processor and the peripheral device.
SPI (Serial Peripheral Interface) is a serial interface similar to UART. However, it is mainly used for communication between hardware components and offers a simple and efficient alternative to parallel bus systems following a master/slave architecture, which makes it very suitable for embedded applications. The focus of this work is on the use of SPI in combination with flash chips. With certain chip packages (e.g., SOP8/16), all data of the flash chip can be retrieved using SPI without having to unsolder the flash chip.
JTAG (Joint Test Action Group) is a standard from IEEE[14], which provides a serial interface for in-circuit testing and debugging of semiconductor chip isolated from the other hardware. JTAG also provides the means to read or program the contents of memory chips. Depending on the version, JTAG offers five (IEEE 1149.1) or two (IEEE 1149.7) pins, the first is also called Test Access Port (TAP) and the second is its further development which is called compact JTAG (cJTAG). Several components of the board can be connected to the same JTAG bus (JTAG chain).
Dissembly
Preliminary examination: Many embedded devices are difficult to disassemble physically. Either it is an ingenious construction consisting of many small individual parts that do not like to be separated from each other, or it is a simple clipping system which is still very difficult to open without damaging the enclosure. In any case, it is worth taking a look at the database of the Federal Communications Commission (FCC) first, before venturing into the hardware. The FCC Regulation Database contains useful information about all devices approved by the FCC for the American market. The FCC ID is a unique alphanumeric code that is usually found on the product label, packaging, or online. Information accessible by FCC ID or by using this alternative client: Test Setup Photos, Test Report, Cover Letter(s), RF Exposure Info, Users Manual, ID Label/Location Info, Internal Photos, External Photos, Operational Description, Schematics and/or Block Diagram.
These Documents must be submitted by the manufacturer for certification of a device and are accessible to the end-user. The internal photos are of great interest, as they can provide information on whether On-Chip Debug (OCD) interfaces are available or not. However, this decision is based on experience, and it is never possible to tell whether OCD interfaces are available by just looking at a photo of the board and can only be done by physical intervention, which will be explained in the next section. Additional regional databases of regulatory organizations may also be useful since not every device has FCC approval.
Disassembly typically requires a few tools and strong nerves. A smaller Phillips screwdriver (PH0/PH3) and some plastic opening tools are generally sufficient. Furthermore, some additional tools may be needed. These include UART to TTL converter (CH340G), SPI/I2C programmer (CH341H), and the appropriate clips to read SOP8 pr SOP16 package type chips without desoldering them. The last two tools will only be used in Section Exploit Memory Chips. A common multimeter may be used to measure the pins. Alternative instruments are introduced as needed. The functions of the CH340G and CH341H can also be performed by a development board like the Raspberry Pi.
Update Mechanism
The Manufacturer’s Website is the first place to go to gather information about devices, such as basic device configurations and technical specifications. Since embedded devices should also be updated from time to time, some manufacturers provide firmware images, e.g., via HTTP or FTP download. Be it for manual firmware upgrades or own modifications of open source projects. This method is the fastest way to get the firmware, which means that the analysis can be started immediately without needing the corresponding embedded device.
Update Mechanisms became important with the increasing number of embedded devices. Those shall provide secure and reliable firmware updates without the user having to take care of it. Updates are performed in the classic pull or in push-mode for IoT update models. In the former case, the device checks with the server whether new updates are available. With the latter, the server sends the new firmware to the device in the event of an update.[3] Therefore, the images often only appear in the Deep Web, if at all. In the case of the pull-models, the update routine is periodically initialized by the device itself or manually via the user interface. In some cases, the download link or even the firmware can be intercepted by performing an eavesdropping attack on the network when the update routine starts. If there is already an access via UART given, but there is no possibility to extract the complete firmware from there, the update mechanism, and its configuration can be searched, which should contain a link to the update server and, if available, also the URL for the firmware download. These methods are made more difficult or even impossible in push mode. Most manufacturers offer their own weakly implemented solutions, if at all. E. Baccelli et al. [4] criticizes the lack of secure and reliable update mechanisms in IoT, even though these are the key factor in eliminating serious vulnerabilities. These mechanisms should guarantee an integrated and authenticated update process from end to end. There are open standards for remote IoT device management, such as IPv6-OTA, SUIT-OTA, and LwM2M-OTA, which provide mechanisms to manage firmware updates. OTA stands for Over-The-Air firmware updates, which are pushed directly from the update server to the IoT device. Table 1 provides an overview of common threads against OTA standards and which enumerated standards have protection mechanisms against them. It can be observed that in the case of reverse engineering, there are still no sophisticated solutions to protect against eavesdropping of the firmware. Although there are approaches to protect the firmware in-flight by encryption or usage of (D)TLS. Furthermore, there are also approaches to how the blockchain can be employed for secure firmware distribution and updates [5]. These advanced update mechanisms will make the firmware download for reverse engineering difficult or even impossible in the future.
| Threads | IPv6-OTA | SUIT-OTA | LwM2M-OTA |
| Tampered Firmware | ✓ | ✓ | ✓ |
| Firmware Replay | ✓ | ✓ | ✓ |
| Offline Device Attack | ✓ | ||
| Firmware mismatch | ✓ | ✓ | |
| Flash Memory Location Mismatch | ✓ | ✓ | ✓ |
| Unexpected Precursor Image | ✓ | ✓ | |
| Reverse Engineering | |||
| Resource Exhaustion | ✓ |
On-chip Debug Interfaces
UART
| Pin | Description |
| RX | Receive |
| TX | Transmit |
| GND | Ground |
| VCC | Voltage |
Table 2: UART Pinout
Universal Asynchronous Receiver Transmitter (UART) is a rather old hardware component which is still the standard debugging interface of most microcontrollers. Data transmission takes place directly via the Transmit (TX) and Receive (RX) lines without handshake so that no additional lines are required. This type of serial communication is referred to as TTL-UART and is only suitable for data transmission over short distances. However, a common GND connection is indispensable for error-free data transmission. The RS-232 standard, on the other hand, uses six additional control lines. In the following, the term UART will refer to a TTL-UART. Furthermore, no distinction is made between UART and the more specific USART (Universal Synchronous Asynchronous Receiver Transmitter) component.
Identification of potential UART interfaces can be done after the devices have been dissembled so that the PCB is freely accessible. The Example PCB can be used here as an illustration. The basic rule for identifying UART interfaces is to search for 3 or 4 contiguous pins, holes, or pads on the exposed board. These may be placed and labeled in obvious locations, or they may be hidden between other test points. Alternatively, the conductor tracks on the PCB can be evaluated. This method is especially useful when searching for hidden interfaces. Using the Example PCB, it can be observed that GND is connected to the ground plane of the PCB. VCC has a thicker trace here and supplies power to several pins. TX and RX both have tracks leading in the same direction, which can be followed to the MC. In some cases, the UART pins may used directly on the microcontroller itself. The corresponding pins can be easily located after consulting the datasheet of the MC. This is possible f.e. for MC of the Quad Flat Package (QFP) with leads on the side. This method could also be used to intercept other communications in and out of the MC.
Confirmation is still required after identifying a potential UART interface. A logic analyzer or oscilloscope are of great advantage here, since they can determine the pin assignment very conveniently. In the case of the UART, this is not necessary, since the pin assignment (Table 2) can also be determined with a multimeter and some trial-and-error. GND is determined by a continuity test and VCC by its constant voltage. UART usually transmits with 3.3V, but in some cases, it can also be 1.8V or 5V. In the best case, TX is transmitting when determining the pin assignment, and a varying voltage between 0V and VCC can be observed since TX is the active component of the UART. If TX is not transmitting, there will be no voltage on RX and TX. Then it is necessary to check which of the two pins reacts to the input of the terminal and which one provides the output on display. The VCC connector does not need to be present or used in such a setup. It is best avoided, as incorrect wiring can cause damage to the host or slave if the electronics do not have suitable protection mechanisms. In rare cases, the GND pin will also be omitted. UART does not have to provide a designated GND pin but can be connected to the ground plane of the PCB at any point.
A Connection via serial console can be established as soon as a corresponding UART interface is identified and confirmed. Examples of serial console programs are Serial (MacOS), minicom (UNIX) and Putty (Windows), and a USB-to-TTL converter is most likely required with modern computers. Its use requires additional configuration of the console of the terminal device from which the connection is to be established. This includes the specification of Baudrate in bits per second, Data Bits (7 or 8), Parity (none, even or odd) and Stop Bits (1 or 2). The configuration of the baud rate, which specifies the transmission rate in bits per second, should be sufficient in most cases. An oscilloscope or a logic analyzer can be used again to determine the baud rate. Alternatively, the usual baud rates, such as 9600, 19200, 38400, 57600, and 115200 b/s, can be tried out until something readable appears in the terminal. A wrong configuration will result in data not being recognized correctly, both when sending and receiving data, and thus pure gibberish will be displayed. Additional configurations should not be necessary, as it rarely deviates from the standard configuration of (8N1), which stands for 8 data bits, parity none, and one stop bit. The result of this configuration is an interface to the local terminal of the target devices, which can be used in further steps to analyze or extract the firmware.
JTAG
| Pin | Description |
| TDI | Test Data In |
| TDO | Test Data Out |
| TCK | Test Clock |
| TMS | Test Mode Select |
| TRST | Test Reset (optional) |
Table 3: JTAG Pinout
| Pin | Description |
| TMSC | Test Serial Data |
| TCKC | Test Clock |
Table 4: cJTAG Pinout
Joint Test Action Group (JTAG) is an On-Chip Debugging (OCD) interface that was developed for in-circuit testing components such as MC, RAM or Flash chips, but can also be used for many other electronic components. This interface is used during the development and test phase to ensure the functionality of the components on board. It also allows direct access to specific chips, which can be used to extract firmware from non-volatile memory. JTAG uses its own hardware description language called BSDL (Boundary-Scan Description Language). The Boundary Scan technique makes it possible to reveal the structure of a chip in order to determine how it can be addressed. For this, however, the corresponding BSDL file of the manufacturer is required for each chip. JTAG provides a synchronous serial interface, and its pinout can be found in Table 3. The methods for the cJTAG variant (Table 4) can also be applied to the Serial Wire Debug (SWD) interface of ARM, which has the same JTAG protocol on top.
S. Vasile et al. [1] describe the process of extracting firmware using JTAG as follows:
- Identification of possible JTAG interfaces: JTAG can occur in multiple pin arrangements. These can be connectors from 8 to 20 pins. Blocks of two times five are good JTAG candidates. In the special case of cJTAG/SWD, only two pins are searched.
- Determination of the pin assignment using specialized hardware like the JTAGulator.
- Dump the internal memory using a suitable JTAG programmer.
JTAGulator is an open-source hardware tool, providing built-in level conversion and input protection, that helps to identify JTAG/UART interfaces and pinout on target devices. [6]
Extraction of the firmware using JTAG is more complex than using UART, because there are a lot of different connectors and proprietary pins. Which, in turn, require different JTAG programmer for different microprocessors and architecture types. Here the Example PCB can be used again for illustration. Furthermore, the manufacturer may have taken security measures to prevent this interface from being exploited in the after-sales phase. Several measures can be taken to achieve this. The activation of readout protection or the destruction of the physical fuse after manufacture. By suppressing higher-level instructions or using password protection for individual components that erase themselves after n attempts. [7]
Design Solutions have been proposed since the emergence of the JTAG standard in 1990, in order to make JTAG a secure debug interface even though most chip manufacturers implement their own security measures. K. Rosenfeld et al. [8] propose that it requires additional protocols working on top of the IEEE 1149.1 standard. These should be able to provide authenticity, secrecy and integrity, in order to prevent that a chip cannot be read by an unauthorized person, that secrets cannot be sniffed on the bus or new data cannot be inserted. Furthermore, they criticize that most manufacturers offer no assurance at all. Vishwakarma et al. [9] discuss JTAG attack solutions and applicability of solutions on IoT nodes. These include the use of Physical Unclonable Functions (PUF), which generate volatile secrets when a chip is switched on, based on unique physical variations that naturally occur during semiconductor manufacturing instead of storing them in non-volatile memory. Also, using challenge-response techniques or the use of asymmetric cryptography based on ECC, which is more suitable for the IoT domain due to the smaller key size. Finally, by using different levels of privileged access provided by a separate Authentication and Authorization Module (AAM) or a credential-based approach involving a remote server for authentication in order to use JTAG. These solutions can make firmware extraction using JTAG more difficult or impossible. However, the cryptographic methods presented here are hardly applicable, due to the simplicity and low computing power of most IoT devices, as well as the fact that several solutions require additional hardware components, which are hardly ever implemented by manufacturers due to the trade-off between higher price on securing hardware.
Exploit Memory Chips
| Pin | Description |
| MOSI | Master-Out Slave-In |
| MISO | Master-In Slave-Out |
| CLK | Clock |
| SS | Slave-Select |
Table 5: SPI Pinout
Last resort: If all previous methods fail, the data can still be extracted directly from the memory chips themselves, which allows bypassing OCD interfaces and possibly implemented security measures by inserting the chip into an artificial system to read the data. In the same way, as it was common practice in the past to insert modular EEPROM components in order to be able to remove them for reading and writing. Today the memory chips are permanently integrated on the circuit board and should not be accessed directly by the end-user. For this purpose there are basically the methods of in-circuit and chip-off data extraction. With the former, chips can be read out without having to desolder them. However, this is only possible for a few chip packages. With the second method, the chips are desoldered with a hot air station and then read with the appropriate chip programmer. Although this is theoretically possible for all chip packages, the hardware required for each package to read the data is not cheap and relatively difficult to obtain. Both methods of in-circuit and chip-off data extraction are presented and evaluated in the following.
Identification of the chips used is essential here, as there are a large number of different manufacturers, memory types and packages. As usual, with embedded devices, the main storage is located outside the MC. The processor can communicate and execute commands with the memory devices via a suitable protocol such as SPI (Serial Peripheral Interface). Each chip carries its model designation engraved by laser on the package, which can then be used to search for the corresponding datasheets. It should be noted that the removal of the engraving can serve as a way of obfuscation. The common memory types are listed in Table 6. NAND and NOR flash devices are the most common memory types used in embedded applications. These flash types have different architectures and characteristics. In general, NOR flash memory is directly addressable, and the ideal choice when lower capacity, fast random read access, and higher data reliability are required. NAND flash, in turn, is ideal for applications requiring higher capacity and faster write and erase operations.
| Memory Type | Package | Capacity | OCD |
| EEPROM | SOP8 | 1kB-1MB | I2C |
| NOR | SOP8/SOP16/SOP32 | 8-256MB | SPI |
| NAND | TSOP48/TLGA52/BGA100 | 256MB-2GB | SPI |
| eMMC | BGA100 | >1GB | MMC |
The Example PCB can be used here again. Two different memory chips are installed on this one. On the back of the PCB is a 512KB SOP8 NOR flash chip (MX25L8035E), to which the in-circuit method is applied. Moreover, on the front is a 4Gb TSOP48 NAND flash chip (MT29F). The chip-off method must be applied to these. In this case study, only the in-circuit method was used. In the example case, the SOP8 chip contains configuration and log files.
In-Circuit
In-Circuit Data Extraction allows chips to be read out without having to desolder them, which is only possible with chips of certain packages where the leads are exposed. Examples are NOR flash chips and EEPROMs of the Small-Outline Package (SOP), which use SPI or I2C. NOR flash chips are used in almost every device today and have replaced the conventional EEPROM. In personal computers, these chips usually contain the BIOS or other EFI-compatible firmware and also play an important role in the embedded area. In this case study, SOP8 package chips were installed on almost every board. These devices can be read with a CH341H programmer and the appropriate clamp or similar. Reading the chips is extremely easy as the programmer supports most off-the-shelve chips. The clamp only has to be plugged onto the chip, whereby the orientation of the chip must be observed. During reading out, the board should be switched off to avoid simultaneous access to the memory module of on-board components. This method is quick and easy, but it is not guaranteed that the firmware image is on this chip. Alternatively, the readout can be performed using an external development board. In this case, the external development board only has to implement the memory commands listed in the datasheet to create a memory dump.
Chip-off
Chip-off data extraction should be seen as a last resort, since this method requires the removal of memory chips and can damage the hardware, which should only be done if data access is otherwise not possible. Desoldering is done using a rework station or hot air gun, tweezers, soldering flux, and patience. This method is mainly used for NAND and eMMC chips, which can appear in a variety of packages like TSOP48, TLGA52, BGA100, or BGA152. Appropriate adapters are required for each package. The actual data extraction is then done by a specialized reader which takes care of creating a logical image from the chip.[10] The tools and further information can be obtained from the Rusolut website. Etemadieh et al. [11] shows that newer technologies like eMMC, which require fewer pins, can even be read with a standard SD card reader. Furthermore, it is shown that if this type of chip has test points on the board, the process can also be performed in-circuit. In any case, this method is very complex, dangerous, and expensive. Data loss or destruction, as well as the acquisition of specialized hardware, is unavoidable.
Example
Tools
- SOP8/16 Clips
- SPI/I2C Programmer (CH340G)
- USB-to-UART (CH341H)
- JTAGulator
Related
- JTAGulator: Introduction
- JTAGulator: Find IoT-Device's UART interface
- JTAGulator: Find a Smartphone's JTAG interface
- JTAGulator: Update firmware
References
- [1] S. Vasile, D. Oswald, and T. Chothia, “Breaking all the things—a systematic survey of firmware extraction techniques for iot devices,” in Smart Card Research and Advanced Applications (B. Bilgin and J.-B. Fischer, eds.), (Cham), pp. 171–185, Springer International Publishing, 2019.
- [2] O. Shwartz, Y. Mathov, M. Bohadana, Y. Elovici, and Y. Oren, “Opening pandora’s box: Effective techniques for reverse engineering iot devices,” in Smart Card Research and Advanced Applications (T. Eisenbarth and Y. Teglia, eds.), (Cham), pp. 1–21, Springer International Publishing, 2018.
- [3] K. Sabri, “Recommendations for iot firmware update processes,” p. 12, CSA: Cloud Security Alliance IOT Working Group, 2018.
- [4] K. Zandberg, K. Schleiser, F. J. Acosta Padilla, H. Tschofenig, and E. Baccelli, “Secure firmware updates for constrained iot devices using open standards: A reality check,” IEEE Access, vol. PP, pp. 1–1, 05 2019.
- [5] K. Sabri, “Using blockchain technology to secure the internet of things,” p. 26, CSA: Cloud Security Alliance IOT Working Group, 2018.
- [6] P. Inc., “Internet of things project.” http://www.grandideastudio.com/jtagulator/, 2019. [Accessed 27 Dec. 2019].
- [7] J. Grand, “Jtagulator: Assisted discovery of on-chip debug interfaces,” in Grand Idea Studio, DEFCON 21, 2013.
- [8] K. Rosenfeld and R. Karri, “Attacks and defenses for jtag,” IEEE Design Test of Computers, vol. 27, pp. 36–47, Jan 2010.
- [9] G. Vishwakarma and W. Lee, “Exploiting jtag and its mitigation in iot: A survey,” Future Internet, vol. 10, p. 121, 12 2018.
- [10] Rusolut, “Data investigation and recovery technology.” https://rusolut.com/, 2019. [Accessed 28 Dec. 2019].
- [11] E. Amir, H. CJ, and H. Khoa, “Hacking hardware with a 10 dollar sd card reader,” in Exploitee.rs, Black hat USA 2017, 2017.