Fuzzing of Embedded Systems: A Survey

As general-purpose operating systems have a large number of functionality, compatibility, and continuous support from developers, they have also been used for embedded devices. However, the minimal shapes of an operating system are frequently used in embedded devices owing to performance limitations. For example, a combination of busybox [129] or uClibc [5] (i.e., lightweight user environments) and the Linux OS kernel has been widely used in the embedded world.

The second class of embedded devices has a custom-built OS, such as a real-time operating system (RTOS) [122]. The RTOS is used for real-time applications that process data as it does not have buffer delay. These operating systems are suitable for low-power-consuming devices. For example, VxWorks [133] or QNX [15] is a representative RTOS and is widely used in embedded devices. Another example is uClinux (i.e., microcontroller Linux), which has no memory management unit (MMU).

This embedded device class has monolithic software that functions as a system and an application by compiling them. For example, many small-scale devices, such as SmartCards, GPS receivers, or thermostats, have this form. These devices typically do not have the hardware abstraction level, which hides the physical hardware and supplies programming interfaces.

Embedded devices have various microcontrollers (i.e., MCU) and OSs. Common MCU types are more than 10 types including ARM, MIPS (32/64bit), Alpha, x86-64, IA-64, MSP430, PowerPC (32/64bit), SPARC-V8, and V9, and OSs are more than 5 including Linux, VxWorks, QNX, uClinux, and TinyOS [4], whereas a desktop system commonly has x86-64 CPU and Linux OS. Desktop fuzzers typically work on the target system, but embedded system fuzzers work on another system as the target system has low power and limited resources. Therefore, most embedded system fuzzers use emulation or re-host firmware. Desktop fuzzers’ target programs are real-world datasets, such as Binutils [100], LAVA-M [35], or CGC datasets [114], whereas embedded system fuzzers’ targets are executable programs in firmware.

MCU architectures have two main types: reduced instruction set computing (RISC) and complex instruction set computing (CISC). Examples of RISC are ARM, MIPS, and PowerPC architectures, whereas an example of CISC is x86-64 architecture [13]. The RISC architecture aims to use simple instructions that are executed in one clock cycle. Conversely, the CISC architecture focuses on using fewer assembly instructions by constructing affluent instruction sets on the target hardware. For example, the CISC “ADD” instruction is divided into three separate instructions in RISC: “LOAD,” “ADD,” and “STORE.” As the instructions are split up, the RISC architecture has the advantages of pipelining and better hardware usage. Thus, many embedded systems use the RISC architecture.

Although desktop fuzzing does not require to consider heterogeneous computer architectures, an embedded system fuzzer must support multi-architectures. Owing to the limited resource environment, the RISC architecture is commonly used for embedded devices. According to Chen et al. [20], 32-bit big/little-endian MIPS architecture makes up 79.4% of all the surveyed firmware images, whereas 32-bit big/little-endian ARM makes up 10.0% of them. In addition, eight other architectures exist, such as PowerPC, Motorola, and x86-64, in firmware images of an embedded system. Consequently, an embedded system fuzzer must support at least MIPS and ARM architectures as they constitute more than 90% of all firmware architectures.

Hundreds of fuzzers exist in the Linux platform, but they cannot be used directly on embedded devices as mentioned above. For example, extracting firmware from a Linux-based embedded device and fuzzing it with a popular fuzzer, such as AFL [139], might not function normally. Therefore, several fuzzing techniques for embedded systems have been proposed. We describe them in Section 3.4. In summary, traditional fuzzing has no hardware dependency, whereas ESF has strong hardware dependency, as presented in Table 2.

