Reactive Peripheral Modeling for Faithful Firmware Rehosting

Motivation and approach

• Existing rehosting misses BLE connection and post-connection paths and can create spurious states by treating MMIO and interrupts as arbitrary fuzz inputs, although peripherals are reactive and stateful.The introduction identifies causal interactions among MMIO, DMA, and interrupts, implicit peripheral transitions, and coordination across peripherals as challenges to semantically valid execution.Source: §1 · pp. 1–2

Reactive Peripheral Modeling

• RPM models peripherals with event-condition-action rules derived from hardware manuals, capturing causal event chains and propagating fuzzed inputs through realistic hardware mechanisms.Rules specify triggering events, applicable conditions, and peripheral actions grounded in registers, interrupt lines, DMA descriptors, and, when needed, internal states.Source: §1 · p. 2

Bluezz

• Bluezz implements RPM for BLE stacks, using composable modeling primitives, CMSIS-SVD register layouts, and runtime hooks to dispatch rules that update state, schedule DMA, or fire interrupts.The authors state that they will release Bluezz and a BLE firmware benchmark suite covering major stacks, roles, and protocol phases.Source: §1 · p. 2

Evaluation

• Bluezz achieves over 2.6× basic-block coverage and over 4.9× BLE stack-related basic-block coverage compared to state-of-the-art rehosting approaches.The evaluation spans 18 BLE firmware samples across NimBLE, Zephyr, and the closed-source Nordic SoftDevice; Bluezz systematically exercises scanning, advertising, connection, and data exchange.Source: §1 · p. 2
• Bluezz identifies five previously unknown post-connection vulnerabilities, including improper input validation and double-free bugs, triggerable remotely with malformed over-the-air packets.The reported consequences include denial of service or unstable controller states; all issues were responsibly disclosed, and one has been fixed.Source: §1 · p. 2

Generality

• RPM generalizes beyond BLE: Bluezz models seven peripheral types from another MCU family for Grbl and achieves coverage comparable to state of the art after about four hours of manual rule adaptation.Grbl is a serial-protocol CNC milling firmware tested through its serial interface.Source: §1 · p. 2

2.1 Rehosting-based Firmware Fuzzing

• MCU firmware interacts with peripherals through MMIO, interrupts, and DMA: registers configure, observe, or carry data; interrupts signal asynchronous events; and DMA transfers buffers without CPU byte-by-byte handling.MMIO registers include control, status, and data types, though some registers combine control and status fields.Source: §2.1 · pp. 2–3
• Rehosting emulates peripherals off-device; HAL models [20] ease effort but require identifiable APIs, while hardware-level models better scale but struggle with complex, timing-sensitive, interdependent semantics.Firmware-centric models may miss implicit peripheral behavior, preventing deeper progress; fuzzing internal MMIO values, DMA buffers, or interrupt schedules can explore states unavailable through realistic attacker-controlled interfaces.Source: §2.1 · p. 3

2.2 Realistic Attack Surface for BLE Firmware

• Under the nearby-wireless-adversary model, attackers control over-the-air protocol inputs, not MMIO, DMA descriptors, interrupt schedules, or other internal hardware events.Realistic BLE firmware testing should therefore exercise firmware through over-the-air packets.Source: §2.2 · p. 3
• BLE’s over-the-air attack surface spans scanning/advertising, connection establishment, and post-connection data exchange, where higher-layer service discovery and attribute-access logic processes attacker-controlled packets.Connection and post-connection phases exercise security-relevant logic beyond early discovery.Source: §2.2 · p. 3

3.1 Why Existing Approaches Fail

