PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Hongyuan Li, Ke Wang, Wei Zhou, Le Guan

arXiv:2609.38872v1cs.CR

TL;DR

Existing MCU firmware evaluations use small, overlapping datasets and study analysis components in isolation, leaving limited evidence about real-world performance and cross-stage dependencies. This SoK systematizes 24 tools in a four-stage workflow and evaluates them on 4,571 ARM Cortex-M samples. It finds limited emulation success and coverage, alongside false crashes and root-cause misattribution.

  • Problem

    Existing evaluations use small, overlapping benchmarks and examine isolated pipeline components, limiting evidence about generalizability and cross-stage dependencies.

    Source: §I · p. 2

  • Method

    The SoK positions 24 tools in a unified four-stage pipeline and evaluates applicable tools on 4,571 unique ARM Cortex-M samples from OTACap and FirmLine.

    Source: §I · p. 2

  • Results

    Current tools show limited emulation success and coverage, numerous false crashes, and frequent root-cause misattribution; average fuzzing coverage ranges from 9% to 11%.

    Source: §I · p. 2, D. Stage 3: Fuzzing and Runtime Results · p. 9

  • Takeaways & Limitations

    The study identifies recurring weaknesses in configuration inference, emulation support, peripheral modeling, crash diagnosis, and engineering that hinder large-scale use.

    Source: §VIII · p. 13

    The pipeline-oriented evaluation excludes tools requiring unavailable inputs or configurations, including some high-fidelity approaches that depend on hardware manuals or source-level code.

    Source: B. Limitations of This Study · p. 13

Abstract

from arXiv · show

Microcontroller (MCU)-based devices are increasingly pervasive, making efficient, scalable firmware security analysis critical. Recent firmware re-hosting work enables automated vulnerability assessment, yet two gaps remain. First, existing tools are evaluated on limited, heavily overlapping datasets, undermining the generalizability of reported results. Second, prior research advances the state of the art along isolated dimensions, such as emulation, fuzzing, or bug diagnosis, without a holistic understanding of how these components interact and complement one another in dynamic analysis workflows. Building on recently released large-scale MCU firmware datasets from OTACAP and FirmLine, we present an empirical study of 24 emulation-based firmware analysis tools published in top conferences and journals. We position these tools within a unified automated analysis pipeline: emulation configuration reconnaissance, emulation, bug finding, and diagnosis. At each stage, we evaluate whether a tool's output provides sufficient information to enable the subsequent stage, using a deduplicated and validated subset of 4,571 ARM-based firmware samples. Only 1,580 samples (34.5%) can be successfully fuzzed, even counting a sample successful if at least one existing tool can fuzz it. Among these, fuzzing results are generally poor, with average code coverage of only 10% and many false crashes/hangs. Through a systematic analysis of failed fuzzing attempts and false-positive cases, we expose fundamental challenges and methodological limitations in current approaches. These findings highlight critical gaps in the state of the art and provide actionable insights to guide future research in emulation-based firmware analysis.

I. INTRODUCTION

MCU firmware is difficult to analyze because it is tightly coupled to diverse hardware and often lacks security protections, while physical testing can be inefficient or infeasible. This SoK evaluates emulation-based analysis holistically on real-world ARM Cortex-M firmware and identifies gaps and research directions.

I. INTRODUCTION

  • Existing evaluations use small, overlapping benchmarks and study pipeline components in isolation, limiting assessment of generalizability and cross-stage dependencies.Earlier SoKs also predate more than a dozen studies advancing emulation, fuzzing, and downstream analysis.Source: §I · pp. 1–2
  • The study positions 24 state-of-the-art tools in a unified four-stage analysis pipeline and evaluates applicable tools on 4,571 unique ARM Cortex-M firmware samples selected from OTACap and FirmLine.Source: §I · p. 2
  • The study reports limited emulation success and coverage, numerous false crashes, and frequent root-cause misattribution in current tools.Its findings are based on real-world datasets and cross-stage evaluation.Source: §I · p. 2
  • The SoK identifies black-box configuration inference, incomplete ISA and memory support, inaccurate peripheral models, and performance and compatibility issues as barriers.The analysis uses real-world firmware examples and false-crash artifacts.Source: §I · p. 2
  • The paper proposes hybrid analysis, higher-fidelity emulation, and more scalable fuzzing and diagnosis strategies as future research directions.These directions address the identified limitations in firmware re-hosting and dynamic analysis.Source: §I · p. 2

