Firmware emulation — Firmadyne, FirmAE, QEMU

Firmware emulation — Firmadyne, FirmAE, QEMU

TL;DR: Most consumer routers / IoT / camera firmware can be emulated end-to-end on a Linux host with QEMU + a stub kernel and a NVRAM library that mocks vendor-specific hardware accesses. Frameworks like Firmadyne and FirmAE automate this. Lets you reach the web management interface and binary services dynamically, attach a debugger, and fuzz — without owning the physical device. Companion to firmware-extraction and firmware-audit-methodology.

Why emulate

  • No physical device needed — research on devices you can’t afford or don’t physically have.
  • Snapshots — revert instantly after a crash.
  • Debugger access — attach gdb via QEMU’s gdbstub.
  • Fuzzing — drive the emulated binary with AFL++ / boofuzz / Mayhem.
  • Scale — emulate many firmware images in parallel for n-day hunting.

The emulation challenge

Embedded firmware:

  • Targets architectures like MIPS (big- and little-endian), ARM, PowerPC, SuperH.
  • Calls into vendor-specific kernel drivers and IOCTLs.
  • Reads / writes NVRAM (vendor key-value store).
  • Talks to peripherals (PHY, switch chip, LED controller) via memory-mapped I/O.

A generic QEMU run fails because the kernel / driver / NVRAM environment isn’t right.

Firmadyne — the original approach

Firmadyne (Daming Chen et al., 2016) provides:

  • A custom MIPS/ARM kernel (Linux 2.6.x) with hooks to intercept hardware accesses.
  • A NVRAM emulation library loaded via LD_PRELOAD into vendor binaries — returns plausible values for nvram_get calls.
  • A harness that extracts the filesystem from firmware, places it under the emulated kernel, mounts it, and boots.
  • A network bridge so you can talk to the emulated device’s HTTP / Telnet / UPnP services.

Limitations:

  • 2.6.x kernel doesn’t support newer device firmware.
  • Many devices don’t fully boot; ~40-50% success rate.

FirmAE — modern improvement

FirmAE (Kim et al., 2020) extends Firmadyne with:

  • More robust NVRAM defaults.
  • Better network initialisation (sets up the right interface up to the right IP).
  • Service-trigger heuristics (boots into HTTP-server mode).
  • ~80%+ success rate on consumer routers.

Recommended starting point for emulating consumer IoT.

Workflow

1. Extract firmware

  • binwalk to identify and extract filesystem (squashfs / cramfs / yaffs).
  • FACT (Firmware Analysis Toolkit) — wraps binwalk + Firmadyne + FirmAE.
  • See firmware-extraction for fuller treatment.

2. Identify architecture

  • file ./bin/busybox — confirms architecture (MIPS LE/BE, ARM, etc.).
  • Kernel module strings sometimes give vendor (Broadcom, Atheros, Realtek).

3. Use FirmAE or manual setup

FirmAE: ./run.sh -r <firmware.bin>. Watches firmware boot in QEMU; produces network bridge.

Manual: copy filesystem to chroot, identify init script, invoke QEMU with appropriate architecture:

1
2
3
4
5

qemu-system-mipsel -M malta -kernel firmadyne-kernel \
   -append "root=/dev/sda1 console=ttyS0" \
   -drive file=image.qcow2,if=ide \
   -netdev tap,id=net0 -device e1000,netdev=net0 \
   -nographic -gdb tcp::1234

4. Reach services

The emulated device boots. From the host:

  • nmap the emulated IP.
  • Browse to the HTTP management interface.
  • Send malformed requests; watch for crashes.

5. Debug

QEMU’s -gdb tcp::1234 lets you attach gdb-multiarch and step through binary handlers. For older MIPS firmware, gdb’s MIPS support requires gdb-multiarch package.

6. Fuzz

  • AFL++ with QEMU mode for binary-only fuzzing.
  • boofuzz for protocol fuzzing (HTTP, UPnP, custom).
  • Mayhem / commercial fuzzers.

Coverage feedback is the hard part for embedded binaries; QEMU TCG block coverage helps.

Pitfalls

  • Vendor-specific kernel modules — some firmware loads custom modules that emulation can’t reproduce. Stub them out or accept partial emulation.
  • Hardware watchdog — devices kick a watchdog timer; emulated binary may reboot itself if not stubbed.
  • NVRAM defaults — many config values feed into web UI; wrong defaults give blank or error pages.
  • MAC address dependency — some binaries check for valid MAC at boot.
  • Architecture mismatch — emulating MIPS big-endian on little-endian host requires the correct qemu-system-* build.
  • Stack layout differences vs real device — exploit primitives may differ in memory layout.

Verifying exploit on real hardware

After emulation finds a bug, you must validate on the physical device:

  • ROP gadget addresses may differ.
  • Crash recovery behaviour differs.
  • Heap layout differs.
  • Crash dumps may not survive to inspect.

Many researchers buy a single instance of the target device for final validation.

Common emulation targets

  • Consumer routers — D-Link, TP-Link, Netgear, Linksys, ASUS.
  • IP cameras — Dahua, Hikvision, Foscam, lower-tier brands.
  • NAS appliances — small Synology / QNAP / Western Digital (some need disk-image mounts).
  • Industrial controllers — Moxa, Lantronix, Phoenix Contact (more challenging).
  • Smart home hubs — TP-Link Tapo, Wyze, etc.

Workflow to study

  1. Pick a common consumer router firmware (TP-Link, D-Link).
  2. Run through FirmAE end-to-end.
  3. Reach the web UI in a browser via emulated network.
  4. Identify a known CVE (from CVE database) and reproduce against the emulated firmware.
  5. Patch-diff against fixed firmware; reproduce the bug.

References