• Independent interrupt, MMIO, and DMA approximations can cause infeasible interrupts or leave handlers with stale packet data, preventing realistic firmware progress.Firmware expects interrupt delivery, status-register state, and DMA-propagated data to match the same peripheral event.Source: §3.1 · p. 4
• Peripheral events require ordered state transitions: without earlier reception progress, later completion events can corrupt state or break processing of the same packet.Existing symbolic-execution approaches struggle to infer temporal constraints encoded across calls and data flow, and may inject fresh fuzzed data on each read.Source: §3.1 · p. 4
• Firmware-centric models miss hidden cross-peripheral coordination, such as a timer triggering radio reception through PPI, so expected interrupts and BLE logic may never occur.Comparable vendor mechanisms include Silicon Labs’ Peripheral Reflex System and Renesas’ Event Link Controller.Source: §3.1 · pp. 4–5

3.2 Reactive Peripheral Modeling

• RPM models peripherals as stateful reactive systems and uses composable ECA rules to link triggers and conditions to state updates, observable effects, and chained reactions.A peripheral command can change internal state, update status registers or buffers, and raise interrupts; rule actions can also generate events for later rules or other peripherals.Source: §3.2 · p. 5

3.3 RADIO Modeling with RPM

• The RADIO example chains timer- and PPI-triggered reception with sequential RX state changes and ordered packet events that represent DMA progress.Reusable MMIO register-centered templates capture recurring ECA patterns, including implicit internal transitions and cross-peripheral logic.Source: §3.3 · pp. 5–6, Figure 3 · p. 6

4.1 Offline Peripheral Model Construction

• Bluezz combines SVD-derived peripheral structure with reference-manual semantics to build reactive ECA models.SVD files provide register layouts and access properties; manual-derived rules capture events, conditions, and side effects. A register-centric, side-effect-guided process follows behavior through affected registers and runtime signals.Source: §4.1 · pp. 6–7
• Bluezz binds declarative ECA rules to register-indexed handlers that execute peripheral responses when firmware accesses modeled MMIO locations or triggering signals.Handlers can update registers, schedule timers, transfer data, route hardware events across peripherals, and inject interrupts.Source: §4.1 · p. 7

4.2 Runtime Emulation and Fuzzing

• Bluezz fuzzes firmware through mutated BLE packets delivered via the radio peripheral’s reception path, using coverage and crash feedback to guide mutations.At runtime, MMIO accesses dispatch ECA handlers that update state and trigger actions; timers support delayed behavior, and internal events can activate chained rules.Source: §4.2 · pp. 7–8

5 Implementation

• Bluezz integrates its ECA engine into Fuzzware’s harness, reusing Fuzzware’s interrupt and NVIC subsystems for firmware execution.Fuzzware itself builds on the Unicorn engine.Source: §5 · p. 8
• For the Nordic nRF52840, Bluezz models nine commonly used peripherals that existing firmware emulators do not fully support.Python automates SVD-derived peripheral skeleton construction, while C implements the runtime ECA engine, reusable action primitives, and rule binding logic.Source: §5 · p. 8
• The core framework contains over 11K lines of code, and Bluezz generates over 10K lines of nRF52840 peripheral model code, including roughly 2K manually written ECA-rule lines.Most peripheral model structure is generated from SVD files; manual effort primarily encodes behavioral semantics missing from the reference manual.Source: §5 · p. 8

6.1 Experiment Setup.

• The benchmark comprises 18 firmware samples—six each for NimBLE, Zephyr, and closed-source Nordic SoftDevice—covering BLE roles and major protocol functions.Role-aligned input models were derived from captured BLE interaction traces; each fuzzer received one physical CPU core and was run ten times per target.Source: §6.1 · p. 8

6.2 Fuzzing Capability Comparison (RQ1)

• Bluezz is designed to satisfy the compared scalability and practical-fuzzing requirements, but requires MCU-specific peripheral and protocol modeling effort.Unlike generic rehosting, its OTA BLE inputs and reactive peripheral interactions enable exploration of peripheral-intensive firmware and harder-to-trigger protocol states.Source: §6.2 · p. 9

6.3 Fuzzing Coverage Analysis (RQ2)