A. MCU-Based Devices and Monolithic Firmware

  • MCU firmware combines application logic, drivers, libraries, and sometimes an RTOS, and interacts with hardware through MMIO, interrupts, and DMA.MCUs are widely used in IoT devices, including security-sensitive settings.Source: §I · p. 1, A. MCU-Based Devices and Monolithic… · p. 3

B. Firmware Development and Deployment

Firmware formats and deployment practices vary, complicating emulation and analysis. The paper organizes relevant research around a four-stage workflow and selects studies targeting general, full-lifecycle ARM Cortex-M dynamic analysis.

B. Firmware Development and Deployment

  • Firmware may be stripped, converted to raw or ASCII images, compressed, encrypted, or split into components, and manufacturers can use proprietary formats.These variations make firmware emulation and analysis challenging.Source: B. Firmware Development and Deployment · p. 3

A. Emulation-Based Firmware Analysis Pipeline

  • The analysis pipeline proceeds from configuration reconnaissance to emulation, security testing, and crash diagnosis.Configuration includes ISA, memory layout or base address, and entry point; testing supplies inputs, monitors coverage, and detects runtime faults.Source: A. Emulation-Based Firmware Analysis… · p. 3

B. Literature Scope and Selection Criteria

  • The study selects literature from 2010–2025 using venue, keyword, and relevance criteria, while noting that these criteria may exclude relevant work.The scope targets monolithic firmware, full-lifecycle emulation, general analysis, ARM Cortex-M support, and at least one dynamic-analysis task.Source: B. Literature Scope and Selection… · pp. 3–4
  • Stage 1 includes OTACap and FirmLine for firmware recognition, while FirmRCA is the only identified post-fuzzing diagnosis tool.The stage-2/3 selection comprises 21 works.Source: B. Literature Scope and Selection… · p. 4

C. Stage 1: Emulation Configuration Reconnaissance

Firmware re-hosting requires the target ISA, base address, and entry point, but real-world firmware is often a stripped black-box binary. The section reviews emulation approaches spanning CPU, peripheral, HAL replacement, and transplanted execution.

C. Stage 1: Emulation Configuration Reconnaissance

  • Tools need the firmware’s ISA, base address, and entry point, which are often unavailable in stripped black-box binaries.Only a few studies explicitly address recovering these inputs, using heuristic methods.Source: C. Stage 1: Emulation Configuration… · p. 4

D. Stage 2: Emulation

  • Existing work targets CPU emulation, peripheral emulation, HAL replacement, or transplanted execution.The paper classifies emulation studies by their primary component.Source: D. Stage 2: Emulation · p. 5

1) EC: CPU Emulation:

  • QEMU offers broader embedded-architecture support, while Unicorn is lighter for dynamic analysis but sacrifices some features.ICICLE uses Ghidra’s SLEIGH specifications for flexible CPU emulation and dynamic binary instrumentation.Source: 1) EC: CPU Emulation · p. 5

2) EP: Peripheral Emulation:

  • Heuristic peripheral models infer behavior from execution, but may sacrifice fidelity and introduce false positives.Other approaches derive models from hardware logs, manuals, or open-source HAL code, each with stated dependencies or limitations.Source: 2) EP: Peripheral Emulation · p. 5

3) EPH: HAL Replacement:

  • HAL replacement can avoid peripheral modeling, but its effectiveness depends on finding an HAL layer and accurate library matching.Not all firmware uses an HAL layer.Source: 3) EPH: HAL Replacement · p. 5

4) ET: Transplanted Execution:

  • SAFIREFUZZ runs ARM Cortex-M firmware on ARM Cortex-A servers without CPU emulation, using HAL replacement and dynamic binary rewriting.The rewriting handles peripheral interactions and Cortex-M-specific instructions.Source: 4) ET: Transplanted Execution · pp. 5–6

E. Stage 3: Security Testing

  • Firmware emulation also supports security testing, including fuzzing and symbolic execution.The passage introduces the stage but does not specify its techniques.Source: E. Stage 3: Security Testing · p. 6

1) F: Fuzzing:

Firmware emulation supports fuzzing and related testing, but existing studies often rely on small, overlapping datasets and examine isolated pipeline components. The section reviews fuzzing enhancements, symbolic execution, diagnosis, and the motivation for a holistic evaluation.

