pith. sign in

arxiv: 2605.16798 · v1 · pith:UKB6FRUVnew · submitted 2026-05-16 · 💻 cs.CR · cs.SE

Stop Starving or Stuffing Me: Boosting Firmware Fuzzing Efficiency with On-demand Input Delivery

Shandian Shen , Wei Zhou , Keming Zhao , Peng Liu , Chung Hwan Kim , Le Guan This is my paper

Pith reviewed 2026-05-19 21:11 UTC · model grok-4.3

classification 💻 cs.CR cs.SE
keywords firmware fuzzinginput deliverystatic analysisdynamic analysiscode coveragebug detectionon-demand input
0
0 comments X

The pith

Firmware fuzzers gain coverage by delivering inputs precisely at availability check points recovered via static and dynamic analysis.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Firmware often receives inputs asynchronously and independently of its execution, unlike general software. Existing fuzzers deliver inputs in ad-hoc ways that either overwhelm the firmware with too much data or fail to supply enough at the right moments. The paper shows that static and dynamic analysis can recover each input processing route as three stages: retrieval, availability check, and processing. This mapping lets the fuzzer deliver test cases exactly at the availability checks and in suitable quantities. The resulting system, FIDO, acts as an add-on that raises code coverage and speeds bug finding over prior methods.

Core claim

Firmware input processing routes can be mapped into three stages: input retrieval, availability check, and processing. Delivering fuzzer inputs exactly at the availability check points within the expected length range, combined with optimized scheduling for multiple routes, allows the fuzzer to avoid overwhelming or under-supplying the firmware, resulting in higher code coverage and faster discovery of bugs.

What carries the argument

Three-stage input processing route mapping recovered by static and dynamic analysis, which identifies availability check points to enable on-demand input delivery at the right timing and quantity.

If this is right

  • FIDO raises median code coverage by up to 115% over Fuzzware's ad-hoc input delivery.
  • FIDO raises median code coverage by up to 54% over MULTIFUZZ.
  • FIDO raises coverage by up to 19% over SEmu even though SEmu requires manual point specification.
  • FIDO finds known bugs faster and uncovers previously unknown bugs.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same stage-mapping technique could extend to fuzzing other embedded or real-time systems that process inputs asynchronously.
  • Combining the recovered availability checks with runtime monitoring might further reduce cases where inputs are still missed.
  • The approach could lower the manual effort needed to fuzz complex firmware that currently requires human-specified delivery points.

Load-bearing premise

The static and dynamic analysis can reliably recover the three-stage input processing routes across diverse firmware without missing asynchronous behaviors or needing extensive manual tuning.

What would settle it

Running FIDO on firmware where availability checks occur through indirect or runtime-generated code that the analysis fails to recover, producing no measurable coverage gain over ad-hoc delivery.

Figures

Figures reproduced from arXiv: 2605.16798 by Chung Hwan Kim, Keming Zhao, Le Guan, Peng Liu, Shandian Shen, Wei Zhou.