• Bluezz exercises code across all major BLE protocol phases, while prior fuzzers largely remain in advertising and scanning logic.The fuzzers discover largely disjoint basic-block sets: Bluezz finds more BLE-stack blocks, while Fuzzware tends to explore more non-stack paths. Bluezz without input models quickly plateaus; structured input models and RPM’s ECA rules support protocol logic and keep fuzzed data at the packet-reception interface.Source: §6.3 · pp. 9–11
• Bluezz achieves 4.9× higher stack-related coverage than Fuzzware and 5.9× higher coverage than Hoedur on average across 18 targets.Coverage is the arithmetic mean of per-target relative stack-coverage improvements; Figure 5 reports unique stack-related basic-block coverage over 24-hour runs.Source: §6.3 · p. 9, Figure 5 · p. 10

6.4 Vulnerability Detection Analysis (RQ3)

• Bluezz uncovered 10 unique crashes and confirmed five previously unknown vulnerabilities, all triggered after connection establishment.The five vulnerabilities were disclosed to affected vendors; one had been fixed at the time of writing. Baseline crashes were not attributable to BLE-stack code and arose from malformed or emulation-specific inputs that could not be replayed on real hardware.Source: §6.4 · p. 11

6.5 Generality of RPM (RQ4)

• On Grbl, all three fuzzers achieve comparable code coverage, reaching over 70% coverage and rediscovering two known bugs.This non-BLE serial-protocol firmware benchmark supports RPM’s extension beyond BLE while maintaining fuzzing effectiveness.Source: §6.5 · p. 11
• RPM modeling took 12.5 hours for Nordic nRF52840 and 4.0 hours for STM32F4, with models reusable across firmware on the same MCU platform.The work covered 9 peripherals and 91 ECA rules for nRF52840, versus 7 peripherals and 49 rules for STM32F4; an agent-assisted workflow reduced nRF52840 rule construction and validation from approximately 12.5 hours to approximately 2 hours with human review.Source: §6.5 · pp. 11–12, Table 5 · p. 11

Lessons learnt

• Faithfully modeling reactive peripheral semantics is a prerequisite for meaningful BLE security testing because progression depends on causal coordination among MMIO, interrupts, DMA, and implicit state transitions.Small deviations can stall execution, block valid connection progress, or produce semantically invalid states.Source: §7 · p. 12
• The practically relevant BLE attack surface lies mainly in connected and post-connection states, which require faithful peripheral behavior and protocol-aware input models to reach.Those models must respect protocol state and packet structure to enable connection management, control-PDU handling, and GATT processing.Source: §7 · p. 12
• Identified BLE vulnerabilities expose fragile handling of stateful control traffic, arising from weak control-PDU validation or unsafe assumptions about transitions after malformed packets.The discussion attributes weaknesses to interactions among malformed inputs, delayed protocol effects, and peripheral-driven execution across later connection events.Source: §7 · p. 12

Limitations and future work

• Bluezz still requires human oversight to validate generated peripheral rules and prepare drivers, and future work will automate support and extend evaluation across firmware, SoC vendors, and protocol-driven systems.An agent can generate effective ECA rules, but validation remains important for undocumented or hardware-specific behavior.Source: §7 · p. 12

8 Related Work

• Jan’s BLE rehosting [25] depends on vendor-specific firmware snapshots for Broadcom and Cypress chips and tests only pre-pairing functions; this work reports full-stack BLE testing.The passage characterizes this work as the first to unlock full-stack BLE firmware testing.Source: §8 · p. 12
• Automated Bluetooth memory-safety efforts include reverse engineering, top-down fuzzing, and on-device fuzzing, limited by coverage, OTA omission, or speed, introspection, and scale.Source: §8 · p. 12
• Prior BLE security analyses uncovered flaws in tracking systems, authentication, and pairing through manual analysis and formal verification.Source: §8 · p. 12
• Rehosting has been applied to trusted-execution, cellular-baseband, and Linux-router firmware, while Cortex-M rehosting models peripherals through MMIO [21] or HALs.Source: §8 · p. 12
• HAL rehosting requires time-consuming, error-prone expert replacements and may miss low-level interactions; MMIO approaches using symbolic execution or board specifications may miss complex, timing-sensitive BLE RADIO behavior.This work instead uses event-condition-action modeling to define peripheral behaviors with improved fidelity.Source: §8 · p. 12