1) F: Fuzzing:

  • Fuzzers use emulation as a back end for execution, feedback collection, and crash detection, but firmware-specific behavior can reduce their effectiveness and efficiency.Enhancements target execution feedback and input generation or mutation.Source: 2) FE: Enhancement · p. 6, 1) F: Fuzzing · p. 6

2) FE: Enhancement:

  • Fuzzing enhancements refine feedback, model inputs as peripheral streams, or use protocol-aware techniques.Ember-IO separates ISR-induced edges; ICICLE and MultiFuzz add finer-grained branch feedback, while Hoedur and MultiFuzz support stream-aware scheduling and mutation.Source: 2) FE: Enhancement · p. 6

3) S: Symbolic Execution:

  • AIM uses symbolic execution to predict interrupt-triggering behavior and concolic execution for crash detection.Its basic memory error detector must align with the memory layout and permissions.Source: 3) S: Symbolic Execution · p. 6

F. Stage 4: Diagnosis

  • Silent memory corruption can make MCU crashes occur long after the initial fault, complicating diagnosis and increasing manual effort.FirmRCA uses backward taint analysis and crash-replay memory snapshots to localize faults.Source: F. Stage 4: Diagnosis · p. 6

IV. LARGE-SCALE EMPIRICAL STUDY OF SOTA TOOLS

  • Existing evaluations use small, overlapping datasets: among 325 unique samples, only 133 were used by one tool, raising concerns about applicability to diverse firmware.The P2IM and WYC datasets were used by 12 and 10 tools, respectively; Fig. 3 depicts vendor distribution and dataset composition across works.Source: §IV · pp. 6–7, Figure 3 · p. 7
  • The study evaluates whether each stage’s output suffices for the next, assessing interoperability, robustness, and completeness end to end.Its evaluation pipeline automates batch processing and stores test results and execution logs.Source: §IV · p. 7

A. Evaluation Scope

The evaluation uses filtered ARM Cortex-M firmware and carries stage outputs forward to assess tool interoperability. Results show that decoupled tools often fail during peripheral modeling, while co-designed tools frequently fail during fuzzing initialization.

A. Evaluation Scope

  • The evaluation selected tools for a unified framework, excluding inaccessible or unreliable tools and those requiring extra specifications or hardware-dependent inputs.Nine tools were evaluated for Stage 2 and Stage 3; ICICLE was excluded because its fuzzing front end overlaps with MultiFuzz and its peripheral emulation depends on Fuzzware.Source: A. Evaluation Scope · p. 7, C. Stage 2: Emulation Initialization · p. 8
  • After filtering 25,654 collected files, the study identified 4,571 unique ARM Cortex-M firmware binaries for the analysis pipeline.The collection came from OTACap and FirmLine; filtering retained executable assembly and identified ISAs.Source: A. Evaluation Scope · p. 7

B. Stage 1: Emulation Configuration Reconnaissance

  • FirmXRay, FirmLine, and rbasefind produced 2,468, 391, and 1,227 candidates that passed initial screening, respectively.Because ground-truth base addresses and entry points were unavailable, screening checked whether execution continued beyond 10 unique instructions within the first 10,000 executed instructions.Source: B. Stage 1: Emulation Configuration… · pp. 7–8, Table IV · p. 8

C. Stage 2: Emulation Initialization

  • Stage 2 experiments used the 2,468 samples whose FirmXRay-generated base addresses and entry points passed verification.FirmXRay was selected for subsequent experiments because it significantly outperformed FirmLine.Source: C. Stage 2: Emulation Initialization · p. 8

1) Decoupled Emulator–Fuzzer:

  • P2IM, AIM, and DICE failed on all 2,468 images; µEmu generated peripheral models for only 295 within the one-hour limit.P2IM, AIM, and DICE either aborted or remained in peripheral-modeling loops; µEmu’s concolic execution encounters path explosion on real-world firmware.Source: 1) Decoupled Emulator–Fuzzer · p. 8

2) Co-Designed Emulator–Fuzzer:

  • Fuzzware, GDMA, and MultiFuzz failed to emulate 997, 1,006, and 969 samples, respectively; AidFuzzer failed on 2,460, with only 8 successful emulations.The initialization test used three 512-byte seeds and treated execution beyond three million basic blocks without input consumption as a hang.Source: 2) Co-Designed Emulator–Fuzzer · p. 8, Table V · p. 8

D. Stage 3: Fuzzing and Runtime Results