As indicated in Algorithm 1, monitoring fuzzing results (i.e., crash detection) is a crucial ESF step. Crash detection is not easy in ESF, but it is comparatively easy in desktop fuzzing. According to Muench et al. [87], T1, T2, and T3 crash detection rates are 70%, 40%, and 0%, respectively. Therefore, the crash detection ratio in embedded systems is only 37% to desktop systems. This is because desktop systems are equipped with various detection mechanisms (e.g., error messages, security warnings, and system logs) on a crash or fault. A fuzzer in Linux detects crashes when an executing program is terminated by a fatal signal such as a segmentation fault. This is because a memory bug that overwrites the return address with an arbitrary value produces a segmentation fault or abort when it is accessed. This detection method is simple and efficient as only the fuzzer catches the signal without operating systems’ intervention.

However, as embedded operating systems do not provide a fault generation mechanism in most cases, a fuzzer can rarely detect a fault or crash. Even worse, as embedded devices often do not have an output device (e.g., a monitor), a user cannot notice crash detection. Thus, embedded fuzzers use a liveness check using heartbeat messages, memory check tools (e.g., MemorySanitizer [116], AddressSanitizer [109], or ThreadSanitizer [110]), or debugging ports (e.g., UART [94] or JTAG [106]). UART is the abbreviation for universal asynchronous receiver transmitter, and JTAG is the abbreviation for joint test action group. (1) The liveness check (or probing) checks the embedded devices’ states periodically. There are two types of probing [87]. Active probing adds special packets into the communication between a fuzzer and the device. This can affect the communication as the program has to respond to the packets. Meanwhile, passive probing only scans the device’s states without modifying them. This is conducted by probing the responses presented by the device to the fuzzer or by identifying crash symbols. (2) Memory checking tools are accompanied by emulation. They check a memory utilization status every time and detect a security violation. Although these techniques are helpful for a desktop fuzzer, they are more beneficial for ESF. (3) The debug ports are used by debugging the device, which indicates that an analyst using a debugger program can have insight into the device. However, debug ports tend to be disabled nowadays.

In software testing, instrumentation refers to the measure of a program’s performance, to diagnose errors and to write trace information [57]. Instrumentation approaches have two types: source code instrumentation performed on the source code during static analysis and binary instrumentation performed on the compiled binary files [48]. Instrumentation is frequently used in desktop systems to gather code coverage information of the supplied inputs or trace taint analysis of interesting variables through source code instrumentation or binary instrumentation [90].

However, typically, the source code of firmware or applications is not available from embedded devices. Even worse, the program cannot be re-compiled as heterogeneous embedded devices have their CPU architecture, operating system, and I/O devices. Consequently, an embedded device tester has difficulty utilizing instrumentation. Rather than using source code instrumentation, the other solution is using dynamic binary instrumentation tools, such as Pin [77] or Valgrind [89]. For example, QSYM [137] uses coverage information when it tests program binary by leveraging the instrumentation techniques of Pin. However, this is only possible for general-purpose OS-based devices, except for embedded OS-specific devices or devices without an OS [87].

Embedded systems have computational performance limitations resulting from low power and limited resources. Several techniques have been developed for current embedded systems to overcome performance limitations. First, embedded systems have a functional upgrade [52]. Since vendors reduce the production cost, they change and upgrade embedded systems by changing the software while keeping the hardware the same. This functional upgrade often includes functionalities to overcome the computational performance limitations. Second, an RTOS or real-time processing, which processes data and events within the time constraints, eliminates computational performance limitations [51]. Third, removing data dependency by the optimized compiler can improve computational performance. Data independency makes parallelization possible and contributes to better computational performance. Finally, having the program use registers, caches, and DMA instead of memory is better for computational performance.

Typically, fuzzing requires re-executing the program under test (PUT) to maintain a clean state for every test input. By reverting virtual machine snapshots, this technique is easy for desktop systems. However, this is difficult for embedded devices that require a substantial amount of time to reset the device. In addition, parallel fuzzing execution is possible in desktop systems. However, parallelization is frequently impossible in embedded devices, such as embedded OS devices or devices without an OS. Thus, repeated trials are impossible, or an embedded system takes a long time to fuzz.

