Source-linked AI summary
Reactive Peripheral Modeling for Faithful Firmware Rehosting
Qinying Wang, Florian Hofhammer, Eduard Vlad, Jianqiang Wang, Marcel Busch, Shouling Ji, Mathias Payer
TL;DR
Existing rehosting approaches struggle to faithfully model reactive peripheral behavior and reach deep, attacker-relevant protocol states. The paper introduces Reactive Peripheral Modeling (RPM) and implements it in Bluezz, which exercises connected BLE states across 18 targets, achieves over 2.6× basic-block coverage, and finds five previously unknown vulnerabilities.
Problem
Existing rehosting approaches often approximate interrupts, MMIO, DMA, peripheral state transitions, and cross-peripheral dependencies, limiting access to deep firmware states.
Method
RPM models peripherals as reactive systems using event-condition-action semantics, and Bluezz applies this abstraction to BLE firmware rehosting and fuzzing.
Results
Across 18 BLE targets, Bluezz achieves over 2.6× basic-block coverage, exercises connected and post-connection states, and identifies five previously unknown vulnerabilities.
Takeaways & Limitations
Faithful reactive peripheral modeling is presented as a prerequisite for meaningful BLE security testing and realistic exploration of connected attack surfaces.
Takeaways & Limitations
Bluezz trades breadth for semantic fidelity, requiring additional effort to model MCU-specific peripheral behaviors and protocol semantics.
Abstract
from arXiv · showhide
Rehosting enables tight control and introspection for firmware testing, but existing approaches largely fail to reach deeper application states and cannot drive embedded protocol stacks beyond early-stage initialization. This limitation reflects a broader weakness in current rehosting techniques: their inability to faithfully model complex peripheral semantics and dependencies. In particular, existing work typically relies on passive approximations of peripheral behavior and overlooks three key aspects: (i) the interplay among interrupts, MMIO, and DMA; (ii) implicit state transitions within peripherals; and (iii) interactions across multiple peripherals. To address this challenge, we propose Reactive Peripheral Modeling (RPM), an abstraction that models hardware peripherals as reactive and stateful systems. RPM captures peripheral behavior using event-condition-action semantics, enabling faithful representation of interrupt, MMIO, and DMA scheduling, implicit state transitions, and cross-peripheral interactions. We implement RPM in Bluezz for BLE firmware rehosting and fuzzing, and show that reactive modeling is necessary to reach deep protocol states. We evaluate Bluezz on representative BLE stacks, including NimBLE, Zephyr, and Nordic SoftDevice, a closed-source commercial stack. Across 18 targets, Bluezz achieves an average basic-block coverage more than 2.6 times that of prior state-of-the-art rehosting approaches. Unlike prior approaches, which remain largely confined to advertising and scanning logic, Bluezz reliably exercises connected BLE states and uncovers five previously unknown vulnerabilities that manifest only after connection establishment. Finally, we show that RPM generalizes beyond BLE to other embedded firmware running on different MCUs.
1 Introduction
Existing firmware rehosting often cannot reach connection and post-connection BLE states because it models peripherals without their reactive dependencies. RPM addresses this gap with event-condition-action peripheral models, and Bluezz substantially improves coverage, vulnerability discovery, and cross-platform applicability.
- Motivation: Existing rehosting approaches rarely progress beyond BLE advertising and scanning, leaving connection and post-connection attack surfaces difficult to explore.These approaches also expose MMIO values and interrupt schedules as generic fuzzing inputs, despite those interfaces not being attacker-controlled.
- Approach: RPM models peripherals as reactive systems using event-condition-action semantics for causal hardware events, implicit state transitions, and cross-peripheral coordination.The abstraction captures dependencies among MMIO, interrupts, DMA, and multiple peripherals.
- Implementation: Bluezz implements RPM with composable peripheral primitives and protocol-aware input models for rehosting and fuzzing diverse BLE stacks, including closed-source stacks.Its evaluation covers NimBLE, Zephyr, and Nordic SoftDevice across 18 BLE firmware samples.
- Evaluation: Over 2.6× basic-block coverage and over 4.9× BLE stack-related basic-block coverage are achieved versus state-of-the-art rehosting approaches.Bluezz systematically exercises scanning, advertising, connection, and data-exchange phases.
- Evaluation: Five previously unknown vulnerabilities are uncovered in post-connection states, including improper input validation and double-free bugs triggered by malformed over-the-air packets.The issues can lead to denial of service or unstable controller states; all were responsibly disclosed and one was fixed.
- Generality: RPM generalizes beyond BLE: on Grbl firmware from a different MCU family, it reaches coverage comparable to the state of the art after about four hours of manual rule adaptation.The result supports extensibility beyond BLE with manageable manual effort.
2 Background
Embedded firmware communicates with hardware peripherals through MMIO, interrupts, and DMA, while rehosting emulates those interactions off-device. For BLE, realistic testing must use over-the-air packets across scanning, connection establishment, and data exchange phases.
- Embedded peripherals: MCU firmware relies on peripherals such as timers, radios, and UARTs to interact with the physical environment and external devices.These peripherals support communication and hardware-mediated execution.
- Peripheral interfaces: Firmware primarily interacts with peripherals through memory-mapped I/O, interrupts, and direct memory access.MMIO configures hardware, issues commands, and exposes status through peripheral registers.
- Firmware rehosting: Firmware rehosting executes code off-device in a virtual environment while emulating peripherals to advance execution.High-level approaches redirect HAL calls, whereas hardware-layer approaches model mechanisms such as MMIO, interrupts, and DMA.
- Threat model: The BLE threat model gives an over-the-air adversary control of protocol-level wireless inputs, but not MMIO registers, DMA descriptors, or interrupt schedules.This constrains realistic fuzzing inputs to packet-level interactions.
- BLE attack surface: BLE communication proceeds through scanning and advertising, connection establishment, and post-connection data exchange.Connection and post-connection phases exercise security-relevant logic beyond early discovery.
3 Motivation and New Modeling Paradigm
Existing hardware-layer rehosting fails to preserve the causal, ordered, and cross-peripheral semantics that BLE firmware expects. RPM addresses this gap by modeling peripherals as stateful reactive systems expressed through composable Event-Condition-Action rules.
- Why Existing Approaches Fail: Existing emulators approximate hardware behavior and struggle with complex, timing-sensitive, interdependent peripheral behavior.
- Why Existing Approaches Fail: Interrupt delivery must remain consistent with peripheral events, interrupt configuration, MMIO status, and DMA-propagated data.Otherwise, firmware may process stale or invalid data, preventing realistic packet handling and execution progress.
- Why Existing Approaches Fail: Peripheral events must be modeled as ordered state transitions because later events become meaningful only after earlier events update peripheral and firmware state.The BLE receive path illustrates this dependency: packet reception must advance PHY state before a valid completion interrupt can trigger further processing.
- Why Existing Approaches Fail: Cross-peripheral coordination must capture hardware-level event propagation, such as timers triggering radio activity through PPI without firmware intervention.
- Reactive Peripheral Modeling: RPM represents peripheral behavior with composable Event-Condition-Action rules that encode triggers, conditions, state changes, interrupts, and chained reactions.Events can originate from firmware or peripherals, while actions can generate subsequent events and activate additional rules.
- Reactive Peripheral Modeling: RPM treats peripherals as stateful reactive systems whose observable behavior evolves across commands, status updates, buffers, and interrupts.
4 Design of Bluezz
Bluezz constructs RPM-based peripheral models offline from hardware artifacts, then loads them into an emulator that translates firmware interactions into reactive hardware behavior during fuzzing. Its runtime combines generated ECA handlers, modeled state updates, interrupts, DMA-related actions, and realistic BLE packet injection with coverage-guided exploration.
- Overview: Bluezz uses a two-phase workflow: offline peripheral model construction followed by emulation and fuzzing.Models are built from hardware manuals and SVD files, then loaded into the runtime emulator.
- Offline Peripheral Model Construction: CMSIS-SVD files provide machine-readable register layouts, address mappings, bit fields, and access permissions for constructing peripheral-model skeletons.
- Offline Peripheral Model Construction: ECA rule generation enriches the SVD-derived skeleton with events, register-state conditions, and reusable actions such as register updates, timers, data transfers, and interrupts.Rules are derived by inspecting control-register behavior and side effects described in the reference manual.
- Offline Peripheral Model Construction: Bluezz automatically binds symbolic ECA register references to concrete SVD-derived fields and predefined execution primitives.
- Runtime Emulation and Fuzzing: At runtime, Bluezz intercepts MMIO accesses, updates modeled register state, and dispatches associated ECA handlers; timers and chained actions support delayed and cascading behavior.
- Runtime Emulation and Fuzzing: Bluezz injects mutated BLE packets through modeled radio-reception behavior and uses coverage and crash feedback to guide subsequent mutations.The generated peripheral model keeps firmware-visible values tied to prior commands and ECA executions rather than arbitrary internal-register perturbations.
5 Implementation
Bluezz is implemented on Fuzzware and Unicorn for the Nordic nRF52840, integrating an ECA engine with existing interrupt and NVIC support. The implementation models nine commonly used peripherals that existing firmware emulators do not fully support.
- Implementation: Bluezz integrates its ECA engine into Fuzzware’s harness, reusing Fuzzware’s interrupt and NVIC subsystems for firmware execution.
- Implementation: Bluezz targets the Nordic nRF52840 board and models nine commonly used peripherals not fully supported by existing firmware emulators.
6 Evaluation
Bluezz is evaluated across diverse BLE stacks and targets, showing stronger coverage, deeper protocol exploration, vulnerability discovery, and generalization beyond BLE. The evaluation also measures modeling effort and reuse across MCU platforms.
- 6.1 Experiment Setup: Bluezz is evaluated on 18 firmware samples spanning NimBLE, Zephyr, and closed-source Nordic SoftDevice BLE stacks.The samples cover scanners, advertisers, centrals, peripherals, GATT clients, GATT servers, and major BLE protocol functions.
- 6.3 Fuzzing Coverage Analysis: The evaluation compares Bluezz with Fuzzware and Hoedur using BLE-stack-related basic-block coverage as the primary attack-surface metric.The metric avoids misleading coverage from unrealistic or non-BLE execution paths.
- 6.3 Fuzzing Coverage Analysis: 4.9× higher stack-related coverage than Fuzzware and 5.9× higher than Hoedur are achieved by Bluezz on average across the 18 targets.Fuzzware and Hoedur generally remain confined to advertising and scanning, while Bluezz processes packets sequentially and reaches connected protocol logic.
- 6.3 Fuzzing Coverage Analysis: Bluezz without input models quickly plateaus, indicating that rehosting alone does not sufficiently explore complex BLE protocol logic.The input models provide grammar and state dependencies while RPM rules constrain fuzzing to packet reception rather than arbitrary internal hardware interfaces.
- 6.4 Vulnerability Detection Analysis: Five previously unknown vulnerabilities were confirmed among 10 unique crashes, and all five occurred in post-connection BLE states.Baseline crashes were largely stack-unrelated and often arose from malformed or emulation-specific inputs that could not be replayed on real hardware.
- 6.5 Generality of RPM: All three fuzzers exceeded 70% coverage on Grbl and rediscovered two known bugs, while RPM modeling effort remained reusable per MCU platform.For Nordic nRF52840, modeling required 12.5 hours for 9 peripherals and 91 ECA rules; agent assistance reduced this to approximately 2 hours.
7 Discussion
The evaluation shows that faithful reactive peripheral modeling is necessary to reach connected BLE states and expose deeper attack surfaces. Automating rule generation may help scale RPM, but validating rules and preparing drivers still require human oversight.
- Lessons learnt: Faithful reactive peripheral semantics are a prerequisite for meaningful BLE security testing beyond shallow protocol phases.Progression into attacker-relevant states depends on coordinated MMIO effects, interrupts, DMA activity, and implicit peripheral transitions.
- Lessons learnt: Connected and post-connection states contain practically relevant BLE attack surface that shallow advertising and scanning fuzzing leaves unexplored.Reaching these states requires protocol-aware input models as well as faithful peripheral behavior.
- Future work: Generated rules can reduce manual model construction, but validating them and preparing drivers for undocumented or hardware-specific behavior still require human oversight.Further automation is proposed to reduce support costs and improve RPM scalability.
8 Related Work
Prior Bluetooth security analysis includes reverse engineering, top-down fuzzing, on-device fuzzing, and BLE rehosting, but these approaches face coverage, scalability, introspection, threat-model, or protocol-state limitations.
- Bluetooth security analysis: Reverse engineering and on-device fuzzing have limited coverage, slow testing, weak introspection, or poor scalability for Bluetooth implementations.The passage also characterizes top-down fuzzing as overlooking over-the-air threat models.
- Bluetooth security analysis: Prior BLE rehosting relies on vendor-specific debugging features available only on Broadcom and Cypress chips, limiting scalability.This approach also tests only a small set of initial functions available before device pairing.
- Bluetooth security analysis: Existing approaches leave a gap in full-stack BLE firmware testing because their analysis remains constrained to early protocol stages or narrow hardware support.The passage positions Bluezz against these limitations without providing the subsequent comparison details.
9 Conclusion
The paper concludes that RPM and Bluezz make BLE firmware execution more semantically valid and extend testing into connected states. It also reports post-connection vulnerability findings, broader MCU applicability, released artifacts, and a defensive publication rationale.
- 9 Conclusion: RPM models peripherals as reactive systems using event-condition-action semantics, capturing causal chains, implicit transitions, and cross-peripheral coordination.Bluezz uses this model to align fuzzing with practical over-the-air attack vectors.
- 9 Conclusion: Five previously unknown vulnerabilities were found in post-connection BLE states as Bluezz exercised stacks beyond advertising and scanning.The conclusion states that Bluezz systematically reaches connection and post-connection states.
- 9 Conclusion: RPM generalized to protocol-driven firmware from another MCU family with manageable manual effort, while the project released code, scripts, benchmarks, datasets, and documentation.The artifacts include 18 BLE samples and their input models.
- 9 Conclusion: The research was published because its defensive benefits were judged to outweigh risks, with weaponized exploits withheld and responsible reporting emphasized.The stated goal is to improve BLE firmware reliability and security through systematic testing and reproducible evaluation.
C BLE Protocol Stack
BLE stacks are organized into controller and host layers, while packets are encapsulated across Link Layer, L2CAP, ATT, and SMP components. Link Layer traffic distinguishes advertising from active-connection data packets.
- BLE stack layers: The BLE stack has controller and host layers: the controller contains PHY and LL, while the host includes L2CAP, ATT, and SMP.PHY and LL handle radio transmission and low-level link management, including advertising, scanning, and connection establishment.
- BLE packet structure: Link Layer packets are categorized primarily as advertising packets or data packets used during active connections.The figure caption identifies the packet structure as including both advertising and data packets.
- BLE packet structure: Link Layer data packets encapsulate L2CAP packets carrying ATT, SMP, or L2CAP signaling messages for link control.This layering connects active-connection traffic to upper-layer attribute, security, and control procedures.
D ECA Action Primitives
The system supports declarative Event–Condition–Action rules through reusable action primitives. These primitives modify state, control timing and packet I/O, manage interrupts, and route hardware events to tasks.
- ECA rule structure: ECA rules organize execution around triggering events, guard conditions, and reusable runtime actions.Events define when rules trigger, conditions define predicates, and actions use runtime primitives.
- Primitive set: The system provides thirteen types of action primitives for implementing ECA rule behavior.
- State and timing: State primitives update registers, flags, or bitfields through assignment, arithmetic, and bitwise operations.The update_field primitive supports set, add, decrease, or, and, and not operations.
- State and timing: Timing and packet primitives start or stop timers, counters, packet reception, and packet transmission.Packet actions write or read buffers using specified addresses and lengths.
- Hardware interaction: Interrupt and event-routing primitives disable device interrupt sources and connect hardware EVENTS to TASKS.Actions can reference registers, bitfields, constants, or user-defined global variables for shared rule state.
E Covered Use Cases of BLE Firmware Samples
Table 6 summarizes the BLE firmware use cases covered by Bluezz. The table specifically concerns covered use cases across BLE firmware samples.
- Covered use cases: Table 6 summarizes the use cases covered by Bluezz.
- Covered use cases: The section presents coverage information as a table rather than enumerating individual use cases in the surrounding text.
- Covered use cases: The covered-use-case summary concerns BLE firmware samples.
F Extended Venn Diagrams for Stack-related Basic Blocks
The paper provides extended Venn diagrams for BLE-stack-related basic blocks across additional evaluation targets. Bluezz, Fuzzware, and overall BLE-stack firmware blocks are shown using distinct colors.
- Extended coverage comparison: Figure 10 presents extended Venn diagrams for targets not included in the main evaluation’s Figure 6.
- Extended coverage comparison: The diagrams compare BLE stack-related basic blocks discovered by Bluezz and Fuzzware against the overall BLE-stack firmware blocks.
- Diagram encoding: Bluezz is shown in red, Fuzzware in blue, and overall BLE-stack basic blocks in yellow.
- Diagram scope: Hoedur’s results are omitted because they are highly similar to Fuzzware for these targets and space is limited.