Skip to main content
Fuzzing Embedded Firmware

Fuzzing Embedded Firmware — Bootloaders, RTOS, IoT

Embedded firmware is where the worst-case bugs live and the worst tooling lives. Fuzze.rs runs AFL++ and libFuzzer campaigns against unicorn-/qemu-hosted firmware targets — managed.

Embedded firmware is one of the hardest targets to fuzz well: the code runs on hardware you don't have ten copies of, the build chain is bespoke, and the standard ASan + libFuzzer combination doesn't apply. The bugs that hide there are also the most consequential — bootloaders, secure-element interfaces, network stacks running with no exploit mitigations.

Fuzze.rs runs AFL++ and libFuzzer against firmware emulated under unicorn or qemu, in a containerised environment you control. The harness drives the firmware entry point you'd reach in real boot; the fuzzer mutates the data path you care about.

Why it matters

Bootloader and secure-boot fuzzing

The signature-parsing and metadata-parsing paths in bootloaders are the highest-stakes attack surface on the device. Fuzzing them finds the bugs static analysis misses.

Protocol stacks under emulation

BLE, MQTT, CoAP, Zigbee — anything taking bytes off the wire is a natural fuzz target. Emulate the radio interface and fuzz the parser.

No hardware-fleet needed

Emulated firmware runs fast and parallel. One job pinned to qemu-system-arm gives you dozens of parallel executions where one device gives you one.

Reproducible across job runs

Persistent corpora mean coverage compounds. The 80% coverage from week one is the starting point of week two.

Workflow

  1. 1

    Pick the emulation target

    unicorn for tight CPU emulation, qemu-system for a full SoC.

  2. 2

    Write the harness

    Boot the firmware to the entry point you care about; feed input from a known buffer the fuzzer mutates.

  3. 3

    Containerise

    Standard Docker image with your cross-toolchain + emulator. Docs ship a starter for cortex-m and aarch64.

  4. 4

    Run the campaign

    AFL++ with QEMU mode is the default; libFuzzer when you can compile to host with sanitizers.

  5. 5

    Triage and minimise

    Reproducers run under the same emulator config. Single-step the failure path under gdbserver if you need to.

  6. 6

    Re-run on every firmware build

    Wire the campaign into your firmware CI — a new build, a fresh fuzz run.

Fuzzers we’d pick

  • AFL++ + QEMU mode — the most popular setup for binary-only or limited-toolchain firmware.
  • libFuzzer when you can build the firmware as a host shared library with sanitizers.
  • Honggfuzz for protocol stacks where its persistent mode pays off.
Start fuzzing your firmware →

First month 50% off. Cancel anytime.