9 Conclusion

• RPM and Bluezz model peripherals through event-condition-action semantics, capturing causal event chains, implicit state transitions, and cross-peripheral coordination.The paper presents this as enabling semantically valid firmware execution and fuzzing aligned with practical over-the-air attack vectors.Source: §9 · p. 13
• Bluezz exercises BLE stacks beyond advertising and scanning into connection and post-connection states, uncovering five previously unknown vulnerabilities there.The vulnerabilities were located in post-connection states.Source: §9 · p. 13
• RPM also extends to protocol-driven firmware from another MCU family with manageable manual effort.Source: §9 · p. 13

A Open Science

• The authors plan to release Bluezz source code, experiment scripts and configurations, 18 BLE samples and input models, build artifacts, and reproduction documentation.An anonymous artifact repository is available, and public release is planned upon acceptance.Source: A Open Science · p. 14

B Ethical Considerations

• The work may affect BLE firmware users, developers and SDK maintainers, while providing reproducible analysis resources to researchers and a more robust ecosystem to the community.Source: B Ethical Considerations · p. 14
• Experiments used legitimate public sources in isolation, sent no over-the-air packets, and collected no personal data; vulnerabilities were privately reported without weaponized exploits.When needed, only information required for maintainers to reproduce and fix issues is provided.Source: B Ethical Considerations · p. 14
• The authors judge publication justified because defensive benefits outweigh risks and systematic testing can help developers fix bugs before exploitation.Source: B Ethical Considerations · p. 14

C BLE Protocol Stack

• The controller’s PHY and LL handle radio transmission and advertising, scanning, and connection establishment, while the host’s L2CAP, ATT, and SMP support data transport, attribute access, and security.GATT defines structured data exchange over ATT, while GAP governs discovery, connection, and security procedures; protocols define data exchange and profiles define interoperable behaviors and roles.Source: C BLE Protocol Stack · p. 14, Figure 8 · p. 14
• Link Layer packets include advertising packets such as ADV_IND and connected-data packets; data packets encapsulate L2CAP messages for ATT, SMP, or link-control signaling.L2CAP signaling supports operations such as connection parameter updates.Source: C BLE Protocol Stack · p. 14, Figure 9 · p. 15

D ECA Action Primitives

• ECA rules organize events as triggers, conditions as guards, and actions as reusable runtime primitives modeling MMIO, interrupts, timers, counters, DMA-like transfers, and inter-peripheral routing.The implementation supports common peripherals such as RADIO, TIMER, DMA, and IRQ controllers, and the action layer can be extended with additional primitives.Source: D ECA Action Primitives · p. 15
• Thirteen action primitives support register and bitfield updates, timers and counters, packet transfers, interrupt control, and routing hardware EVENTS to TASKS.Packet actions read or write buffers at specified addresses and can start or stop reception and transmission; interrupt actions raise, enable, or disable device interrupts.Source: D ECA Action Primitives · p. 15
• Primitive parameters can reference register or bitfield names, constants, or user-defined global variables shared across rules.Source: D ECA Action Primitives · p. 15

• Table 6 summarizes the BLE firmware use cases covered by Bluezz.Source: Table 6 · p. 15, E Covered Use Cases of BLE Firmware… · p. 15

F Extended Venn Diagrams for Stack-related Basic Blocks

• Figure 10 shows Bluezz and Fuzzware’s discovered BLE stack-related basic blocks against the overall stack-related blocks for targets omitted from Figure 6.Bluezz is red, Fuzzware is blue, and overall BLE stack-related firmware blocks are yellow.Source: F Extended Venn Diagrams for… · p. 15, Figure 10 · p. 16
• Hoedur’s results are omitted because they are highly similar to Fuzzware’s for these targets.The figure excludes them due to page-limit constraints.Source: Figure 10 · p. 16