Emulation-based fuzzing Wiki

Overview

Emulation-based fuzzing is a class of software-security testing in which the target program—typically a firmware binary, embedded application, or other low-level system component—is executed inside an emulator rather than on its native hardware. The fuzzer generates random or mutated inputs, feeds them to the emulated target, observes execution behavior (notably code coverage), and uses that feedback to guide further input generation.

Emulation-based fuzzing is the dominant approach when:

source code is unavailable (closed-source firmware blobs);
the target runs on exotic or difficult-to-source hardware (e.g., microcontroller units, cellular basebands);
on-device testing is too slow, unsafe, or destructive to perform at scale.

Why an emulator?

Unlike conventional user-space targets, embedded firmware:

receives inputs through memory-mapped I/O (MMIO) registers, interrupts, and DMA rather than standard interfaces such as sockets or files;
has no operating system protection, monolithic code layout, and constrained memory;
depends on hardware peripherals whose behavior must be modeled for the firmware to execute meaningfully.

Because of this, a re-hosting step is required: the firmware binary is loaded into an emulator that simulates the CPU and (parts of) the peripherals, allowing the fuzzer to run the firmware off-device at high speed. General-purpose emulators such as QEMU and Unicorn are commonly used as the execution backbone. For example, the Fuzzware framework combines a lightweight program-analysis step, firmware re-hosting, and coverage-guided fuzzing, with a novelty being precise MMIO modeling that consumes chunks of the raw fuzz input and translates them into hardware-generated values served back to the emulated firmware; coverage feedback is then reported to the fuzzing engine. The Hardwear.io 2025 presentation Low Power, High Risk: Fuzzing the Chips Behind IoT describes this pipeline as composed of a fuzzing engine (input generation and coverage monitoring), a raw input byte stream, an MMIO access model, and an ISA emulator that runs the firmware binary as if it were on a real microcontroller.

Instrumentation: the central challenge

Modern fuzzers are coverage-guided: they instrument the target to track which basic blocks or edges have been executed and use this signal to steer mutations toward unexplored code. The quality of an emulation-based fuzzer therefore depends on how cleanly and portably instrumentation can be integrated into the emulator.

Historically, emulation-based fuzzers evolved by re-purposing general-purpose emulators, so fuzzing-specific instrumentation (e.g., coverage tracing, sanitizers, comparison hooks) was layered on in an ad-hoc, ISA-specific way. As the Icicle paper observes:

"The instrumentation techniques added to extract feedback and guide input mutations towards generating effective test cases is at the core of modern fuzzers. But, modern emulation-based fuzzers have evolved by re-purposing general-purpose emulators; consequently, developing and integrating fuzzing techniques, such as instrumentation methods, are difficult and often added in an ad-hoc manner, specific to an instruction set architecture (ISA). This limits state-of-the-art fuzzing techniques to few ISAs such as x86/x86-64 or ARM/AArch64; a significant problem for firmware fuzzing of diverse ISAs."

Fuzzing-specific emulators (Icicle)

Icicle (Chesser et al., 2023) re-thinks emulation for fuzzing by designing a fuzzing-specific, multi-architecture emulation framework from the ground up, so that instrumentation is added once in an architecture-agnostic manner with low execution overhead. Key results reported:

Icicle is plugged in as the emulator for an existing state-of-the-art ARM firmware fuzzer, Fuzzware, and replicates prior results.
New instrumentation made possible by Icicle enabled the discovery of new bugs.
The architecture-agnostic instrumentation reproduces LAVA-M benchmark bugs across diverse ISAs—x86-64, ARM/AArch64, RISC-V, MIPS—confirming the fidelity of the emulation and the efficacy of the instrumentation.
A fuzzing campaign against real-world MSP430 firmware binaries (an ISA previously unsupported in emulation-based fuzzers) discovered 7 new bugs, demonstrating that a fuzzing-native emulator can expand the reach of emulation-based fuzzing to architectures that off-the-shelf general-purpose emulators do not support cleanly.

Cellular baseband fuzzing (BaseSAFE)

BaseSAFE (Hofmann et al., 2020) is one of the earliest published systems to apply emulation-based fuzzing to commercial cellular basebands—closed-source firmware blobs running on a Nucleus RTOS-based MediaTek baseband that parse untrusted data from over-the-air LTE signaling messages before authentication. BaseSAFE performs partial rehosting of the baseband in an emulator for fast, instrumented, off-device fuzzing, and ships a sanitizing drop-in allocator to surface heap-based buffer overflows quickly. Reported throughput reaches hundreds of executions per second per core, and roughly 15k test cases per second in total across cores, on a complex test case. The authors describe BaseSAFE as, to their knowledge, the first use of emulation-based fuzzing for security testing of commercial cellular basebands, and note that its tooling and approaches transfer to other low-level kernels and firmware.

Application domains

Evidence in the literature positions emulation-based fuzzing as the workhorse for several hardware-security-adjacent domains:

Microcontroller / IoT firmware (e.g., nRF52-class low-power Bluetooth SoCs), where on-device fuzzing is impractical due to complex peripheral behavior, timing sensitivity, and the risk of bricking hardware.
Cellular basebands, where the attacker model (rogue base stations) makes pre-authentication parsing bugs especially valuable.
General binary-only and cross-ISA targets, where architecture-agnostic emulation instrumentation removes the need to re-implement fuzzing techniques per ISA.

Limitations and open problems

Faithful modeling of MMIO, interrupts, DMA, and timers is necessary for the firmware to take useful control-flow paths; imprecise models produce shallow fuzzing.
Historically, fuzzing instrumentation has been ISA-specific and bolted onto general-purpose emulators, limiting portability.
Some ISAs (e.g., MSP430) have lacked adequate support in mainstream emulation-based fuzzers until fuzzing-specific emulators such as Icicle arrived.

Related techniques and tools

Fuzzware – ARM firmware fuzzer with precise MMIO modeling; reused as a downstream consumer of the Icicle emulator.
BaseSAFE – emulation-based fuzzing framework for cellular basebands (MediaTek / Nucleus RTOS).
Icicle – fuzzing-specific, multi-architecture emulator with architecture-agnostic instrumentation.
QEMU, Unicorn – general-purpose emulators commonly used as the execution backbone for emulation-based fuzzers.
LAVA-M – bug benchmark used to validate emulation fidelity and instrumentation across ISAs.