Skip to content

Back to the catalog

SoK: A Large-Scale Empirical Study of Emulation-Based Dynamic Analysis Research for ARM Cortex-M Firmware (Extended Version)
arxiv.orgpaper

SoK: A Large-Scale Empirical Study of Emulation-Based Dynamic Analysis Research for ARM Cortex-M Firmware (Extended Version)

This SoK paper empirically evaluates 24 published emulation-based dynamic analysis tools for ARM Cortex-M firmware re-hosting, using large-scale datasets from OTACAP and FirmLine totaling 4,571 deduplicated ARM firmware samples. It finds that only 34.5% of samples can be successfully fuzzed by any existing tool, with average code coverage of just 10% and frequent false crashes/hangs, exposing systemic gaps across the emulation, fuzzing, and bug-diagnosis pipeline stages.

TL;DR Large-scale study of 24 ARM Cortex-M firmware emulation/fuzzing tools finds only 34.5% of samples can be fuzzed at all, with ~10% average coverage.
Document

What it is

This SoK (NDSS 2027) systematizes 24 emulation-based ARM Cortex-M firmware analysis tools — including P2IM, Fuzzware, µEmu, Hoedur, MultiFuzz, SAFIREFUZZ, Ember-IO, ICICLE, Aidfuzzer, GDMA, FlexEmu, and PEmu — into a four-stage pipeline: (1) emulation configuration reconnaissance, (2) emulation (CPU/peripheral), (3) security testing/fuzzing, (4) bug diagnosis.

How it works

The paper's Table I classifies each tool by what it depends on and produces at each stage: how it infers ISA/base address/entry point (e.g., pattern-based, PC-based, HAL-code-based, or FlexEmu's LLM-assisted approach), how it emulates peripherals (register-replay, fuzzing-driven, waiting-state detection), and what fuzzer/enhancement it builds on. Critically, most later tools (ICICLE, Hoedur, SplITS, MultiFuzz, Aidfuzzer, GDMA, PEmu) are shown to depend directly on earlier ones — Fuzzware in particular is a load-bearing dependency for Aidfuzzer, GDMA, and PEmu — meaning failures in upstream emulation-configuration inference propagate downstream into fuzzing and diagnosis. Two tools in the table (Laelaps, Conware) are marked "Unsupported" for security testing, and FlexEmu is marked unavailable (✗) for artifact access.

Preconditions / Affected

Applies specifically to monolithic Type-II/III ARM Cortex-M firmware; the authors explicitly excluded Linux-based (Type-I) firmware, hardware-in-the-loop approaches, startup-only emulation (e.g., Jetset), and domain-specialized tools (baseband, automotive, ICS, satellite, USB, TrustZone) from the systematization.

Caveats

The extended taxonomy (Fig. 2/Table I) is a structural map of tool lineage and capability, not a performance ranking — the quantitative failure numbers (34.5% fuzzable, 10% coverage) given in the existing summary come from a separate large-scale evaluation, not from this dependency table itself. The fetched content cuts off mid-section (III.B) before the paper's own discussion of how literature-selection choices affect findings (§VII-B, referenced but not reached).

Technologies named here

  • 24 emulation-based firmware analysis tools
  • ARM Cortex-M firmware
  • OTACAP
  • FirmLine
  • ARM Cortex-M

Techniques named here

  • Firmware re-hosting / emulation-based dynamic analysis
  • Fuzzing