The study finds limited fuzzing coverage and many false crashes or hangs, while diagnosis often identifies only the immediate symptom rather than the earlier emulation error. Across the pipeline, configuration, emulation fidelity, scalability, and interoperability constrain practical analysis.

D. Stage 3: Fuzzing and Runtime Results

  • Average fuzzing coverage was 9% to 11%; Hoedur achieved the highest overall coverage, with relatively small differences in most cases.Crashes occurred in 521/1,471 Fuzzware, 681/1,499 MultiFuzz, and 619/1,485 Hoedur supported samples; most were false positives, and hang counts differed because Hoedur did not deduplicate hangs.Source: D. Stage 3: Fuzzing and Runtime Results · p. 9

E. Stage 4: Bug Diagnosis

  • Among 100 sampled crashes, FirmRCA diagnosed 98, but only 79 reports identified an instruction related to the immediate crash cause, not necessarily the underlying cause.Manual validation found all 98 diagnosed crashes were false crashes caused by emulation problems P7–P9.Source: E. Stage 4: Bug Diagnosis · p. 9

V. MAIN FINDINGS FROM THE EMPIRICAL STUDY

  • The evaluation shows attrition across stages: initialization failures prevent some samples from reaching fuzzing, and many reported crashes and hangs are false positives.Figure 4 summarizes sample attrition, stage-specific failures, and tool compatibility across the pipeline.Source: §V · p. 9, Figure 4 · p. 10
  • Configuration reconnaissance can fail when tools rely on sparse address clues, overweight duplicates, or assume the interrupt vector table begins at the image start.Firmware headers or metadata before the vector table can yield an invalid entry point and immediate configuration-verification failure.Source: §V · pp. 9–10
  • Incomplete instruction support and generic memory maps cause false crashes or initialization failures on legitimate firmware instructions and device-specific memory regions.Fuzzware’s unsupported instructions caused 12,315 false crashes across 74 samples; generic maps also miss external regions and can conflict with ROM placement.Source: §V · pp. 10–11
  • Long peripheral-initialization delay loops can exhaust emulators’ execution limits before fuzzing reaches subsequent code.In sample #7658, a delay executes over three million basic blocks, the timeout threshold used by Hoedur and MultiFuzz.Source: §V · p. 11
  • Incorrect interrupt timing and low-fidelity peripheral models drive infeasible executions, false crashes, and hangs.Broad CR/SR/DR register abstractions can miss richer peripheral semantics, including address-related metadata used to access peripheral memory.Source: §V · p. 11
  • Poor scalability, implementation defects, missing prerequisites, limited architecture support, and weak interoperability constrain practical tool use across the workflow.FirmLine consumed over 200 GB in some cases; most decoupled tools did not finish peripheral modeling within one hour for most samples, and Stage-3 tools were often tied to specific Stage-2 implementations.Source: §V · p. 12

VI. FUTURE DIRECTIONS

The paper proposes six directions for more reliable, scalable, and comparable MCU firmware analysis. They address configuration recovery, reusable emulation, peripheral fidelity, postmortem diagnosis, realistic benchmarks, and standardized evaluation.

D1. Emulation Configuration Reconnaissance

  • Recover platform configuration from complementary structural and semantic evidence, and represent uncertainty so downstream tools can refine or reject ambiguous configurations.The proposed recovery spans ISA, execution mode, memory layout, entry point, HAL functions, MCU model, and other platform metadata.Source: §VI · p. 12

D2. Extensible Emulation Frameworks

  • Build extensible emulation frameworks with stable APIs separating CPU execution, hardware modeling, event scheduling, and analysis.The proposed interfaces cover memory maps, MMIO, interrupts, DMA, state inspection, tracing, and feedback.Source: §VI · p. 12

D3. High-Fidelity Automatic Peripheral Modeling

  • Develop reusable peripheral-behavior repositories and context-sensitive models that expose their assumptions and uncertainty.The direction addresses heuristic inaccuracies while recognizing that higher-fidelity methods may require HAL code or MCU specifications unavailable for black-box firmware.Source: §VI · p. 12

D4. Emulation-Based Postmortem Analysis

  • Combine inputs, control and data dependencies, peripheral and interrupt events, and emulator state in replayable traces for postmortem analysis.Such traces are proposed to distinguish firmware bugs from modeling artifacts, group related failures, and identify triggering operations and earlier state corruption.Source: §VI · p. 12

