Fuzzware

Overview

Fuzzware is a grey-box emulation-based fuzzer for embedded firmware, maintained at the repository fuzzware-fuzzer/fuzzware on GitHub and written primarily in Python. It is designed to test firmware binaries without requiring source code, and to handle cases where automated execution on real target hardware is difficult and slow.

Architecture and Emulator

Fuzzware's original emulator has been replaced by Icicle, a fuzzing-specific, multi-architecture emulation framework introduced in the paper Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing. Icicle is designed so that instrumentation can be added once in an architecture-agnostic manner with low execution overhead, which is a different approach from re-purposing general-purpose emulators where instrumentation ends up being added in an ISA-specific, ad-hoc way.

Using Icicle as the emulator, the Fuzzware team was able to replicate prior ARM firmware fuzzing results and, importantly, the new instrumentation available in Icicle enabled the discovery of new bugs.

Target ISA

Fuzzware specifically targets ARM / AArch64 firmware. This is the only ISA relationship explicitly supported by the evidence, and reflects Fuzzware's original design as an ARM firmware fuzzer that was later ported onto the architecture-agnostic Icicle emulator.

Crash Analysis Workflow

Fuzzware includes built-in functionalities that aid in crash triage:

1. Gather crash buckets
   • Maps crashes based on their instruction pointer (EIP/PC) and link register (LR).
   • Creates replayable paths for each unique crash signature.
2. Replay crash traces
   • Outputs the path taken in the emulator up until the crash, including:
     • MMIO (memory-mapped I/O) interactions, and
     • The sequence of code basic blocks visited.
   • Provides an initial overview of each crash before manual root-cause analysis.

A representative trace snippet shows typical ARM Cortex-M-style execution — for example, calls into nrfx_coredep_delay_us / nrfx_coredep_delay_ms with link registers like 0x266b9, stack-relative reads/writes on addresses such as 0x2003ffbc (SP-relative), and basic blocks at addresses such as 0x0002641c, 0x00026428, 0x000266b0, and 0x0003e850. The instruction pointer (EIP/PC) indicates which instruction the CPU is to execute next.

Practical Observations from Real-World Use

Experience reports from applying Fuzzware to IoT/Bluetooth firmware (Hardwear.io presentation, Low Power, High Risk: Fuzzing the Chips Behind IoT) note:

• Fuzzware is effective at finding vulnerabilities but lacks some usability aspects — it is not "plug and play."
• Even with workflow improvements, output analysis still requires manual work and a good understanding of memory layouts and assembly instructions.
• Fuzzing Bluetooth-class devices is time-consuming due to heavy reliance on MMIO communication, which is needed to obtain good coverage.
• There can be a thin line between legitimate functionality and a security flaw in the protocols/configurations involved.

Related Work

• Icicle — the multi-architecture, fuzzing-oriented emulator that Fuzzware now uses in place of its original emulator.
• Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing — the paper (Chesser et al., arXiv:2301.13346v2, 2023) describing Icicle and the port of Fuzzware onto it.

References

• Fuzzware main repository: https://github.com/fuzzware-fuzzer/fuzzware
• Chesser et al., Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing, arXiv:2301.13346v2.
• Holmdin & Borgaonkar, Low Power, High Risk: Fuzzing the Chips Behind IoT, Hardwear.io presentation.