The ability to handle increased demands is referred to as scalability, and this is parallel execution in the fuzzing field. Parallel fuzzing is typically supported in desktop systems but impossible in embedded devices owing to limited resources and economic reasons. As constructing an environment for parallel fuzzing in embedded systems requires many actual devices, it costs a lot. For example, AFL (i.e., a popular desktop fuzzer) supports parallel fuzzing through single-system parallelization or multi-system parallelization, which depends on the number of systems required. In summary, ESF cannot expect scalability in state-of-the-art works.

Black-box testing in software engineering only determines the program’s interfaces, rather than the details of the PUT, such as data structure or algorithm [92]. Similarly, the black-box fuzzer randomly mutates the seed test cases based on predefined rules without identifying the PUT’s inner information. This method has the advantages of simplicity and ease of use, but it is not smart. For example, in Table 3, the probability of reaching assert() function is \(1/2^{32}\) as it attempts a brute-force execution (i.e., bit-flip mutation). To render a fuzzer smarter, white-box and gray-box fuzzers have been proposed.

White-box fuzzing is a technique for generating test cases based on the PUT’s internal structure and information generated during execution [45]. Specifically, this fuzzing method leverages program analysis techniques, such as dynamic symbolic execution (DSE) [46], to generate a suitable test case. The DSE executes the program initially, generates path constraints, and solves the constraints. For example, DSE executes initially the if statement in Table 3, then it identifies that the constraint is “0xdeadbeef,” and finally it makes the “0xdeadbeef” integer value to the input variable. Consequently, DSE can reach the assert() function within the second execution; hence, it is more efficient than black-box fuzzing, which requires \(2^{32}\) executions.

The advantage of white-box fuzzing is that, in principle, every new test case will cover a new execution path in the program. Thus, white-box fuzzing provides better code coverage and can discover more software vulnerabilities than the black-box fuzzing approach. It is also able to expose vulnerabilities that are located in the deep area of the code. However, white-box fuzzing has a disadvantage; that is, it requires much time to solve the constraint or sometimes cannot solve the constraints due to various problems such as path explosion [71] or massive resource consumption. In addition, it requires a large amount of information, such as a source code or preliminary work for the information.

The gray-box fuzzer is in the middle of black-box fuzzer and white-box fuzzer, and it only requires partial information about the target program (i.e., PUT). This partial information is commonly the code coverage produced through instrumentation or taint-flow information through taint analysis. For example, the most popular gray-box fuzzer, AFL [139], collects path coverage information at runtime and efficiently utilizes the coverage map to mutate test cases (i.e., test inputs). Specifically, it provides weight to the test cases to find a new path, and the test cases mutate. Thus, the gray-box fuzzer is sufficiently efficient as it does not require preliminary analysis and gathers only partially related information. After AFL, more advanced gray-box fuzzers [16, 17, 23, 102] have emerged continuously, indicating the effectiveness of the gray-box fuzzer.

This approach directly connects the target device and tests the system firmware without intervention. This category has two types of fuzzing. (1) Fuzzing via a network [22, 29] can test only network applications, which is simple, but black-box fuzzing is only possible. (2) The other fuzzing via debugging interfaces, such as the UART [12, 83] or JTAG [106], can test the operating system and applications. Therefore, the second approach is more beneficial. However, it requires intensive labor (i.e., making debug environments) and is not always possible owing to removing the debugging interfaces. UART is a hardware equipment for asynchronous communication between a computer and a peripheral device. Meanwhile, JTAG is a method used for verifying the designs of circuit boards and test circuit boards after manufacturing. In addition, JTAG equipped with in-circuit emulators [25, 62, 84] can be used to diagnose and debug the system.