D5. Realistic and Unified Benchmarks

  • Create unified benchmarks spanning architectures, vendors, models, RTOSes, and peripheral classes, with ground truth for configuration, behavior, vulnerabilities, inputs, and root causes.The paper also calls for fidelity metrics based on trace and state agreement, rather than only boot or execution progress.Source: §VI · p. 13

D6. Standardized Evaluation Criteria

  • Standardize reporting of prerequisites, assumptions, manual effort, resource use, tool versions, and pipeline-specific evaluation criteria.The recommendations include consistent definitions for fuzzing initialization, throughput, coverage, timeouts, crashes, hangs, deduplication, and false-positive validation.Source: §VI · p. 13

VII. DISCUSSION AND LIMITATIONS

The study finds that prior challenges remain unresolved and that pipeline-wide evaluation exposes issues missed by studying emulation, fuzzing, and diagnosis in isolation. Its findings are bounded by tool eligibility, ARM-only scope, and subjective judgments in some empirical assessments.

A. Progress on Past Challenges, Persistent Issues, and Emerging Challenges

  • None of the challenges identified by prior SoKs is fully resolved, despite advances in mitigation techniques.The pipeline perspective also uncovers difficulties distinguishing firmware defects from emulation-induced crashes and diagnosing their root causes.Source: A. Progress on Past Challenges,… · p. 13

B. Limitations of This Study

  • Pipeline incompatibility excludes tools requiring inputs or configurations unavailable for black-box firmware, and this selection may bias findings about P4–P9.Examples include high-fidelity peripheral-modeling tools that require hardware manuals or source-level HAL/driver code.Source: B. Limitations of This Study · p. 13
  • The evaluation does not test non-ARM firmware, so its findings are not directly applicable to other architectures.Source: B. Limitations of This Study · p. 13
  • Some conclusions may reflect subjective judgments in empirical assessments, despite efforts to provide evidence and rationales.The paper gives the threshold of 10 valid functions for distinguishing firmware from non-code blobs as one example of an assessment choice.Source: B. Limitations of This Study · p. 13

VIII. CONCLUSION

The study evaluates emulation-based MCU firmware analysis across a unified four-stage workflow, identifying recurring technical and engineering pitfalls. It also documents ethical boundaries and releases artifacts intended to support future research.

VIII. CONCLUSION

  • The four-stage evaluation and case studies expose fragile configuration inference, incomplete emulation, low-fidelity peripheral models, unreliable crash diagnosis, and engineering limits.The workflow covers configuration reconnaissance, emulation, fuzzing, and bug diagnosis.Source: §VIII · p. 13

ETHICAL CONSIDERATIONS

  • Crash validation remains incomplete: manual review of tens of thousands of reported crashes is infeasible, and no previously unknown vulnerability has been confirmed.Unverified crash statistics are released only in aggregate; firmware images are not redistributed, and researchers can reconstruct the benchmark from authorized sources and hashes.Source: ETHICAL CONSIDERATIONS · p. 13

OPEN SCIENCE AND ARTIFACT AVAILABILITY

  • The artifact release includes the evaluation framework, tool snapshots and configurations, stage-by-stage results, and supporting empirical details.The listed results include stage outputs, failure categories, fuzzing coverage and crash counts, and FirmRCA diagnostics with manual verification.Source: OPEN SCIENCE AND ARTIFACT AVAILABILITY · pp. 13–14
  • The benchmark can be reconstructed using firmware hashes, source-dataset identifiers, and mappings, while firmware images themselves are not redistributed.The reconstruction metadata also includes identifiable vendor, OS, and device or MCU information.Source: ETHICAL CONSIDERATIONS · p. 13, OPEN SCIENCE AND ARTIFACT AVAILABILITY · p. 14

APPENDIX

The appendix records the study’s literature scope and provides supplementary dataset descriptions. It reports source-dataset and vendor distributions for the evaluated firmware.

A. Additional Literature Scope •

  • The literature-scope list includes additional conferences and journals spanning security, software engineering, and dependable systems.The listed venues include ESORICS, EuroS&P, TDSC, TIFS, ACSAC, Asia CCS, RAID, ASE, ESEC/FSE, ISSTA, ICSE, and DSN.Source: A. Additional Literature Scope • · p. 16

B. Dataset ISA Identification

  • The appendix includes a table summarizing ISA identification for the collected dataset; its caption does not provide the identification results.The supplied table caption names the scope but gives no cell values.Source: Table X · p. 17

