[Paper] DyMA-Fuzz: Dynamic Direct Memory Access Abstraction for Re-hosted Monolithic Firmware Fuzzing

Source: arXiv - 2602.08750v1

Overview

Firmware for smart‑device controllers is increasingly the attack surface for critical systems such as cars, medical equipment, and industrial IoT. While “re‑hosting” (running firmware on a PC‑based emulator) makes large‑scale fuzzing feasible, the tight coupling between firmware and its peripherals—especially Direct Memory Access (DMA) engines—has kept many bugs hidden. The paper DyMA‑Fuzz proposes a fully automated way to model and fuzz DMA‑driven I/O, dramatically improving coverage and vulnerability discovery in monolithic firmware binaries.

Key Contributions

• Dynamic DMA abstraction: A runtime‑analysis layer that automatically discovers vendor‑specific DMA descriptors, their layout, and the memory regions they target, without any datasheet or manual configuration.
• Stream‑based fuzz injection for DMA: Extends existing fuzz‑input streaming techniques (originally built for MMIO/interrupts) to high‑throughput DMA channels, allowing arbitrary fuzz data to be placed directly into the buffers that DMA will read or write.
• Broad evaluation: Tested on 94 real‑world firmware images and 8 known DMA‑related CVE benchmarks, showing up to 122 % higher code coverage compared with the best open‑source re‑hosted fuzzers.
• Zero‑configuration workflow: The tool automatically adapts to heterogeneous DMA designs (different descriptor formats, scatter‑gather lists, circular buffers, etc.), making it practical for security teams that lack deep hardware documentation.

Methodology

1. Emulated re‑hosting platform: The authors built on an existing firmware emulator that models the CPU, memory, and peripheral registers.
2. Dynamic descriptor discovery: While the firmware runs, DyMA‑Fuzz monitors memory accesses that match typical DMA‑setup patterns (e.g., writes to control registers followed by pointer writes). It then infers the structure of the descriptor (source/destination addresses, length, flags).
3. Buffer identification & mapping: Once a descriptor is recognized, the tool tracks the pointed‑to buffers and registers them as “fuzzable streams.”
4. Fuzz data injection: A standard coverage‑guided fuzzer (e.g., AFL++) supplies byte streams that DyMA‑Fuzz writes into the identified buffers just before the DMA engine is triggered. Because DMA bypasses the CPU, this injection happens at the memory level, ensuring the firmware sees the fuzzed payload exactly as it would from real hardware.
5. Feedback loop: Execution traces (branch coverage) are fed back to the fuzzer, which mutates inputs to explore new paths, just like conventional software fuzzing.

The whole pipeline runs automatically: start the emulator, attach DyMA‑Fuzz, launch the fuzzer, and let the system discover DMA interfaces on‑the‑fly.

Results & Findings

The authors highlight several case studies where a DMA‑driven peripheral (e.g., a UART DMA engine) copied attacker‑controlled data into a privileged memory region, leading to a stack overflow that was invisible to MMIO‑only fuzzers. DyMA‑Fuzz also uncovered a mis‑configured scatter‑gather list that allowed out‑of‑bounds writes in a medical device firmware sample.

Practical Implications

• Security testing pipelines: Teams can plug DyMA‑Fuzz into existing CI/CD fuzzing setups for firmware, gaining immediate coverage gains without hiring hardware experts.
• Vendor‑agnostic analysis: Because the tool learns DMA layouts at runtime, it works across MCU families (ARM Cortex‑M, RISC‑V, etc.) and across proprietary peripherals, reducing reliance on vendor documentation.
• Regulatory compliance: Industries that must demonstrate thorough firmware testing (automotive ISO‑26262, medical IEC 62304) can now claim coverage of DMA paths, a previously gray area.
• Bug bounty and vulnerability research: Researchers can target high‑value DMA‑related attack surfaces (e.g., DMA‑enabled DMA‑to‑PCIe bridges) with far less manual reverse‑engineering effort.

Limitations & Future Work

• Emulation fidelity: DyMA‑Fuzz depends on the underlying emulator accurately modeling DMA timing and side‑effects; exotic peripherals with custom DMA controllers may still behave incorrectly.
• Performance overhead: The dynamic descriptor analysis adds ~15 % runtime overhead, which can limit the number of executions per second for very large firmware images.
• Non‑memory‑mapped DMA triggers: Some DMA engines are started via complex handshake protocols (e.g., DMA‑linked list updates) that the current heuristic may miss.
• Future directions: The authors plan to integrate hardware‑in‑the‑loop (HIL) validation to confirm findings on real devices, extend support for multi‑core firmware, and explore machine‑learning‑driven descriptor inference to further reduce false positives.

Authors

• Guy Farrelly
• Michael Chesser
• Seyit Camtepe
• Damith C. Ranasinghe

Paper Information

• arXiv ID: 2602.08750v1
• Categories: cs.CR, cs.SE
• Published: February 9, 2026
• PDF: Download PDF