Another approach uses emulation with firmware extracted from embedded devices through a UART or JTAG or downloaded from firmware update websites. Chen et al. [20] emulated 9,486 firmware, and Zheng et al. [145] covered 8,556 firmware. They used QEMU [10], which boots up the file system from firmware and runs a corresponding kernel on the file system. This emulation is a system-mode emulation, which executes some applications inside an operating system on an emulated hardware. However, every piece of hardware cannot be emulated owing to some restrictions on supported kernels and supported CPUs. Thus, partial emulation [60, 61, 70, 138] forwards peripheral API requests to the real device. This method has the same effect as system-mode emulation without full support, but intensive work is required to prepare the actual device and forwarding mechanism. User-mode emulation [145] migrates only user-level programs to the host OS by using a shared memory state (i.e., RAM file) with system-mode emulation. This migration is only possible when the kernel is the same in the system-mode emulator and user-mode emulator. The user-mode emulator has the advantage of having high throughput.

The third approach is firmware analysis, which is useful when dynamic analysis that requires firmware execution or emulation is difficult in some embedded systems. For example, Firmalice [112] has three main components: a static program analysis module, a symbolic execution, and an authentication bypass check module. The static program analysis module develops a program dependence graph of the firmware and creates an execution path slice from the start point to the target point. The symbolic execution engine finds execution paths that arrive at the target point and constraint-satisfied inputs. The authentication bypass check module confirms whether the input results in an authentication bypass vulnerability. Another example, KARONTE [104], also analyzes multi-binary interactions (i.e., static analysis) and uses taint information (i.e., flow information). This approach commonly requires comprehensive program information; thus, white-box fuzzing is only possible.

Many embedded system fuzzers have used firmware extracted from actual devices [124] or acquired from the Internet as a fuzzing target. After acquiring firmware, it is used as an input to emulation [20, 86, 145] or further analysis [112]. When the firmware is used as an input to emulation, it can be run and analyzed dynamically in the execution environment. Emulation-based fuzzing [27, 42, 49, 87, 115, 145] benefits from testing much firmware in a short time without difficulties in preparing real devices or creating experimental environments.

Muench et al. [87] explained the effectiveness and efficiency of emulation-based fuzzing for embedded devices. Specifically, through comprehensive experiments, they proved that fuzzing via a fully emulated system is faster and more accurate than that via a physical system. They reported four advantages. First, emulation-based approaches can easily add fault detection, such as heuristic methods. This advantage is beneficial to the embedded fuzzing environment with a crash detection difficulty. Second, as an emulator typically has a higher clock speed than a physical device, emulation-based fuzzing exhibits high throughput. Third, an emulation-based approach has time efficiency as rebooting the physical device is time consuming compared to restarting emulation. Finally, emulation has the advantage of clearing the target system easily as it uses a snapshot and reverts the target to an initial state. Firmware and its emulation are closely related. Thus, we describe popular emulators and their advantages in Section 5.3.

Despite that emulation is the correct option, it requires intensive work, such as firmware acquisition, firmware unpacking, and executable analysis. Moreover, emulation is not always possible, especially when at least one of the works is unsolvable. Another solution is fuzzing embedded devices via a network, commonly referred to as network fuzzer [43]. Network fuzzing is commonly a black-box fuzzing, and it does not analyze the program source code or binary code, but only captures network packets. For instance, Prospect [61] randomizes only 1 byte at a random position per captured packet and replays the communication. When the fuzzer detects an exception, it stores the network packets for further analysis. Meanwhile, IoTFuzzer [22] analyzed the protocol used in the communication between IoT applications and physical devices and performed protocol-guided fuzzing. IoTFuzzer performs a continuous liveness check to detect a fault. However, this type of fuzzing has three limitations: (1) target applications should be accessible from the network, (2) it is often slow, and (3) firmware crashes or faults are difficult to detect due to silent memory corruptions [87].

UART [131] is an interface for asynchronous serial communication, one of the most common protocols found in embedded devices. Hence, it has been used as a fuzzing bridge. For example, beSTORM [12] is an automated dynamic testing tool (i.e., fuzzer) to verify the security of any software or product that uses high-speed UART. Although this tool is a black-box fuzzer, it typically produces satisfactory results as it includes many protocol standards, such as UART, and supports auditing the specific protocol, thereby performing smart fuzzing. Other researchers [83] used an Arduino [6] to fuzz the debug pins on an embedded device and then used the Arduino as a USB-to-serial converter to communicate to the device and obtain a shell. Further, UART is commonly used as a fuzzing bridge and is often used as a connecting medium to facilitate emulation. In [87, 138], UART was used as a communication channel to transmit the memory state. In addition, as UART supports serial communication, it can be used as a data channel, such as sending interrupts or data.

