Skip to content
STIMSMITH

Firmware Fuzzing

Technique

Firmware fuzzing is a class of dynamic security testing techniques that exercise embedded/IoT firmware binaries to discover vulnerabilities. Modern approaches face challenges such as architecture diversity, lack of source code, missing hardware peripherals, and closed-source third-party components; these have motivated emulator-based greybox fuzzing (e.g., Fuzzware, Icicle), directed greybox fuzzing (e.g., BullsEye), and side-channel-informed black-box fuzzing (e.g., PowerFuzz).

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

WIKI

Firmware Fuzzing

Overview

Firmware fuzzing is a dynamic analysis technique that exercises firmware binaries—typically those running on resource-constrained IoT or embedded devices—with generated or mutated inputs to discover crashes, memory corruptions, and other vulnerabilities. Because firmware images frequently lack source code, target unfamiliar instruction set architectures (ISAs), and depend on peripherals and hardware behavior that are difficult to model, firmware fuzzing has evolved into a distinct subfield of binary fuzzing.

READ FULL ARTICLE →

NEIGHBORHOOD

3 nodes · 3 edges
graph · Firmware Fuzzing · depth=1

RELATIONSHIPS

7 connections
Fuzzware ← implements 100% 2e
Fuzzware is a firmware fuzzing tool designed to test embedded firmware binaries.
Memory-Mapped I/O (MMIO) uses → 95% 1e
Firmware fuzzing delivers inputs via MMIO registers, interrupts, and DMA rather than standard interfaces.
interrupt uses → 90% 1e
Firmware fuzzing delivers inputs via interrupts.
DMA uses → 90% 1e
Firmware fuzzing delivers inputs via DMA.
UICR uses → 85% 1e
Firmware fuzzing of nRF52 devices involves UICR MMIO memory sections that must be configured.
FICR uses → 85% 1e
Firmware fuzzing of nRF52 devices involves FICR MMIO memory sections that must be configured.
The abstract highlights challenges specific to firmware fuzzing across diverse ISAs.

CITATIONS

17 sources
17 citations — click to expand
[1] Firmware fuzzing is a class of dynamic security testing techniques that exercise embedded/IoT firmware binaries to discover vulnerabilities. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[2] Modern emulation-based fuzzers have re-purposed general-purpose emulators, so instrumentation is added in an ad-hoc, ISA-specific manner, limiting state-of-the-art fuzzing techniques to a few ISAs. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[3] Icicle is a fuzzing-specific, multi-architecture emulation framework that implements instrumentation once in an architecture-agnostic way with low execution overhead. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[4] Icicle replicates Fuzzware's results when used as the emulator for the Fuzzware ARM firmware fuzzer and enabled the discovery of new bugs. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[5] Icicle reproduced LAVA-M benchmark bugs across diverse ISAs (x86-64, ARM/AArch64, RISC-V, MIPS). Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[6] A fuzzing campaign with Icicle on real-world MSP430 firmware binaries discovered 7 new bugs. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[7] Fuzzware combines a fuzzing engine, an ISA emulator, an MMIO access model, and coverage feedback; chunks of raw input are translated by MMIO access models into hardware-generated values served to the emulated firmware. Low Power, High Risk: Fuzzing the Chips Behind IoT (Hardwear.io PDF, citing Fuzzware/USENIX Security '22)
[8] When applied to nRF52 firmware, Fuzzware's automatic configuration tool did not produce a valid memory map and omitted FICR/UICR MMIO sections, preventing emulation; manual configuration enabled emulation but was slow and crash-prone. Low Power, High Risk: Fuzzing the Chips Behind IoT (Hardwear.io PDF)
[9] Useful configuration refinements in practice include adding static/constant MMIO reads in the bootloader, patching delay functions, and patching 'wait-for-flag' conditions. Low Power, High Risk: Fuzzing the Chips Behind IoT (Hardwear.io PDF)
[10] The Aurora-Fuzz configuration script automates Fuzzware configuration for nRF52 binaries with features such as memory-map editing, Softdevice MMIO filtering, UICR/FICR loading, boot/interrupt/exit modification, configuration saving, testing, and starting fuzzing sessions. Low Power, High Risk: Fuzzing the Chips Behind IoT (Hardwear.io PDF)
[11] BullsEye is the first Directed Grey-Box Fuzzing framework to schedule closed-source Linux-based firmware fuzzing by basic-block-level distance to user-specified targets. BullsEye: Directed Firmware Fuzzing
[12] BullsEye combines static and dynamic analysis to enable DGF in the firmware domain, introduces novel DGF heuristics, and targets vulnerabilities in reused third-party components. BullsEye: Directed Firmware Fuzzing
[13] On 40 vulnerability sites across 32 firmware images, BullsEye reproduced every target within budget, versus 35 for the strongest of four greybox-fuzzing baselines, with a 9.5× to 72.5× geometric-mean reduction in Time-to-Exposure. BullsEye: Directed Firmware Fuzzing
[14] Against GREENHOUSE on the 18 targets its pipeline supports, BullsEye was faster by a geometric mean of 9.8×. BullsEye: Directed Firmware Fuzzing
[15] PowerFuzz is a statistical black-box firmware fuzzing framework that uses power side-channel measurements instead of binary instrumentation to obtain coverage. PowerFuzz: Power-Based Black-Box Firmware Fuzzing
[16] PowerFuzz uses a sliding-window followed by a growing-window full-trace correlation method to identify branches from power traces and constructs a high-level control-flow graph to drive the fuzzer. PowerFuzz: Power-Based Black-Box Firmware Fuzzing
[17] Across three embedded hardware platforms and ten firmware benchmarks, PowerFuzz achieves branch coverage within 13.5% of grey-box fuzzers while outperforming state-of-the-art black-box fuzzers by up to 22%. PowerFuzz: Power-Based Black-Box Firmware Fuzzing