Source-linked AI summary
P$^2$IM: Scalable and Hardware-independent Firmware Testing via Automatic Peripheral Interface Modeling (extended version)
Bo Feng, Alejandro Mera, Long Lu
TL;DR
Embedded firmware fuzzing is limited by hardware dependence, incomplete peripheral emulation, and poor scalability. The paper presents P2IM, which automatically models processor-peripheral I/O so a generic emulator can run firmware with an off-the-shelf fuzzer. The framework continuously executed 79% of 70 sample firmware and uncovered 7 unique previously unknown bugs in 10 real-device firmware.
Problem
Firmware fuzzing lacks scalable execution platforms because existing emulators do not cover MCU peripherals and hardware-dependent approaches are slow and limit parallelism.
Method
P2IM automatically generates approximate peripheral-interface models from firmware binaries and uses them with a generic processor emulator and drop-in fuzzer.
Results
79% of 70 sample firmware ran continuously without crashes, stalls, or skipped peripheral operations, and testing 10 real-device firmware found 7 unique previously unknown bugs.
Takeaways & Limitations
P2IM enables peripheral-oblivious, hardware-independent dynamic testing of MCU firmware at scale.
Takeaways & Limitations
Advanced interrupt-firing strategies remain the responsibility of the drop-in fuzzer or its operators and are outside P2IM's scope.
Abstract
from arXiv · showhide
Dynamic testing or fuzzing of embedded firmware is severely limited by hardware-dependence and poor scalability, partly contributing to the widespread vulnerable IoT devices. We propose a software framework that continuously executes a given firmware binary while channeling inputs from an off-the-shelf fuzzer, enabling hardware-independent and scalable firmware testing. Our framework, using a novel technique called P$^2$IM, abstracts diverse peripherals and handles firmware I/O on the fly based on automatically generated models. P$^2$IM is oblivious to peripheral designs and generic to firmware implementations, and therefore, applicable to a wide range of embedded devices. We evaluated our framework using 70 sample firmware and 10 firmware from real devices, including a drone, a robot, and a PLC. It successfully executed 79% of the sample firmware without any manual assistance. We also performed a limited fuzzing test on the real firmware, which unveiled 7 unique unknown bugs.
1 Introduction
MCU firmware fuzzing is constrained by the lack of scalable, hardware-independent execution environments. P2IM addresses this by automatically modeling peripheral I/O so firmware can run with an off-the-shelf fuzzer, achieving broad execution coverage and finding unknown bugs.
- MCU firmware contains vulnerabilities comparable in nature to computer-software vulnerabilities, but off-the-shelf fuzzers cannot directly test it.
- Existing approaches either lack complete peripheral emulation or depend on real hardware, making firmware fuzzing slow and difficult to scale.Hybrid emulation forwards peripheral operations to real devices, but hardware dependence limits scalability.
- The framework executes unmodified firmware binaries with AFL while channeling fuzzing inputs and feedback through a generic QEMU-based processor emulator.
- P2IM automatically models peripheral I/O while treating peripherals as black boxes, enabling firmware execution without dependent real or emulated peripherals.Its Processor-Peripheral Interface Equivalence property supports smooth emulated execution without crashes, stalls, or skipped peripheral operations.
- 79% of 70 sample firmware ran continuously without crashes, stalls, or skipped peripheral operations, while testing 10 real-device firmware uncovered 7 unique previously unknown bugs.The real devices included a drone, a robot, and a PLC.
2 Roadmap & Overview
MCU firmware fuzzing is constrained by hardware dependence, diverse peripherals and operating-system designs, and incompatible input interfaces. P2IM addresses these challenges by automatically modeling processor-peripheral interfaces so generic emulation can support scalable, hardware-independent testing.
- Open Challenges: Hardware-dependent firmware fuzzing limits parallelism and introduces orders-of-magnitude delays, preventing the scalability needed for effective fuzzing.Prior approaches forward peripheral operations to hardware, with I/O forwarding reported as three orders of magnitude slower than native I/O.
- Open Challenges: Existing emulators lack generic support for the wide range of MCU peripherals, while diverse OS designs and incompatible peripheral input interfaces hinder reusable fuzzing methods.Firmware reads inputs through heterogeneous peripherals and access conventions, making manually adding support for every interface impractical.
- Our Approach: P2IM provides a drop-in framework that runs unmodified fuzzers with a generic processor emulator and automatically generated peripheral-interface models, without hardware dependence.Its approximate emulators model acceptable interface inputs rather than reproducing peripheral behavior or requiring full peripheral emulation.
- MCU Firmware and Interfaces: MCU firmware includes drivers, system software, and application logic, while firmware I/O uses memory-mapped registers, interrupts, and DMA.The paper focuses on on-chip peripherals and treats memory-mapped registers and interrupts as processor-peripheral interfaces.
- Scope: DMA is outside the method’s scope because it is difficult to model generically and depends heavily on peripheral internals.Only 2 out of 70 tested firmware used DMA, according to the paper.
- Processor-Peripheral Interfaces: P2IM uses Processor-Peripheral Interface Equivalence to model the interfaces expected by firmware rather than the peripherals themselves.The framework verifies that emulated interfaces have an equivalent impact on firmware execution, enabling approximate emulator generation across peripheral varieties.
- Framework Overview: P2IM derives models in two steps: experts define one architecture-class abstract model, then the framework instantiates it for each firmware during execution.The abstract model captures generic access conventions and acceptable inputs, while instantiation adds firmware-specific information and can generate handlers for observed operations.
3 Abstract Model Definition
P2IM defines an abstract, architecture-class model that uses generic register access patterns to identify and handle peripheral interfaces without modeling peripheral internals. It distinguishes register types, feeds fuzzing data through data registers, and dynamically derives status-register values, while leaving input pruning and advanced interrupt strategies to external fuzzers.
- Abstract model: P2IM builds an abstract model for an MCU architecture class, with generic peripheral-register patterns and handling strategies.The ARM Cortex-M model generalizes peripheral registers into four types and is intended as a template for other MCU architectures.
- Register identification: P2IM identifies registers through memory-mapped access patterns, including read-modify-write behavior for control registers and conditional reads for data registers.It treats accessed words in the peripheral-register memory segment as candidate registers and uses empirical access patterns for categorization.
- Status-register handling: Status-register handling dynamically infers values that pass firmware checks and enable subsequent peripheral I/O, rather than modeling peripheral semantics.P2IM categorizes status registers using unconditional reads evaluated in conditions and can correct misclassifications when polling behavior appears.
- Register handling: Data-register reads supply the next fuzzing-input word, while control-register reads return previously written values or zero by default.Data registers are treated as the main fuzzing interface, whereas control registers are modeled as non-volatile memory words.
- Scope and caveats: P2IM can exercise infeasible peripheral inputs and paths, so input pruning remains the responsibility of fuzzers or other testing tools.The framework does not prune potentially infeasible inputs because it is designed to support, rather than control, input-generation tools.
- Scope and caveats: All detected crashes and hangs were reproducible on real hardware except for two false hangs caused by P2IM, while advanced interrupt strategies remain outside its scope.The current interrupt strategy nevertheless produced high firmware code coverage in the evaluation.
4 Automatic Model Instantiation
P2IM automatically instantiates firmware-specific peripheral models during execution, interleaving exploration with fuzzing whenever accesses are unmodeled or unhandled. It identifies registers, associates them with peripherals, derives access handlers, and uses explorative execution to select status-register values that keep firmware progressing.
- Model instantiation: Model instantiation produces a firmware-specific full model from an architecture-level abstract model and adds information needed for processor-peripheral interface equivalence.The instantiated model guides the emulator in identifying and handling firmware I/O operations.
- Model instantiation: Instantiation is fully automatic, on-demand, and interleaved with fuzzing, which resumes when the model stabilizes without requiring a target precision threshold.Each invocation is a round of model instantiation, and multiple rounds can occur throughout testing.
- Instantiated model contents: The instantiated model records identified registers, register locations and types, access strategies, enabled interrupts, and interrupt-firing strategies, but not peripheral configurations or internals.The process relies on a customized QEMU that emulates Cortex-M instructions and a generic interrupt controller rather than MCU peripherals.
- Instantiation workflow: The workflow monitors peripheral-register accesses, categorizes registers, handles accesses, generates missing status-register handlers through explorative execution, and monitors interrupts.Register identification considers accesses to the memory segment reserved for peripheral registers and uses empirically generalized access patterns.
- Register association: P2IM groups registers by spatial adjacency and alignment to reduce ambiguity when handling status-register accesses.The grouping captures peripheral association without requiring knowledge of peripheral types or characteristics.
- Explorative execution: Explorative execution snapshots firmware at a new status-register access, tests candidate values in parallel, and returns the best qualified value to the original execution.The design addresses search-space construction, worker termination, qualification, and the frequency of explorative executions.
- Explorative execution: The search space contains 32+1 candidates for a 32-bit status register: one value for each single set bit plus an all-zero value.This replaces testing all 2^32 possible values and assigns one worker thread to each candidate.
- Explorative execution: SR grouping reduces overhead by avoiding independent explorative executions for every status-register read while retaining firmware-specific handling strategies.Status-register strategies can vary across registers and use sites, motivating both per-context derivation and grouping optimization.
5 Evaluation & Fuzzing Results
P2IM executes most tested firmware without peripheral-specific hardware, while maintaining register-model accuracy and enabling fuzzing of real devices. Its evaluation also identifies failure causes, rare hangs, and previously unknown security bugs.
- Unit Tests: 76% to 92% of registers were categorized accurately across peripherals, with no peripheral type showing substantially better or worse accuracy.The evaluation compared instantiated categorizations against manually extracted datasheet ground truth.
- Unit Tests: 79% (55) of unit tests passed without crashes, stalls, or skipped peripheral operations, compared with 0% for prior generic automatic peripheral modeling.Performance was similar across MCU SoC and OS combinations, suggesting MCU- and OS-agnostic behavior.
- Real Firmware: Most real firmware models were instantiated within 3 rounds, and the resulting models supported execution with Processor-Peripheral Interface Equivalence satisfied.The framework then used these models to fuzz all tested real firmware, with overhead and inaccuracy reported as low enough for practical use.
- Mis-categorizations: 8.2% of registers read by firmware were mis-categorized, but only 2.6% negatively impacted Processor-Peripheral Interface Equivalence.Type-I errors mainly slowed fuzzing, whereas Type-II errors could prevent code paths from being reached or stall firmware execution.
- False Crashes/Hangs: P2IM introduced two hangs on Soldering Iron firmware: one from register mis-categorization and one from DMA usage outside the paper’s modeling scope.Other crashes and hangs found by P2IM were reproduced on real devices with the same inputs and attributed to firmware bugs.
- Fuzzing Results: 7 unique and previously unknown bugs were found after 24 hours of fuzzing each real firmware, and all were confirmed exploitable by manual analysis.The bugs included improper array-index validation, out-of-bounds writes, incorrect numeric conversions, and uncontrolled resource consumption.
6 Discussion
The discussion identifies limitations and extensions of P2IM, including unsupported DMA, potential support for non-ARM architectures, and uses beyond fuzzing.
- Limitations: P2IM does not model Direct Memory Access, limiting support for firmware whose peripherals provide input through DMA.DMA modeling conflicts with P2IM’s peripheral-oblivious design because DMA is complex and peripheral-specific.
- Architectures beyond ARM: P2IM can be extended beyond ARM because non-ARM architectures use comparable memory-mapped peripherals, register categories, and access conventions.The analyzed architectures include AVR, MIPS, and RISC-V, with differences in memory access and interrupt handling requiring extensions.
- Firmware Analysis beyond Fuzzing: The framework can support dynamic analyses beyond fuzzing, including reachability analysis, taint analysis, debugging, and concolic execution.For concolic execution, it can provide realistic concrete inputs, reduce symbolic values, and avoid some infeasible paths.
7 Related Work
Prior dynamic firmware-analysis approaches rely heavily on hardware or expertise, whereas P2IM removes hardware dependence and automates testing at scale.
- Dynamic Firmware Analysis: Hybrid-emulation approaches forward peripheral operations to real devices but remain hardware-dependent, limiting speed and scalability.These approaches include Avatar and its hardware-accelerated successors.
- Dynamic Firmware Analysis: P2IM is largely automated and removes hardware dependency without peripheral I/O forwarding or replaying.The framework also found bugs in real MCU firmware, unlike the previous works discussed.
- Dynamic Firmware Analysis: Fully emulated or directly tested Linux-based devices do not address MCU-specific challenges because Linux-based devices have more diverse emulator support.Their peripheral environments are less diverse than those of MCU devices.
- Static Firmware Analysis: Static symbolic-execution approaches model peripheral reads or forward accesses to hardware, but can face state explosion or hardware dependence.FIE assumes enabled interrupts can occur after every instruction, while Inception can forward peripheral access through Avatar.
8 Conclusion
The paper presents P2IM as a peripheral-oblivious technique that enables scalable, hardware-independent MCU firmware testing and discovers bugs in real devices.
- Conclusion: P2IM models processor-peripheral I/O behaviors to enable peripheral-oblivious emulation of MCU devices.The technique is implemented in a framework that executes firmware binaries and hosts AFL as a drop-in fuzzer.
- Conclusion: 7 new bugs were found in real device firmware when the framework was paired with a limited memory error detector.The paper characterizes these results as evidence of practical value and potential.
A Vulnerability Analysis and PoC: PLC firmware
Fuzzing the PLC firmware exposed an exploitable Modbus buffer overflow that allowed attacker-controlled writes to PLC memory, demonstrated through a proof of concept.
- Vulnerability Findings: 7 bugs found across PLC, Gateway, and Heat Press firmware were confirmed exploitable with proof-of-concept attacks.The PLC case is presented as a representative example.
- PLC Firmware: The PLC firmware implements Modbus RTU over USART and RS485 for communication with an HMI or SCADA system.The tested firmware combines Arduino-based functionality, control logic, and the Modbus communication stack.
- Vulnerability Analysis: A wrong cast in Function Code 15 validation causes a buffer overflow because crafted coil counts can bypass validation.Function Code 15 forces multiple coils and controls the number of coils processed.
- Impact: The vulnerability provides attacker-controlled location and data-write primitives that can overwrite important PLC data structures.The authors verified this capability despite a limited controllable memory span.
- Proof of Concept: The proof of concept used a development board, a USB-to-Serial attacker connection, a crafted Modbus query, and a debugging console.The console confirmed memory was overwritten with an attacker-supplied value.
B Full Results of Unit Tests
The unit-test evaluation reports results across 70 tests, marking 14 combinations as impossible because of MCU SoC and OS/library incompatibility.
- 70 unit tests were evaluated, with 14 marked N/A because their MCU SoC and OS/library combinations were incompatible.
C Firmware Information
The real-firmware evaluation section documents the tested firmware and the information reported for each device. Firmware entries include platform, software, size, source, and product imagery, with some implementation details undisclosed as proprietary.
- The real-firmware evaluation covers end-to-end testing and fuzzing experiments.
- Each firmware entry reports its target MCU, operating system, lines of code, size, source, and product picture.Firmware size refers to the compiled ELF file and may include headers, sections, and debug symbols.
- PLC and machine-control routines are proprietary, while only open-source libraries are disclosed.