The JTAG is a standard interface to verify the design and test pins of printed circuit boards [130]. As the JTAG is designed to access the hardware resources of the target device, to our knowledge, JTAG fuzzing does not exist. However, the JTAG can be used as a connecting medium to facilitate emulation similar to the UART. In several research studies [70, 86, 87, 138], there is forwarding peripheral input and output to the actual device through a JTAG debugger with an in-memory stub. Additionally, JTAG interfaces support accessing the CPU state, registers, and memory when communication is required between emulation and the physical device. In summary, the JTAG is commonly used for connecting an emulator and a real device, rather than a fuzzing target interface.

Emulation has several types. In system-mode emulation, firmware images are emulated similar to a virtual machine, and all peripherals should be supported. This emulation is a basic emulation provided by QEMU [10]. However, it is heavyweight and slower than user-mode emulation. User-mode emulation executes processes compiled for one central processing unit (CPU) on another CPU to provide convenience and efficiency. Hence, it supports system call translation, signal handling, and threading. System call translation indicates that the system calls of a PUT can be converted to those of the host. Further, user-mode emulation can redirect all signals in the PUT to the host’s signal handler. It can also emulate the clone system call and create a real host thread for each emulated thread. In summary, system-mode emulation emulates firmware as an entire system, whereas user-mode emulation emulates a process on another CPU for convenience.

However, system-mode emulation requires manual work, such as file system extraction, customized kernel configuration, and running system-mode QEMU. Thus, the Firmadyne [20] authors conducted full-system emulation by adding automatic works to system-mode emulation. The added automatic works are extracting the file system from the firmware, configuring the customized kernel, developing virtual network interfaces, and running system-mode QEMU. Meanwhile, some works [86, 138] used partial emulation as the emulations mentioned above are not perfect and accurate. Partial emulation, also referred to as hybrid emulation, combines an emulation environment and an actual device, and it forwards all items that emulation cannot handle to actual devices. Consequently, partial emulation has the advantages of accuracy and scalability, but it has a disadvantage of requiring an actual device.

Another hybrid emulation is the augmented process emulation used by Firm-AFL [145]. Augmented process emulation combines system-mode emulation with user-mode emulation to enhance fuzzing throughput. Thus, they implemented memory mapping, a RAM file that is a memory-mapped file shared between system-mode and user-mode emulator, and system call redirection. Consequently, Firm-AFL showed high-throughput fuzzing results and found two unknown vulnerabilities. Similarly, the authors of P\(^2\)IM [38] introduced an approximate emulation that feeds acceptable inputs to the firmware. Specifically, the emulator provides firmware with suitable inputs from the emulated peripherals when requested. These inputs do not need to be the same as the output from a real peripheral, but they should satisfy the firmware’s checking function to execute firmware successfully. In addition, P\(^2\)IM automatically generates approximate emulators for IoT devices equipped with various peripherals. This emulator renders it possible to roughly execute firmware, which is sufficient for fuzzing and analyzing firmware’s control or data flows. However, approximate emulation cannot ensure functional accuracy. Hence, it cannot be used for a program that requires high accuracy.

Emulation-based fuzzers must have an emulator. Considering the additional costs of creating an emulator from scratch, developers often utilize an existing emulator. Although QEMU [10] is the most popular emulator, few other emulators are available. Table 7 compares the popular emulators QEMU, Unicorn [91], and Simics [79]. QEMU and Simics emulate a full system, including the CPU and peripherals, so they are heavy. Meanwhile, Unicorn emulates only the CPU, so it is lightweight. As Unicorn emulates the CPU without the execution environment, it is flexible. However, it requires other implementations when more accurate emulation is necessary. Although QEMU has many related vulnerabilities, Unicorn and Simics have no vulnerability to date.

