Abstract:Finding bugs in microcontroller (MCU) firmware is challenging, even for device manufacturers who own the source code. The MCU runs different instruction sets than x86 and exposes a very different development environment. This invalidates many existing sophisticated software testing tools on x86. To maintain a unified developing and testing environment, a straightforward way is to re-compile the source code into the native executable for a commodity machine (called rehosting). However, ad-hoc re-hosting is a da… Show more
“…Due to the diversity of peripherals, dynamic analysis of MCU firmware is extremely challenging. Although the rehosting technique has made some breakthroughs to test the hardware-independent part of the firmware [11,13,17,19,22,27,43,47], no existing work can test the driver code.…”
Section: Analysis Of Mcu Firmwarementioning
confidence: 99%
“…Existing approaches for MCU firmware fuzzing can be classified into five categories as shown in Figure 4 of the work by Li et al [43]. Emulation is the most intuitive method.…”
Section: Related Work 61 Mcu Firmware Fuzzingmentioning
confidence: 99%
“…All of them demonstrate good performance and cost-effectiveness. As with HALucinator, para-rehosting [43] also provides a uniform platform by abstracting an MCU on the commodity hardware in order to benefit from the off-the-shelf test suites such as AFL [46] and Ad-dressSanitizer [40] with the most powerful capability. Furthermore, it can greatly improve the fuzzing performance.…”
Section: Related Work 61 Mcu Firmware Fuzzingmentioning
confidence: 99%
“…For example, HALucinator [13] automatically detects HAL libraries and replaces them with host implementations. Para-rehosting [43] provides common HAL backend implementations to help port MCU firmware to native hosts. However, both approaches cannot test the peripheral driver which never runs.…”
Fuzzing is one of the most effective approaches to finding software flaws. However, applying it to microcontroller firmware incurs many challenges. For example, rehosting-based solutions cannot accurately model peripheral behaviors and thus cannot be used to fuzz the corresponding driver code. In this work, we present 𝜇AFL, a hardware-in-the-loop approach to fuzzing microcontroller firmware. It leverages debugging tools in existing embedded system development to construct an AFL-compatible fuzzing framework. Specifically, we use the debug dongle to bridge the fuzzing environment on the PC and the target firmware on the microcontroller device. To collect code coverage information without costly code instrumentation, 𝜇AFL relies on the ARM ETM hardware debugging feature, which transparently collects the instruction trace and streams the results to the PC. However, the raw ETM data is obscure and needs enormous computing resources to recover the actual instruction flow. We therefore propose an alternative representation of code coverage, which retains the same path sensitivity as the original AFL algorithm, but can directly work on the raw ETM data without matching them with disassembled instructions. To further reduce the workload, we use the DWT hardware feature to selectively collect runtime information of interest. We evaluated 𝜇AFL on two real evaluation boards from two major vendors: NXP and STMicroelectronics. With our prototype, we discovered ten zero-day bugs in the driver code shipped with the SDK of STMicroelectronics and three zero-day bugs in the SDK of NXP. Eight Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).
“…Due to the diversity of peripherals, dynamic analysis of MCU firmware is extremely challenging. Although the rehosting technique has made some breakthroughs to test the hardware-independent part of the firmware [11,13,17,19,22,27,43,47], no existing work can test the driver code.…”
Section: Analysis Of Mcu Firmwarementioning
confidence: 99%
“…Existing approaches for MCU firmware fuzzing can be classified into five categories as shown in Figure 4 of the work by Li et al [43]. Emulation is the most intuitive method.…”
Section: Related Work 61 Mcu Firmware Fuzzingmentioning
confidence: 99%
“…All of them demonstrate good performance and cost-effectiveness. As with HALucinator, para-rehosting [43] also provides a uniform platform by abstracting an MCU on the commodity hardware in order to benefit from the off-the-shelf test suites such as AFL [46] and Ad-dressSanitizer [40] with the most powerful capability. Furthermore, it can greatly improve the fuzzing performance.…”
Section: Related Work 61 Mcu Firmware Fuzzingmentioning
confidence: 99%
“…For example, HALucinator [13] automatically detects HAL libraries and replaces them with host implementations. Para-rehosting [43] provides common HAL backend implementations to help port MCU firmware to native hosts. However, both approaches cannot test the peripheral driver which never runs.…”
Fuzzing is one of the most effective approaches to finding software flaws. However, applying it to microcontroller firmware incurs many challenges. For example, rehosting-based solutions cannot accurately model peripheral behaviors and thus cannot be used to fuzz the corresponding driver code. In this work, we present 𝜇AFL, a hardware-in-the-loop approach to fuzzing microcontroller firmware. It leverages debugging tools in existing embedded system development to construct an AFL-compatible fuzzing framework. Specifically, we use the debug dongle to bridge the fuzzing environment on the PC and the target firmware on the microcontroller device. To collect code coverage information without costly code instrumentation, 𝜇AFL relies on the ARM ETM hardware debugging feature, which transparently collects the instruction trace and streams the results to the PC. However, the raw ETM data is obscure and needs enormous computing resources to recover the actual instruction flow. We therefore propose an alternative representation of code coverage, which retains the same path sensitivity as the original AFL algorithm, but can directly work on the raw ETM data without matching them with disassembled instructions. To further reduce the workload, we use the DWT hardware feature to selectively collect runtime information of interest. We evaluated 𝜇AFL on two real evaluation boards from two major vendors: NXP and STMicroelectronics. With our prototype, we discovered ten zero-day bugs in the driver code shipped with the SDK of STMicroelectronics and three zero-day bugs in the SDK of NXP. Eight Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).
“…Further, emulationbased approaches for monolithic firmware depend on having an accurate execution environment, including providing values for emulated peripherals. Hence, some fuzzing frameworks emulate peripherals using manual software models at a higher abstraction layer [15,27]-while recent methods have investigated approaches to remove the need for manually written software models [18,38,50].…”
Exponential growth in embedded systems is driving the research imperative to develop fuzzers to automate firmware testing to uncover software bugs and security vulnerabilities. But, employing fuzzing techniques in this context present a uniquely challenging proposition; a key problem is the need to deal with the diverse and large number of peripheral communications in an automated testing framework. Recent fuzzing approaches: i) employ re-hosting methods by executing code in an emulator because fuzzing on resource limited embedded systems is slow and unscalable; and ii) integrate models of hardware behaviour to overcome the challenges faced by the massive input-space to be explored created by peripheral devices and to generate inputs that are effective in aiding a fuzzer to make progress.Our efforts expounds upon program execution behaviours unique to firmware to address the resulting input-space search problem. The techniques we propose improve the fuzzer's ability to generate values likely to progress execution and avoids time consumed on mutating inputs that are functionally equivalent to other test cases.We demonstrate the methods are highly efficient and effective at overcoming the input-space search problem. Our emulation-based implementation, Ember-IO, when compared to the existing stateof-the-art fuzzing framework across 21 firmware binaries, demonstrates up to 255% improvement in blocks covered. Further Ember-IO discovered 6 new bugs in the real-world firmware, previously not identified by state-of-the-art fuzzing frameworks. Importantly, Ember-IO integrated with the state-of-the-art fuzzer, Fuzzware, demonstrates similar or improved coverage across all firmware binaries whilst reproducing 3 of the 6 new bugs discovered by Ember-IO.
CCS CONCEPTS• Computer systems organization → Embedded systems.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.