Figure 1
Figure 1. Figure 1: Three delivery plans with varying timing and [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Two I/O operating modes for peripheral input [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Overview of FIDO 1) As noted in F3, P operations occur only when length checks (i.e., lower limits) are satisfied; 2) As noted in F1, the ISR uses a ring buffer for input storage, meaning the input is overwritten before retrieval, indicating the input byte length has exceeded the upper limits. Thus, we propose incrementally increasing the delivery bytes at the delivery point and monitoring the length at wh… view at source ↗
Figure 5
Figure 5. Figure 5: Length range inference with example in Listing 1. [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figure 7
Figure 7. Figure 7: Code coverage comparison between SEmu+MSP and SEmu+FIDO (only 7 samples are shown, as the other samples require peripheral models that SEmu does not ex￾tract). fuzz delivery strategies, each byte is delivered after certain number of basic blocks are executed, allowing enough time for inputs to be read, so the overfeeding problem P1 is less common, except for input routes containing stricter length checks l… view at source ↗
Figure 8
Figure 8. Figure 8: Code Coverage Comparison with and without [PITH_FULL_IMAGE:figures/full_fig_p018_8.png] view at source ↗
read the original abstract

Firmware fuzzing has gained attention for identifying firmware bugs. However, current approaches often directly integrate fuzzing tools for general software. General software receives input as it encounters I/O functions, but firmware input can be received asynchronously and independently of the firmware's execution, with uncertain timing and quantity. Without full awareness of firmware's exceptions, existing solutions often imprudently deliver fuzzer-generated input to the firmware in an ad-hoc way. This either overwhelms the processing function of the firmware (stuffing) or fails to deliver enough input data to trigger input processing functions (starving). In both cases, fuzzing capability is weakened. In this paper, we comprehensively investigate the input delivery issue. To determine the optimal timing and quantity for delivering test cases, we leverage the fact that firmware has to check input availability before using data. So we employ static and dynamic analysis to map each input processing route into three stages: input retrieval, availability check, and processing. This recovered semantic information allows the fuzzer to accurately deliver input at the availability check points within the expected length range. For multiple input routes problem, we also optimize the scheduling algorithm to reach more diverse routes. Our prototype, named FIDO, can serve as an add-on to existing firmware fuzzers to enhance their test-case delivery effectiveness. Compared to ad-hoc input delivery methods used in Fuzzware and MULTIFUZZ, FIDO increases their median code coverage by up to 115% and 54%, respectively. Compared to SEmu, which requires humans to manually specify input delivery points, FIDO still improves its coverage by up to 19%. As a result, FIDO discovers known bugs significantly faster and also identifies five previously unknown bugs.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper presents FIDO, an add-on for firmware fuzzers that employs static and dynamic analysis to recover input processing routes and decompose them into three stages (retrieval, availability check, and processing). This semantic mapping enables precise on-demand delivery of fuzzer inputs at availability-check points with appropriate lengths, avoiding the starving or stuffing problems that arise from ad-hoc delivery in asynchronous firmware settings. The prototype is shown to improve median code coverage by up to 115% over Fuzzware, 54% over MULTIFUZZ, and 19% over manual-point SEmu, while also accelerating discovery of known bugs and finding five new ones.

Significance. If the route-recovery analysis proves reliable across firmware with varied input mechanisms, FIDO would meaningfully advance practical firmware fuzzing by directly tackling a core source of inefficiency in input scheduling. The reported coverage deltas and new bug findings provide concrete evidence of impact; the approach is additive to existing tools rather than a full replacement, which increases its potential adoption.

major comments (3)
  1. [§3] §3 (Static and Dynamic Analysis for Route Mapping): The description of how availability checks are identified does not explicitly address asynchronous or indirect mechanisms such as interrupt handlers, DMA completion callbacks, or hardware queues. Because the coverage gains (up to 115%/54%/19%) rest on correctly locating these checks for on-demand delivery, incomplete recovery could produce spurious or missed routes and undermine the comparison to ad-hoc baselines.
  2. [Evaluation] Evaluation section (coverage results): The improvements are stated as 'median code coverage by up to' values; it is unclear whether these are the maximum observed median across firmware samples, whether runs were repeated with statistical tests, or how data-exclusion rules for non-input routes were applied. Without these details the robustness of the central claim cannot be fully assessed.
  3. [§4] §4 (Multi-route Scheduling): The scheduler optimization for reaching diverse routes is presented at a high level. A concrete description or pseudocode of how the algorithm balances delivery across routes with different availability frequencies would be needed to verify that it does not simply re-introduce starvation for low-frequency routes.
minor comments (2)
  1. [Abstract] Abstract: the phrase 'imprudently deliver' is informal; a more precise term such as 'deliver without regard to availability timing' would improve clarity.
  2. The paper would benefit from an explicit limitations paragraph discussing firmware that uses polling loops or complex state machines for input availability.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive feedback and the recommendation for major revision. We address each major comment point by point below, providing clarifications and committing to revisions where the manuscript can be strengthened without misrepresenting our approach or results.

read point-by-point responses

  1. Referee: [§3] §3 (Static and Dynamic Analysis for Route Mapping): The description of how availability checks are identified does not explicitly address asynchronous or indirect mechanisms such as interrupt handlers, DMA completion callbacks, or hardware queues. Because the coverage gains (up to 115%/54%/19%) rest on correctly locating these checks for on-demand delivery, incomplete recovery could produce spurious or missed routes and undermine the comparison to ad-hoc baselines.

    Authors: Our route-mapping technique combines static identification of input retrieval sites with dynamic tracing that monitors all executed control flows and data accesses in the emulator. This inherently includes paths triggered by interrupts, DMA completions, and hardware queues because availability checks (e.g., status register tests or buffer-length comparisons) are observed at runtime regardless of the triggering mechanism. Nevertheless, we agree that the current text does not spell out these cases explicitly. We will revise §3 to add a paragraph that describes how interrupt handlers and DMA callbacks are captured through dynamic tracing of hardware register accesses and callback sites, thereby clarifying the generality of the recovery process. revision: yes

  2. Referee: [Evaluation] Evaluation section (coverage results): The improvements are stated as 'median code coverage by up to' values; it is unclear whether these are the maximum observed median across firmware samples, whether runs were repeated with statistical tests, or how data-exclusion rules for non-input routes were applied. Without these details the robustness of the central claim cannot be fully assessed.

    Authors: The phrase 'up to' denotes the largest median coverage gain observed across the evaluated firmware samples. Each campaign was repeated multiple times with distinct random seeds, medians were taken over those runs, and non-input routes were filtered using the same route-mapping analysis that identifies retrieval and availability-check stages. We will expand the Evaluation section to state the exact number of repetitions, the statistical test employed (Wilcoxon rank-sum), and the precise exclusion criteria, thereby making the experimental protocol fully reproducible. revision: yes

  3. Referee: [§4] §4 (Multi-route Scheduling): The scheduler optimization for reaching diverse routes is presented at a high level. A concrete description or pseudocode of how the algorithm balances delivery across routes with different availability frequencies would be needed to verify that it does not simply re-introduce starvation for low-frequency routes.

    Authors: The scheduler maintains a priority queue in which each route's priority is inversely proportional to its measured availability frequency; low-frequency routes therefore receive proportionally more delivery opportunities. A weighted round-robin pass then selects the next route while respecting these priorities. We will insert pseudocode in §4 that shows the priority-update and selection steps, demonstrating that starvation of infrequent routes is explicitly avoided. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical engineering technique with independent evaluation

full rationale

The paper describes a static/dynamic analysis pipeline to recover three-stage input routes (retrieval, availability check, processing) from firmware binaries and then schedules on-demand delivery at check points. No equations, fitted parameters, or self-referential definitions appear; the coverage gains are measured empirically against external baselines (Fuzzware, MULTIFUZZ, SEmu) on standard firmware images. The method is self-contained against external benchmarks and does not reduce any central claim to a prior self-citation or by-construction equivalence.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The approach assumes firmware input handling always includes an explicit availability check that can be located by static/dynamic analysis. No free parameters or invented entities are mentioned; the method adds an analysis layer on top of existing fuzzers.

axioms (1)
  • domain assumption Firmware must check input availability before using data, and this check is statically or dynamically identifiable.
    Stated in the abstract as the key fact leveraged to map routes into retrieval, availability check, and processing stages.

pith-pipeline@v0.9.0 · 5863 in / 1316 out tokens · 25743 ms · 2026-05-19T21:11:49.002470+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

64 extracted references · 64 canonical work pages

  1. [1]

    N. S. Agency, “Ghidra,” https://ghidra-sre.org/, 2023, last accessed: 2024-11-1

    work page 2023

  2. [2]

    Ghidra-Server.org provides a collaboration server on the in- ternet for the software reverse engineering,

    ——, “Ghidra-Server.org provides a collaboration server on the in- ternet for the software reverse engineering,” https://www.ghidra-ser ver.org/, April 2025

    work page 2025

  3. [3]

    Sfuzz: Slice-based fuzzing for real- time operating systems,

    L. Chen, Q. Cai, Z. Ma, Y . Wang, H. Hu, M. Shen, Y . Liu, S. Guo, H. Duan, K. Jianget al., “Sfuzz: Slice-based fuzzing for real- time operating systems,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 485–498

    work page 2022

  4. [4]

    Sharing more and checking less: Leveraging common input keywords to detect bugs in embedded systems,

    L. Chen, Y . Wang, Q. Cai, Y . Zhan, H. Hu, J. Linghu, Q. Hou, C. Zhang, H. Duan, and Z. Xue, “Sharing more and checking less: Leveraging common input keywords to detect bugs in embedded systems,” in30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 303–319

    work page 2021

  5. [5]

    Icicle: A re-designed emulator for grey-box firmware fuzzing,

    M. Chesser, S. Nepal, and D. C. Ranasinghe, “Icicle: A re-designed emulator for grey-box firmware fuzzing,” inProceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2023, pp. 76–88

    work page 2023

  6. [6]

    Incorrect handling of zero length sysex messages,

    ——, “Incorrect handling of zero length sysex messages,” https://github.com/MultiFuzz/MultiFuzz-benchmarks/blob/main/cras h-analysis.md#incorrect-handling-of-zero-length-sysex-messages, 2024, last accessed: 2024-03-01

    work page 2024

  7. [7]

    Multifuzz: A multi-stream fuzzer for testing monolithic firmware,

    ——, “Multifuzz: A multi-stream fuzzer for testing monolithic firmware,” in33rd USENIX Security Symposium (USENIX Security), 2024

    work page 2024

  8. [8]

    Null Pointer Dereference in ccnl cs,

    ——, “Null Pointer Dereference in ccnl cs,” https: //github.com/MultiFuzz/MultiFuzz-benchmarks/blob/main/cras h-analysis.md#issue-with--encoded-characters-in-ccnl cs, 2024, last accessed: 2024-03-01

    work page 2024

  9. [9]

    Reinitialization of shared global timer,

    ——, “Reinitialization of shared global timer,” https: //github.com/MultiFuzz/MultiFuzz-benchmarks/blob/main/cras h-analysis.md#reinitialization-of-shared-global-timer, 2024, last accessed: 2024-03-01

    work page 2024

  10. [10]

    Stdio initialization race,

    ——, “Stdio initialization race,” https://github.com/MultiFuzz/Mul tiFuzz-benchmarks/blob/main/crash-analysis.md#return-value-of-s trtok-not-checked-for-null-in-gsm get imei, 2024, last accessed: 2024-03-01

    work page 2024

  11. [11]

    Stdio initialization race,

    ——, “Stdio initialization race,” https://github.com/MultiFuzz/M ultiFuzz-benchmarks/blob/main/crash-analysis.md#return-value-o f-strstr-not-checked-for-null-in-sms check, 2024, last accessed: 2024-03-01

    work page 2024

  12. [12]

    Stdio initialization race,

    ——, “Stdio initialization race,” https://github.com/MultiFuzz/M ultiFuzz-benchmarks/blob/main/crash-analysis.md#return-value-o f-strstr-not-checked-for-null-in-gsm get time, 2024, last accessed: 2024-03-01

    work page 2024

  13. [13]

    Stdio initialization race,

    ——, “Stdio initialization race,” https://github.com/MultiFuzz/Multi Fuzz-benchmarks/blob/main/crash-analysis.md#stdio-initialization-r ace, 2024, last accessed: 2024-03-01

    work page 2024

  14. [14]

    Stdio initialization race,

    ——, “Stdio initialization race,” https://github.com/MultiFuzz /MultiFuzz-benchmarks/blob/main/crash-analysis.md#net-pkt-com mand-dereferences-a-user-provided-pointer, 2024, last accessed: 2024-03-01

    work page 2024

  15. [15]

    Use After Free in evtimer struct,

    ——, “Use After Free in evtimer struct,” https://github.com/Multi Fuzz/MultiFuzz-benchmarks/blob/main/crash-analysis.md#missing-r emoval-from-evtimer-struct, 2024, last accessed: 2024-03-01

    work page 2024

  16. [16]

    A friend’s eye is a good mirror: Synthesizing mcu peripheral models from peripheral driver,

    L. Chongqing, L. Zhen, Z. Yue, Y . Yan, L. Junzhou, and F. Xinwen, “A friend’s eye is a good mirror: Synthesizing mcu peripheral models from peripheral driver,” inUSENIX Security, 2024

    work page 2024

  17. [17]

    {HALucinator}: Firmware re-hosting through abstraction layer emulation,

    A. A. Clements, E. Gustafson, T. Scharnowski, P. Grosen, D. Fritz, C. Kruegel, G. Vigna, S. Bagchi, and M. Payer, “{HALucinator}: Firmware re-hosting through abstraction layer emulation,” in29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 1201– 1218

    work page 2020

  18. [18]

    Ember-io: Ef- fective firmware fuzzing with model-free memory mapped io,

    G. Farrelly, M. Chesser, and D. C. Ranasinghe, “Ember-io: Ef- fective firmware fuzzing with model-free memory mapped io,” in Proceedings of the 2023 ACM Asia conference on computer and communications security, 2023

    work page 2023

  19. [19]

    Splits: Split input-to-state mapping for effective firmware fuzzing,

    G. Farrelly, P. Quirk, S. S. Kanhere, S. Camtepe, and D. C. Ranas- inghe, “Splits: Split input-to-state mapping for effective firmware fuzzing,” inEuropean Symposium on Research in Computer Security. Springer, 2023, pp. 290–310

    work page 2023

  20. [20]

    Aim: Automatic in- terrupt modeling for dynamic firmware analysis,

    B. Feng, M. Luo, C. Liu, L. Lu, and E. Kirda, “Aim: Automatic in- terrupt modeling for dynamic firmware analysis,”IEEE Transactions on Dependable and Secure Computing, 2023

    work page 2023

  21. [21]

    P2im: Scalable and hardware- independent firmware testing via automatic peripheral interface mod- eling,

    B. Feng, A. Mera, and L. Lu, “P2im: Scalable and hardware- independent firmware testing via automatic peripheral interface mod- eling,” inProceedings of Usenix Security Symposium, 2020

    work page 2020

  22. [22]

    CVE-2020-10064 Description,

    L. Foundation, “CVE-2020-10064 Description,” https://docs.zephyrp roject.org/latest/security/vulnerabilities.html#cve-2020-10064, 2020, last accessed: 2024-03-01

    work page 2020

  23. [23]

    CVE-2020-10065 Description,

    ——, “CVE-2020-10065 Description,” https://docs.zephyrproject.o rg/latest/security/vulnerabilities.html#cve-2020-10065, 2020, last ac- cessed: 2024-03-01

    work page 2020

  24. [24]

    CVE-2020-10066 Description,

    ——, “CVE-2020-10066 Description,” https://docs.zephyrproject.o rg/latest/security/vulnerabilities.html#cve-2020-10066, 2020, last ac- cessed: 2024-03-01

    work page 2020

  25. [25]

    CVE-2021-3319 Description,

    ——, “CVE-2021-3319 Description,” https://github.com/zephyrproje ct-rtos/zephyr/security/advisories/GHSA-94jg-2p6q-5364, 2021, last accessed: 2024-03-01

    work page 2021

  26. [26]

    CVE-2021-3320 Description,

    ——, “CVE-2021-3320 Description,” https://docs.zephyrproject.o rg/latest/security/vulnerabilities.html#cve-2021-3320, 2021, last ac- cessed: 2024-03-01

    work page 2021

  27. [27]

    CVE-2021-3329 Description,

    ——, “CVE-2021-3329 Description,” https://github.com/zephyrproje ct-rtos/zephyr/issues/39549, 2021, last accessed: 2024-03-01

    work page 2021

  28. [28]

    Toward the analysis of embedded firmware through automated re-hosting,

    E. Gustafson, M. Muench, C. Spensky, N. Redini, A. Machiry, Y . Fratantonio, D. Balzarotti, A. Francillon, Y . R. Choe, C. Kruegel et al., “Toward the analysis of embedded firmware through automated re-hosting,” in22nd International Symposium on Research in Attacks, Intrusions and Defenses ({RAID}2019), 2019, pp. 135–150

    work page 2019

  29. [29]

    {PASAN}: Detecting peripheral access concurrency bugs within{Bare-Metal}embedded applications,

    T. Kim, V . Kumar, J. Rhee, J. Chen, K. Kim, C. H. Kim, D. Xu, and D. J. Tian, “{PASAN}: Detecting peripheral access concurrency bugs within{Bare-Metal}embedded applications,” in30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 249–266

    work page 2021

  30. [30]

    Why short interrupt service routines matter,

    P. Koopman, “Why short interrupt service routines matter,” https://betterembsw.blogspot.com/2013/04/why-short-interrupt-servi ce-routines.html, 2025, last accessed: 2025-06-01

    work page 2013

  31. [31]

    µafl: non-intrusive feedback-driven fuzzing for microcontroller firmware,

    W. Li, J. Shi, F. Li, J. Lin, W. Wang, and L. Guan, “µafl: non-intrusive feedback-driven fuzzing for microcontroller firmware,” inProceed- ings of the 44th International Conference on Software Engineering, 2022, pp. 1–12

    work page 2022

  32. [32]

    {CO3}: Concolic co-execution for firmware,

    C. Liu, A. Mera, E. Kirda, M. Xu, and L. Lu, “{CO3}: Concolic co-execution for firmware,” in33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 5591–5608

    work page 2024

  33. [33]

    {SHiFT}: Semi-hosted fuzz testing for embedded applications,

    A. Mera, C. Liu, R. Sun, E. Kirda, and L. Lu, “{SHiFT}: Semi-hosted fuzz testing for embedded applications,” in33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 5323–5340

    work page 2024

  34. [34]

    Avatar 2: A multi-target orchestration platform,

    M. Muench, D. Nisi, A. Francillon, and D. Balzarotti, “Avatar 2: A multi-target orchestration platform,” inProc. Workshop Binary Anal. Res.(Colocated NDSS Symp.), vol. 18, 2018, pp. 1–11

    work page 2018

  35. [35]

    Avatar2: A multi-target orchestration platform,

    ——, “Avatar2: A multi-target orchestration platform,” inProc. Work- shop Binary Anal. Res.(Colocated NDSS Symp.), vol. 18, 2018, pp. 1–11

    work page 2018

  36. [36]

    Official mbed ble examples,

    M. OS., “Official mbed ble examples,” https://github.com/ARMmb ed/mbed-os-example-ble

    work page

  37. [37]

    Ffxe: Dynamic control flow graph recovery for embedded firmware binaries,

    T. Ryan, Asmita, J. Doreen, S. Soheil, M. Prasant, and H. Houman, “Ffxe: Dynamic control flow graph recovery for embedded firmware binaries,” in33rd USENIX Security Symposium (USENIX Security), 2024

    work page 2024

  38. [38]

    CVE-2020-12140 Description,

    T. Scharnowski, “CVE-2020-12140 Description,” https: //github.com/fuzzware-fuzzer/fuzzware-experiments/blob/main /03-fuzzing-new-targets/bug-details/CVE-2020-12140-Contiki-NG-l 2cap-frame-size.md, 2022, last accessed: 2024-03-01

    work page 2020

  39. [39]

    CVE-2020-12141 Description,

    ——, “CVE-2020-12141 Description,” https://github.com/fuzzwar e-fuzzer/fuzzware-experiments/blob/main/03-fuzzing-new-targets/b ug-details/CVE-2020-12141-Contiki-NG-SNMP-string-decode.md, 2022, last accessed: 2024-03-01

    work page 2020

  40. [40]

    P2IM Gateway OOB write in HAL Description,

    ——, “P2IM Gateway OOB write in HAL Description,” https://github.com/fuzzware-fuzzer/fuzzware-experiments/tree/ main/04-crash-analysis/12, 2022, last accessed: 2024-03-01

    work page 2022

  41. [41]

    P2IM Gateway OOB write in HAL Description,

    ——, “P2IM Gateway OOB write in HAL Description,” https://github.com/fuzzware-fuzzer/fuzzware-experiments/tree/ main/04-crash-analysis/21, 2022, last accessed: 2024-03-01

    work page 2022

  42. [42]

    P2IM Gateway OOB write in HAL Description,

    ——, “P2IM Gateway OOB write in HAL Description,” https://github.com/fuzzware-fuzzer/fuzzware-experiments/tree/ main/04-crash-analysis/23, 2022, last accessed: 2024-03-01

    work page 2022

  43. [43]

    P2IM Heat Press Bug in get FC3 Description,

    ——, “P2IM Heat Press Bug in get FC3 Description,” https://github.com/fuzzware-fuzzer/fuzzware-experiments/tree/ main/04-crash-analysis/13, 2022, last accessed: 2024-03-01

    work page 2022

  44. [44]

    P2IM PLC Bug in Process FC1 Description,

    ——, “P2IM PLC Bug in Process FC1 Description,” https://github.com/fuzzware-fuzzer/fuzzware-experiments/tree/ main/04-crash-analysis/14, 2022, last accessed: 2024-03-01

    work page 2022

  45. [45]

    P2IM PLC Bug in Process FC15 Description,

    ——, “P2IM PLC Bug in Process FC15 Description,” https://github.com/fuzzware-fuzzer/fuzzware-experiments/tree/ main/04-crash-analysis/16, 2022, last accessed: 2024-03-01

    work page 2022

  46. [46]

    P2IM PLC Bug in Process FC16 Description,

    ——, “P2IM PLC Bug in Process FC16 Description,” https://github.com/fuzzware-fuzzer/fuzzware-experiments/tree/ main/04-crash-analysis/17, 2022, last accessed: 2024-03-01

    work page 2022

  47. [47]

    P2IM PLC Bug in Process FC3 Description,

    ——, “P2IM PLC Bug in Process FC3 Description,” https://github.com/fuzzware-fuzzer/fuzzware-experiments/tree/ main/04-crash-analysis/15, 2022, last accessed: 2024-03-01

    work page 2022

  48. [48]

    Fuzzware: Using precise MMIO modeling for effective firmware fuzzing,

    T. Scharnowski, N. Bars, M. Schloegel, E. Gustafson, M. Muench, G. Vigna, C. Kruegel, T. Holz, and A. Abbasi, “Fuzzware: Using precise MMIO modeling for effective firmware fuzzing,” in31st USENIX Security Symposium (USENIX Security 22). Boston, MA: USENIX Association, 2022. [Online]. Available: https://www.usen ix.org/conference/usenixsecurity22/presentat...

    work page 2022

  49. [49]

    Gdma: Fully automated dma rehosting via iterative type overlays,

    T. Scharnowski, S. Hoffmann, M. Bley, S. W ¨orner, D. Klischies, F. Buchmann, N. O. Tippenhauer, T. Holz, and M. Muench, “Gdma: Fully automated dma rehosting via iterative type overlays,” in34rd USENIX Security Symposium (USENIX Security 25), 2025

    work page 2025

  50. [50]

    Hoedur: Embedded firmware fuzzing using multi- stream inputs,

    T. Scharnowski, S. Woerner, F. Buchmann, N. Bars, M. Schloegel, and T. Holz, “Hoedur: Embedded firmware fuzzing using multi- stream inputs,” in32nd USENIX Security Symposium (USENIX Security 23). Boston, MA: USENIX Association, Aug. 2023. [Online]. Available: https://www.usenix.org/conference/usenixsecuri ty23/presentation/scharnowski

    work page 2023

  51. [51]

    Firmalice-automatic detection of authentication bypass vulnerabili- ties in binary firmware

    Y . Shoshitaishvili, R. Wang, C. Hauser, C. Kruegel, and G. Vigna, “Firmalice-automatic detection of authentication bypass vulnerabili- ties in binary firmware.” inNDSS, vol. 1, 2015, pp. 1–1

    work page 2015

  52. [52]

    Conware: Automated modeling of hardware peripherals,

    C. Spensky, A. Machiry, N. Redini, C. Unger, G. Foster, E. Blas- band, H. Okhravi, C. Kruegel, and G. Vigna, “Conware: Automated modeling of hardware peripherals,” inProceedings of the 2021 ACM Asia Conference on Computer and Communications Security, 2021, pp. 95–109

    work page 2021

  53. [53]

    Charm: Facilitating dynamic analysis of device drivers of mobile systems,

    S. M. S. Talebi, H. Tavakoli, H. Zhang, Z. Zhang, A. A. Sani, and Z. Qian, “Charm: Facilitating dynamic analysis of device drivers of mobile systems,” in27th USENIX Security Symposium, 2018, pp. 291–307

    work page 2018

  54. [54]

    Aidfuzzer: Adaptive interrupt-driven firmware fuzzing via run-time state recognition,

    J. Wang, Q. Wang, T. Scharnowski, L. Shi, S. Woerner, and T. Holz, “Aidfuzzer: Adaptive interrupt-driven firmware fuzzing via run-time state recognition,” in34rd USENIX Security Symposium (USENIX Security 25), 2025

    work page 2025

  55. [55]

    Embedded systems/io programming,

    WikeBooks, “Embedded systems/io programming,” https://en.wik ibooks.org/wiki/Embedded Systems/IO Programming, 2025, last ac- cessed: 2025-07-01

    work page 2025

  56. [56]

    What you see is not what you get: Revealing hidden memory mapping for peripheral modeling,

    J. Y . Won, H. Wen, and Z. Lin, “What you see is not what you get: Revealing hidden memory mapping for peripheral modeling,” in25th International Symposium on Research in Attacks, Intrusions and Defenses, RAID 2022, Limassol, Cyprus, October 26-28, 2022. ACM, 2022, pp. 200–213. [Online]. Available: https://doi.org/10.1145/3545948.3545957

    work page doi:10.1145/3545948.3545957 2022

  57. [57]

    Avatar: A framework to support dynamic security analysis of embedded systems’ firmwares

    J. Zaddach, L. Bruno, A. Francillon, D. Balzarottiet al., “Avatar: A framework to support dynamic security analysis of embedded systems’ firmwares.” inNDSS, vol. 14, 2014, pp. 1–16

    work page 2014

  58. [58]

    Ble hci uart example,

    Zephyr., “Ble hci uart example,” https://docs.zephyrproject.org/lates t/samples/bluetooth/hci uart/README.html#bluetooth hci uart

    work page

  59. [59]

    Automatic firmware emulation through invalidity-guided knowledge inference,

    W. Zhou, L. Guan, P. Liu, and Y . Zhang, “Automatic firmware emulation through invalidity-guided knowledge inference,” in30th USENIX Security Symposium (USENIX Security 21), 2021

    work page 2021

  60. [60]

    What your firmware tells you is not how you should emulate it: A specification- guided approach for firmware emulation,

    W. Zhou, L. Zhang, L. Guan, P. Liu, and Y . Zhang, “What your firmware tells you is not how you should emulate it: A specification- guided approach for firmware emulation,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 3269–3283

    work page 2022

  61. [61]

    Constructing more complete control flow graphs utilizing directed gray-box fuzzing,

    K. Zhu, Y . Lu, H. Huang, L. Yu, and J. Zhao, “Constructing more complete control flow graphs utilizing directed gray-box fuzzing,” Applied Sciences, vol. 11, no. 3, p. 1351, 2021

    work page 2021

  62. [62]

    Fuzzing: a survey for roadmap,

    X. Zhu, S. Wen, S. Camtepe, and Y . Xiang, “Fuzzing: a survey for roadmap,”ACM Computing Surveys (CSUR), vol. 54, no. 11s, pp. 1–36, 2022. Appendix A. Feature of Unit-test Samples TABLE 7: Feature of unit-test samples (-:No official demo) RTOS Driver Demo RIoT Nuttx Zephyr MbedOS FreeRTOS GPIOF3 F2, F3 F3 F3 F3 UARTF1, F2, F3 F1, F3 F1, F3 F1, F3 F1, F3 I...

    work page 2022

  63. [63]

    The paper provides a valuable step forward in an estab- lished field. It addresses the problem of input delivery in interrupt-driven firmware fuzzing, demonstrating that the timing and quantity of injected inputs significantly influence coverage and bug discovery. By introducing a novel approach orthogonal to traditional improvements in test-case generati...

    work page

  64. [64]

    The paper creates a new tool to enable future science. The authors implement FIDO as a practical extension compatible with existing firmware fuzzers such asFuz- zware,MULTIFUZZ, andSEmu, showing measurable improvements in coverage and vulnerability discovery. By planning to releaseFIDOas open source, the work provides the research community with a reusabl...

    work page