Skip to content
STIMSMITH

Fuzzware

Tool

Fuzzware is a state-of-the-art grey-box firmware fuzzer that targets ARM/AArch64 firmware via emulation. It uses the Icicle emulation framework, supports crash bucketing and crash replay for triage, and has been used to discover real-world IoT/Bluetooth firmware bugs.

First seen 7/19/2026
Last seen 9/28/2026
Evidence 6 chunks
Wiki v1

WIKI

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.

READ FULL ARTICLE →

NEIGHBORHOOD

7 nodes · 12 edges
graph · Fuzzware · depth=1

RELATIONSHIPS

16 connections
Aurora-Fuzz Configuration Script ← uses 95% 2e
The Aurora-Fuzz Configuration Script automates Fuzzware configuration and can start fuzzing sessions.
Firmware Fuzzing implements → 100% 2e
Fuzzware is a firmware fuzzing tool designed to test embedded firmware binaries.
Aurora-Fuzz ← uses 95% 2e
Aurora-Fuzz is built on top of Fuzzware and automates its configuration process for nRF52 binaries.
The Fuzzware paper introduces the Fuzzware tool for effective firmware fuzzing.
Memory-Mapped I/O (MMIO) uses → 100% 1e
Fuzzware models MMIO accesses to simulate hardware peripheral responses during firmware emulation.
Coverage Feedback uses → 95% 1e
Fuzzware monitors code coverage and uses it as feedback to guide fuzzing.
Raw Input uses → 95% 1e
Fuzzware's fuzzing engine generates raw input bytes that are consumed by MMIO models.
ISA Emulator uses → 95% 1e
Fuzzware uses an ISA emulator to execute firmware as if on real hardware.
Crash Bucket Analysis implements → 95% 1e
Fuzzware has built-in functionality to gather crash buckets mapping crashes based on instruction pointer and link registers.
Crash Trace Replay implements → 95% 1e
Fuzzware has built-in functionality to replay crash traces showing the path taken in the emulator up to the crash.
The study integrates Icicle as the emulator within the Fuzzware fuzzer to replicate prior results.
Icicle uses → 85% 1e
Within the study, the Fuzzware fuzzer is run using Icicle as its emulator backend.
MMIO Modeling implements → 100% 1e
Fuzzware implements precise MMIO modeling to handle hardware peripheral interactions during firmware fuzzing.
ARM targets ISA → 95% 1e
The abstract characterizes Fuzzware specifically as an ARM firmware fuzzer.
Coverage-Guided Fuzzing implements → 95% 1e
Fuzzware uses coverage feedback to guide the fuzzing process.
Emulation-Based Fuzzing implements → 95% 1e
Fuzzware uses an ISA emulator to run firmware in a virtual environment during fuzzing.

CITATIONS

5 sources
5 citations — click to expand
[1] Fuzzware's main repository is fuzzware-fuzzer/fuzzzer on GitHub, implemented primarily in Python, and serves as the entry point to install the tool. fuzzware-fuzzer/fuzzware
[2] Fuzzware uses Icicle as its emulator; the Icicle paper describes porting Fuzzware onto the architecture-agnostic Icicle emulator and replicating prior ARM firmware fuzzing results, with the new instrumentation enabling discovery of new bugs. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[3] Fuzzware targets ARM/AArch64 firmware. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[4] Fuzzware provides built-in crash-bucketing based on instruction pointer and link register, and crash-replay functionality that prints the emulator path (MMIO interactions and basic blocks visited) up to the crash. Low Power, High Risk: Fuzzing the Chips Behind IoT
[5] Practical use shows Fuzzware is effective for finding vulnerabilities but is not 'plug and play'; analysis requires manual work and understanding of memory layouts and assembly, and fuzzing Bluetooth-class devices is slow due to reliance on MMIO for coverage. Low Power, High Risk: Fuzzing the Chips Behind IoT