QEMU (i.e., Quick Emulator) is a generic and open-source emulator with unique features to emulate the processor and peripheral devices, to support multi-architectures and multi-platforms, and to be maintained eagerly. It translates several basic blocks simultaneously, provides a set of virtual hardware and devices, and runs various operating systems. QEMU can also emulate user-level processes, which execute processes compiled for one CPU on another CPU. Since QEMU [10] was invented, many fuzzing researchers have used QEMU as an emulation engine. Despite the insufficient functionalities of QEMU, several researchers combined it with other features, such as actual hardware support [70, 138] or augmented process emulation [145]. Authors of Firmadyne [20] added four features to address the limitations of current emulation. First, they modified QEMU to support NVRAM-related functions as the original QEMU did not provide such support. Second, QEMU booted up the extracted filesystem with their pre-compiled kernels as it could not support every kernel extracted from all firmware. With these pre-compiled kernels for ARM little-endian, MIPS little-endian, and MIPS big-endian platforms, they can cover 90.8% of their dataset. Third, their QEMU had a learning mode, in which their modified kernels recorded all system interactions. Finally, Firmadyne launched the extracted firmware image and performed network connectivity checks.

Unicorn Engine [80, 91] is a lightweight multi-architecture CPU emulator framework. It is derived from QEMU, but it has several advantages over QEMU, as presented in Table 7. First, Unicorn is a framework wherein anyone can develop tools on it. Second, it emulates only the CPU, so it is lightweight and flexible. It can emulate raw binary code without an execution environment, but QEMU requires an entire system image or an executable binary. Third, QEMU cannot present dynamic instrumentation, whereas Unicorn supports customized handlers for several types of CPU events. This support renders it possible for an expert to create an instrumentation tool for emulation. Finally, QEMU has had many vulnerabilities, according to the CVE website [30], and all of them are from subsystems such as peripherals and input/output devices. However, Unicorn does not have any revealed vulnerabilities to now. Therefore, it is more secure than QEMU.

Simics [79, 132] is a commercial full system simulator that simulates complex digital systems’ hardware and software. As Simics provides instruction-level fidelity and hardware models [135], it can support more than 10 processors, including ARM, MIPS (32/64bit), Alpha, x86-64, IA-64, MSP430, PowerPC (32/64bit), SPARC-V8, and V9. It also supports common operating systems (i.e., Windows, Linux, Solaris, and so on) as well as real-time operating systems (i.e., VxWorks and QNX). As Simics is a fast enough commercial simulator with sufficient fidelity and accuracy [105], it has been widely used in various industries. On the other hand, QEMU is an open-source machine emulator and is widely used in academia. Most emulation-based fuzzers in Table 4 use QEMU for their emulation platform.

In addition to the emulators mentioned above, other emulators exist, such as libemu [33], PyEmu [99], libCPU [44], IDA-x86emu [58], and Ghidra [95]. However, these emulators have limitations: for example, libemu only emulates x86 and is used to detect a shellcode. PyEmu is also an x86 emulator in Python, and IDA-x86emu is the x86 emulator plugin for IDA Pro [107]. These three are not multi-architecture emulators, but only x86 emulators. libCPU is an open-source library that emulates several CPU architectures, but it is incomplete and has not been updated for a long time. Ghidra is an open-source reverse engineering tool released by the National Security Agency (NSA). It includes a suite of software analysis tools on various platforms, including Windows, Mac OS, and Linux, and supports a wide variety of processor instruction sets and executable formats. However, as the time that the Ghidra project was released is not long, only a few embedded system fuzzers [65] use the Ghidra emulator to date. In summary, other emulators, except the four (i.e., QEMU, Unicorn, Simics, and Ghidra), are difficult to use and are no longer maintained.