C. MCUs and MCU Vendors of Firmware Samples Used in Previous Works

  • A separate table summarizes MCU and vendor statistics from 133 firmware samples used in prior fuzzing-only studies.The supplied caption provides the total sample count but no distribution values.Source: Table XI · p. 17

D. Vendor and Source Distribution of Our Dataset

E. Hashes of Mentioned Firmware Samples

The appendix documents sample-identification aids, resource-intensive FirmLine cases, evaluation thresholds, and a comparison of Fuzzware with GDMA. It also specifies how two fuzzers classify failures.

E. Hashes of Mentioned Firmware Samples

F. Resource-Intensive FirmLine Failure Cases

G. Rationales of Empirical Threshold Selections

  • The study uses at least 10 valid functions to classify a binary as firmware, at least 10 unique instructions among the first 10,000 executed for preliminary base-address verification, and at least 10% coverage to select Stage 4 cases.The authors say the 10% Stage 4 threshold prioritizes higher-coverage crashes because FirmRCA is computationally expensive, while acknowledging potential bias.Source: G. Rationales of Empirical Threshold… · p. 18

H. Comparison of Fuzzware With and Without GDMA

  • GDMA recognized DMA models in 35 test cases, producing 920 additional crashes and increasing coverage by only 1.09% on average among those cases.The comparison table lists only 27 cases with recognized models and observable result differences.Source: H. Comparison of Fuzzware With and… · p. 18, Table XV · p. 18

1) Fuzzware:

  • Fuzzware classifies unmapped reads, writes, and fetches separately, while Hoedur combines several memory faults into crashes and defines hangs by input-consumption intervals.Fuzzware’s hang criterion is no input consumed within the first 3,000,000 executed basic blocks; Hoedur also checks for no input within 150,000 blocks after the last consumption.Source: 1) Fuzzware · p. 18, 2) Hoedur · p. 18

3) MultiFuzz:

The appendix explains minor failure categories, deduplication approaches, and seed-level initialization results. It attributes several failure categories to implementation or emulation issues while leaving some causes unresolved.

J. Crash Counts in Minor “Other” Categories

  • Several reported failure categories reflect implementation defects: reset failures arise from unhandled VECTRESET, while MultiFuzz’s unaligned-execution and instruction errors are linked to disassembly problems.The causes of InternalError remain unidentified.Source: J. Crash Counts in Minor “Other”… · p. 19

K. Crash and Hang De-duplication Strategies

L. Detailed Fuzzing Initialization Results Across Seeds

M. Heuristic Attribution of False Crashes and Hangs

The appendix uses suspicious crash and hang signatures to approximate false-failure causes, while acknowledging that these heuristics are not exact causal classifiers. It also presents per-tool false-crash counts and root-cause categories.

M. Heuristic Attribution of False Crashes and Hangs

  • The attribution heuristics approximate problem prevalence: matching signatures do not prove a cause, and failures without them may still have that cause.Some causes cannot be quantified reliably, so reported problem ratios may not sum to 100%.Source: M. Heuristic Attribution of False… · p. 20
  • Unsupported-instruction crashes use tool-specific exceptions; inaccurate-layout crashes involve unmapped addresses within potentially valid ARM memory regions.Interrupt-timing false crashes are associated with interrupt-context crashes involving uninitialized-pointer accesses.Source: M. Heuristic Attribution of False… · p. 20
  • Peripheral-response or peripheral-modeling crashes are associated with faults in peripheral, system-peripheral, or otherwise unmapped regions, which inaccurate values may indirectly target.False hangs attributed to these causes cannot be reliably distinguished from other hang causes and are not quantitatively assigned.Source: M. Heuristic Attribution of False… · p. 20
  • Implementation-limit failures use tool-specific signatures; MultiFuzz mode-transition defects, for example, appear as ReadPerm exceptions with an UnknownError::READ_PROT subtype.Source: M. Heuristic Attribution of False… · p. 21

N. Details of false-crash counts and problem categories

  • Appendix N provides false-crash counts and root-cause categories for GDMA (Fuzzware), MultiFuzz, and Hoedur, alongside a legend defining crash-type categories.The supplied captions identify the tables' scope but do not state their cell values.Source: Table XXIX · p. 21, Table XXX · p. 21, Table XXXI · p. 21
Loading 2609.38872v1…