Skip to content
STIMSMITH

Emulation-based fuzzing

Technique

Emulation-based fuzzing is a technique for security testing that executes firmware or other binary-only targets inside an instruction-set emulator (e.g., QEMU, Unicorn, or a custom emulator such as Icicle) instead of on real hardware. It is widely used for embedded systems, microcontroller firmware, and cellular basebands, where on-device testing is slow, impractical, or destructive. Modern emulation-based fuzzers add coverage-feedback instrumentation directly inside the emulator to guide input mutation, but historically such instrumentation has been bolted on in an ISA-specific, ad-hoc manner, restricting state-of-the-art fuzzing techniques to a few ISAs (x86/x86-64, ARM/AArch64). New fuzzing-specific emulators such as Icicle add instrumentation once in an architecture-agnostic way, enabling coverage-guided fuzzing across diverse ISAs including RISC-V, MIPS, and MSP430, and have been used to discover new bugs in real-world MSP430 firmware and to replicate results of ARM firmware fuzzers such as Fuzzware.

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

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:

READ FULL ARTICLE →

NEIGHBORHOOD

3 nodes · 3 edges
graph · Emulation-Based Fuzzing · depth=1

RELATIONSHIPS

4 connections
Fuzzware ← implements 95% 1e
Fuzzware uses an ISA emulator to run firmware in a virtual environment during fuzzing.
QEMU uses → 90% 1e
Emulation-based fuzzing uses QEMU to simulate firmware in virtual environments.
Unicorn Engine uses → 90% 1e
Emulation-based fuzzing uses Unicorn Engine to simulate firmware in virtual environments.
The abstract opens by describing the role and benefits of emulation-based fuzzers.

CITATIONS

12 sources
12 citations — click to expand
[1] Emulation-based fuzzers enable testing binaries without source code and facilitate testing embedded applications where automated execution on the target hardware architecture is difficult and slow. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[2] Modern emulation-based fuzzers evolved by re-purposing general-purpose emulators, so instrumentation is added in an ad-hoc, ISA-specific manner, limiting state-of-the-art techniques to x86/x86-64 and ARM/AArch64. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[3] Icicle is a fuzzing-specific, multi-architecture emulation framework that allows instrumentation to be added once in an architecture-agnostic manner with low execution overhead. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[4] Using Icicle as the emulator for Fuzzware replicates prior ARM firmware fuzzing results, and new instrumentation enabled by Icicle led to the discovery of new bugs. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[5] Icicle reproduces LAVA-M benchmark bugs across x86-64, ARM/AArch64, RISC-V, and MIPS, demonstrating emulator fidelity and architecture-agnostic instrumentation. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[6] Fuzzing real-world MSP430 firmware binaries with Icicle discovered 7 new bugs, demonstrating reach to an ISA previously unsupported in emulation-based fuzzers. Icicle: A Re-Designed Emulator for Grey-Box Firmware Fuzzing
[7] Fuzzing automates security testing by sending malformed inputs to uncover bugs; embedded/firmware fuzzing uses inputs delivered via hardware peripherals (MMIO, interrupts, DMA). Low Power, High Risk: Fuzzing the Chips Behind IoT (Hardwear.io 2025)
[8] Emulation/re-hosting simulates firmware in virtual environments such as QEMU or Unicorn to enable fuzzing without physical hardware. Low Power, High Risk: Fuzzing the Chips Behind IoT (Hardwear.io 2025)
[9] On-device fuzzing of low-power Bluetooth IoT MCUs such as nRF52 is impractical due to slow speed and risk of damage; emulation-based re-hosting is therefore essential. Low Power, High Risk: Fuzzing the Chips Behind IoT (Hardwear.io 2025)
[10] Fuzzware combines lightweight program analysis, firmware re-hosting, and coverage-guided fuzzing, with precise MMIO modeling that focuses on meaningful hardware-generated values; its main components are a fuzzing engine, raw input, MMIO access model, ISA emulator, and coverage feedback. Low Power, High Risk: Fuzzing the Chips Behind IoT (Hardwear.io 2025)
[11] BaseSAFE enables partial rehosting of cellular basebands for fast, instrumented, off-device fuzzing of closed-source firmware blobs and is, to the authors' knowledge, the first use of emulation-based fuzzing for security testing of commercial cellular basebands. BaseSAFE: Baseband SAnitized Fuzzing through Emulation
[12] BaseSAFE's sanitizing drop-in allocator surfaces heap-based buffer overflows quickly; its emulator instrumentation reaches hundreds of executions per second per core and around 15k test cases per second in total. BaseSAFE: Baseband SAnitized Fuzzing through Emulation