{"id":"283aa807-fa79-48c3-b95e-874349e6ab27","arxiv_id":"2412.12746","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Firmware transplantation runs Cortex-M binaries natively on Cortex-A hosts, cutting MCU fuzzing time by up to 8x.","lead":"EmbedFuzz rewrites microcontroller firmware so it runs directly on faster server-class Arm chips, avoiding the slow emulation step used by older tools. This makes automated bug hunting in small IoT devices faster and cheaper, which matters as more everyday objects connect to the internet.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The most load-bearing concern is the unvalidated fidelity of the interrupt and exception model in transplanted firmware, which the paper itself concedes is a best-effort approximation, and the coverage and bug-finding results do not independently demonstrate semantic equivalence with real MCU…","rationale":"The paper's central claim is that transplantation yields fast native execution without sacrificing functional equivalence, and the evaluation's throughput and energy numbers depend on that equivalence being representative. The weakest point is the interrupt/exception model, which the paper itself flags in Section 7 as a best-effort approximation. The reader's verdict centered on the HAL-library scope limitation; that is real and properly flagged, but the more load-bearing gap for the correctness of the specific evaluation is the unmeasured fidelity of the interrupt model. The paper's own Table 2 and coverage analysis compare against emulator-based tools, not real hardware, so they cannot establish semantic equivalence. A concrete test is to compare interrupt/timing behavior against real hardware or a cycle-accurate reference on one or more of the 10 firmware targets. The overall CONDITIONAL verdict remains appropriate, and the revision should either add such a validation or explicitly present the fidelity claim as a demonstrated engineering trade-off rather than a validated equivalence.","tokens_in":28813,"tokens_out":1221,"duration_ms":11966,"concrete_test":"Instrument EmbedFuzz and a real board (e.g., the P2IM target's physical MCU, or a cycle-accurate simulator) with the same input sequence and trace peripheral read/write ordering and interrupt delivery points; if the instruction-count-based scheduler delivers interrupts at materially different points than the real hardware for even one evaluated firmware, the fidelity claim requires an explicit caveat, and RQ5 should be downgraded to an open question.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim requires that native execution preserves firmware semantics closely enough for the fuzzing results to be valid. Section 4.3 and Section 7 describe a virtual-clock-based interrupt scheduler that delivers interrupts at fixed instruction-count intervals, and Section 7 explicitly concedes that this 'may not accurately match the time executed in real firmware' and that interrupt simulation 'cannot simulate a real interrupt-based system's behavior with 100% accuracy.' The evaluation never validates this model against execution on real MCU hardware: RQ5 is argued qualitatively rather than measured. The bug-finding results in Table 2 do not close this gap, because cross-fuzzer agreement does not establish fidelity, and the claimed false positives in Fuzzware (IDs 20, 25, 26) are classified using EmbedFuzz's own interrupt semantics as ground truth. If instruction-count-based interrupt timing diverges from real-world timing, the reported coverage comparisons and bug classifications rest on an unvalidated model, and the claimed functional equivalence that distinguishes transplantation from emulation is not established.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"EmbedFuzz proposes firmware transplantation: a static binary rewriting workflow that converts Arm Cortex-M MCU firmware into a Linux user-space process for Arm Cortex-A hosts, running most instructions natively while a runtime emulates MCU-specific behavior (banked stack pointers, exception entry/return, interrupts) and HAL-level peripherals via high-level modeling. The paper claims up to eight-fold higher fuzzing throughput than P2IM and Fuzzware, at least four-fold energy efficiency, and seven distinct bugs found on the P2IM dataset of ten firmware images. The evaluation uses ten 24-hour trials per system, a public dataset, and open-source code, and the paper includes a case study on FreeRTOS task switching.","tokens_in":28871,"tokens_out":4255,"duration_ms":37432,"significance":"If the central claims hold, transplantation is a genuinely new point in the MCU rehosting design space: it avoids the emulation tax by exploiting the Thumb-2 overlap between Cortex-M and Cortex-A, and it enables standard user-space tooling (e.g., GDB, AFL++) on firmware binaries. The paper reports substantial engineering: a custom static rewriter, trap-and-emulate for special instructions, exception entry/return emulation, and both C and Python HAL handlers, with the implementation released as open source. The evaluation is more thorough than typical for the area (ten 24-hour trials per campaign, public P2IM benchmark, explicit seed policy). However, the headline throughput and energy claims are confounded by running the compared systems on different hardware, and the evaluation does not validate the interrupt/timing model against real MCU execution, so the confidence in the quantitative claims is currently limited.","major_comments":[{"comment":"The 'up to eight-fold throughput' and 'at least four-fold energy efficiency' claims are not cleanly attributable to transplantation, because EmbedFuzz ran on an NXP LX2160A (Arm Cortex-A72, 30W TDP) while P2IM and Fuzzware ran on an Intel Xeon Gold 5218 (125W TDP). The throughput difference could reflect CPU generation, microarchitecture, or clock behavior rather than native execution, and the energy difference is dominated by the platforms' respective TDPs and idle power draws (29.9W vs 84.0W in Table 3). To support the stated claims, the authors should run the emulation-based baselines on the same LX2160A hardware (or EmbedFuzz's qemu-user mode on the Xeon) and report throughput and energy per execution on a common platform.","section":"§6.1, §6.2, §6.5"},{"comment":"The paper's functional-equivalence claim rests on an interrupt model that the authors themselves concede is approximate: Section 4.3 delivers interrupts on an instruction-count-based virtual clock, and Section 7 states that this 'may not accurately match the time executed in real firmware' and 'cannot simulate a real interrupt-based system's behavior with 100% accuracy.' RQ5 (§6.7) is argued qualitatively, without measuring execution against real MCU hardware. Moreover, Table 2's classification of Fuzzware findings as false positives (IDs 20, 25, 26) uses EmbedFuzz's own interrupt configuration semantics as ground truth. An external fidelity check, such as a differential test against a real Cortex-M board or against an established emulator on the same input corpus, is needed before the equivalence claim can be accepted.","section":"§4.3, §7, §6.4"},{"comment":"The coverage comparison in Figure 3 is not apples-to-apples: EmbedFuzz redirects control at HAL entries, making HAL implementations unreachable, whereas Fuzzware and P2IM execute those blocks. The authors subtract a statically determined lower bound of HAL-only basic blocks from Fuzzware's coverage, but this does not fully correct for the different code populations, and the statement that 'EmbedFuzz outperforms P2IM in all ten cases' is misleading if total coverage, including HAL code, is considered. The RQ2 conclusion should be restricted to a common, method-independent set of application-level basic blocks, or the comparison should be presented as coverage above the HAL only.","section":"§6.3, Fig. 3"},{"comment":"The end-to-end applicability claimed in the abstract and introduction is narrower than stated because the method requires HAL libraries (or an embedded OS with a similar stable interface). Section 4.1 states 'we assume that HAL libraries are available to the analyst,' and Section 7 concedes that without such libraries 'EmbedFuzz cannot handle peripheral accesses triggered by the targeted firmware.' For firmware using direct MMIO or private peripheral libraries, the transplantation workflow as described cannot model interactions, so the supported firmware class should be stated in the abstract and used as a selection criterion for the dataset, rather than implying general coverage of MCU firmware binaries.","section":"§4.1, §7"}],"minor_comments":[{"comment":"The processor name is inconsistent: Section 6.1 says 'Intel Xeon Gold 5218' while Section 6.5 and Table 3 say 'Intel Xeon Gold 5128'.","section":"§6.5 and §6.1"},{"comment":"The bulleted list in Section 4 has typographical errors: 'i))' and 'ii))' instead of '(i)' and '(ii)'.","section":"§4.1 or §4.2"},{"comment":"There is a typo in 'high-performance dynamic analysis of embedded firmare' — should be 'firmware'.","section":"§6.7"},{"comment":"The qemu-user comparison used to motivate native execution should state explicitly which host hardware was used for that comparison, since the same-platform concern may apply there as well.","section":"§6.2"},{"comment":"The text says 'EmbedFuzz outperforms P2IM in all ten cases' immediately after noting that Fuzzware/P2IM 'can reach many more basic blocks'; clarifying which coverage metric (above-HAL vs total) is being used would avoid a misleading reading.","section":"§6.3"}],"recommendation":"major_revision","confidential_remarks":"The paper's technical idea is novel and the implementation appears substantial, but the quantitative claims need to be repositioned around a same-hardware comparison and a validated interrupt/timing model. The HAL dependency is a scope restriction that should be made prominent. I would be supportive after the authors add the missing fidelity experiment and rerun the comparisons on a common platform."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should read this one. EmbedFuzz's static transplantation trick is genuinely new: HALucinator stayed on QEMU, Safirefuzz did dynamic rewriting, para-rehosting needed source code, and this is the first end-to-end system that statically rewrites Cortex-M binaries into native Linux user-space processes on Cortex-A and makes fuzzing work. The runtime mechanisms are concrete and clever: banked stack pointers mapped through d16+ vector registers, exception-return magic values mapped to software routines, bkpt-immediate trap-and-emulate for svc/cps/coprocessor instructions, and inline replacement of trivial HAL functions. The Soldering Iron/FreeRTOS case study explains precisely why hal-fuzz and Safirefuzz break on the P2IM dataset, which is the kind of direct comparison work that clarifies the field.\n\nThe evaluation is mostly solid: ten 24-hour trials, a public dataset, and the native-versus-qemu-user comparison on the same Arm host is the right control, supporting roughly a 7x advantage from native execution alone. The authors are also honest about scope: Section 7 concedes HAL dependence, no MPU support, and that interrupt simulation is best-effort. That honesty earns real credit.\n\nThe soft spots are real but fixable. First, the headline 'up to 8x throughput, at most a fourth of the energy' compares EmbedFuzz on an Arm LX2160A against P2IM and Fuzzware on an Intel Xeon Gold. Different ISAs, different TDPs — the energy claim especially is mostly the datacenter hardware, not the technique. The same-hardware qemu-user comparison is the cleaner evidence and should lead the paper. Second, the coverage summary overstates: after subtracting HAL code, EmbedFuzz matches or beats Fuzzware in 5 of 10 cases, yet Section 6.3 says it outperforms both. Third, on the interrupt-fidelity concern: it lands, but not as a fatal flaw. Instruction fidelity is high by construction since most code runs natively; it's the virtual-clock interrupt timing that is approximate, and the paper says so. The sharper issue is classifying Fuzzware's IDs 20/25/26 as false positives using EmbedFuzz's own interrupt semantics as ground truth; 'not triggered under our model' would be more precise. RQ5 stays qualitative; one real-hardware spot check would substantially strengthen it. Minor: released code without a commit hash, and the roughly 10% uninstrumented basic blocks are acknowledged as a coverage lower bound.\n\nThis is a serious systems paper for the embedded-firmware fuzzing crowd. The flaws are in the comparison framing and the fidelity evidence, not in the core technique. Send it to serious peer review; with a revised performance framing and a toned-down RQ5 it should be accepted.","headline":"Genuinely new transplantation technique with a substantial implementation; the headline 8x/4x numbers are muddied by cross-hardware comparison and RQ5's fidelity claim is argued rather than measured, but the core approach is sound and deserves a serious referee.","tokens_in":29571,"tokens_out":4941,"would_cite":true,"duration_ms":44547,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"By statically rewriting Cortex-M firmware into native Cortex-A Linux processes, EmbedFuzz achieves up to eightfold higher fuzzing throughput than emulation-based rehosting.","keywords":["firmware transplantation","rehosting","fuzzing","Arm Cortex-M","static binary rewriting","high-level modeling","coverage-guided fuzzing","MCU firmware"],"falsifier":"A concrete falsifier is a Cortex-M firmware whose peripheral I/O is implemented through direct MMIO with no HAL symbols: EmbedFuzz should still transplant and fuzz it end-to-end, and a failure to do so would show that the claimed general applicability collapses outside HAL-based firmware.","tokens_in":28426,"feed_emoji":"⚡","tokens_out":7790,"duration_ms":63722,"temperature":0.7,"pith_summary":"EmbedFuzz sets out to eliminate the emulation tax that dominates fuzzing of low-end microcontroller firmware. Its central proposal, called transplantation, is to statically rewrite a binary Cortex-M firmware image into a Linux user-space process that runs on Arm Cortex-A hardware, so the majority of instructions execute natively at server speed while a small runtime handles the architectural and peripheral differences. The paper reports that transplanted firmware fuzzes up to eight times faster than emulator-based rehosters, consumes at most a quarter of the energy, and still reproduces seven distinct bugs in a ten-firmware benchmark. A sympathetic reader would take the core claim to be that native execution plus careful handling of ISA and peripheral semantics can displace emulation as the default rehosting strategy for HAL-based MCU firmware.","feed_headline":"Cortex-M firmware transplanted to Linux fuzzes up to 8x faster","feed_subtitle":"EmbedFuzz rewrites bare-metal binaries into native Cortex-A processes, cutting emulation overhead and energy use by up to 4x.","key_machinery":"The central mechanism is the transplantation pipeline itself: a static binary rewriter that preserves the MCU's flat physical address layout in a user-space virtual address space, rewrites or traps the handful of Thumb-2 instructions whose behavior differs between Cortex-M and Cortex-A, instruments basic blocks for coverage, and replaces HAL functions with in-process handler calls; the companion runtime emulates exception entry/return, banked stack-pointer switching using Cortex-A-only floating point registers, and interrupt scheduling on an instruction-counted virtual clock. The key design decision is that only the semantically divergent instructions and peripheral interfaces are emulated, while all other code executes natively, which is what converts the emulation tax into a small runtime surcharge.","core_discovery":"Transplantation treats the overlap between the Arm Cortex-M and Cortex-A instruction sets as a resource rather than a problem. EmbedFuzz keeps the firmware's physical address-space layout intact inside a Linux process's virtual memory, copies most code unchanged, rewrites the few semantically different instructions (for example svc becomes a bkpt trap and mrs/msr accesses to the banked stack pointer are mapped to unused floating-point registers), and inserts coverage instrumentation plus branches to HAL peripheral handlers. The runtime then emulates only what cannot be rewritten: Cortex-M exception entry and return, switching between SP_main and SP_process, virtual-clock-based interrupt delivery, and the peripheral handlers reached through high-level modeling. In the paper's evaluation on ten real-world firmware images from the P2IM dataset, this yields up to eightfold higher executions per second than P2IM or Fuzzware, total system power draw of about 47 W versus 197 W, and reproduction of seven distinct bugs, while coverage above the HAL is at least on par in five of ten cases.","pith_inferences":["If transplantation holds up, the same ISA-overlap argument points toward Cortex-R firmware and other architecture pairs with similar superset relationships, but the paper's throughput gains would need re-measurement on workloads that trap heavily, where kernel context-switch overhead could erode the native-speed advantage.","The coverage comparison suggests that HAL-level rehosting deliberately trades away visibility below the HAL; an extension that combines transplantation with lightweight MMIO modeling for non-HAL firmware would test whether the speed gain survives outside the HAL-based firmware class.","Native Linux-process execution could enable sanitizers, hardware performance counters, and differential testing between the transplanted firmware and the original MCU, none of which the paper evaluates but all of which follow directly from the approach.","The virtual-clock interrupt scheduler is acknowledged as best-effort; a direct comparison of bug-finding and timing fidelity against the same firmware on real hardware would quantify how much fidelity is lost when instruction counts stand in for wall-clock time."],"forward_implications":["MCU fuzzing campaigns can run on Arm server hardware at native speed, so the number of executions per second, and therefore the input space explored, grows by up to a factor of eight relative to emulation-based fuzzers.","Because the transplanted firmware is an ordinary Linux process, standard tools such as AFL++, GDB, Valgrind, and fork-based process replication can be used without emulator-specific debugger stubs, simplifying crash triaging and horizontal scaling.","The measured power draw (about 47 W for the whole Arm system versus 197 W for the x86 system) means large-scale campaigns can be run with at least a fourfold improvement in energy efficiency, reducing infrastructure cost.","Peripheral handlers are written once per HAL and reused across firmware sharing that HAL (seven of the ten evaluated firmware use the STM32 HAL), so the one-time modeling effort amortizes.","Interrupts are only delivered after the firmware has configured them, which avoids false-positive bugs caused by premature interrupt delivery that plague some emulators."],"supporting_citations":[{"why":"Supplies the high-level modeling principle and reusable peripheral handlers that EmbedFuzz's runtime intercepts and extends.","marker":"[17]"},{"why":"Provides the ten-firmware evaluation dataset and is the primary emulation-based baseline for throughput, coverage, and bug-finding comparisons.","marker":"[23]"},{"why":"Provides the second emulation-based baseline (Fuzzware) and the bug identifiers used in the bug-finding comparison.","marker":"[60]"},{"why":"Concurrent approach also exploiting Arm Cortex-M/A ISA similarity; EmbedFuzz contrasts its handling of semantic differences such as svc and PendSV.","marker":"[62]"},{"why":"QEMU is the emulation engine behind the compared fuzzers and the source of the emulation tax that transplantation is designed to remove.","marker":"[10]"},{"why":"The Armv7-M architecture manual defines the special registers, exception entry/return behavior, and Vendor_SYS region that the rewriting and runtime must model.","marker":"[6]"},{"why":"The AAPCS defines the calling convention that lets runtime handlers access HAL function arguments and return values directly.","marker":"[9]"}],"fun_headline_variants":["Transplant MCU firmware to native ARM for 8x fuzzing speed","Fuzz MCU firmware at native speed: EmbedFuzz transplants to Linux","EmbedFuzz: 8x faster fuzzing by running Cortex-M code natively on Cortex-A","No emulation overhead: EmbedFuzz transplants MCU firmware for 8x throughput","From MCU to Linux: Transplanted firmware fuzzes 8x faster, uses 4x less energy"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the firmware talks to its hardware through vendor hardware-abstraction libraries (or an embedded OS with a similarly stable interface) whose function boundaries can be located and intercepted; firmware that drives peripherals by writing directly to device memory addresses, or through private libraries, cannot be transplanted by EmbedFuzz.","fun_headline_variants_meta":{"raw":{"variants":["Transplant MCU firmware to native ARM for 8x fuzzing speed","Fuzz MCU firmware at native speed: EmbedFuzz transplants to Linux","EmbedFuzz: 8x faster fuzzing by running Cortex-M code natively on Cortex-A","No emulation overhead: EmbedFuzz transplants MCU firmware for 8x throughput","From MCU to Linux: Transplanted firmware fuzzes 8x faster, uses 4x less energy"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000912,"raw_usage":{"total_tokens":3915,"prompt_tokens":937,"completion_tokens":2978,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":553,"completion_tokens_details":{"reasoning_tokens":2874}},"tokens_in":553,"tokens_out":2978,"duration_ms":18717,"temperature":1.0,"reasoning_tokens":2874,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T13:47:11.570172+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A concrete falsifier is a Cortex-M firmware whose peripheral I/O is implemented through direct MMIO with no HAL symbols: EmbedFuzz should still transplant and fuzz it end-to-end, and a failure to do so would show that the claimed general applicability collapses outside HAL-based firmware.","supporting_citations":[{"cited_title":"Clements, Eric Gustafson, Tobias Scharnowski, Paul Grosen, David Fritz, Christopher Kruegel, Giovanni Vigna, Saurabh Bagchi, and Mathias Payer","cited_arxiv_id":null,"evidence_quote":"Supplies the high-level modeling principle and reusable peripheral handlers that EmbedFuzz's runtime intercepts and extends."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the ten-firmware evaluation dataset and is the primary emulation-based baseline for throughput, coverage, and bug-finding comparisons."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the second emulation-based baseline (Fuzzware) and the bug identifiers used in the bug-finding comparison."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Concurrent approach also exploiting Arm Cortex-M/A ISA similarity; EmbedFuzz contrasts its handling of semantic differences such as svc and PendSV."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"QEMU is the emulation engine behind the compared fuzzers and the source of the emulation tax that transplantation is designed to remove."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The Armv7-M architecture manual defines the special registers, exception entry/return behavior, and Vendor_SYS region that the rewriting and runtime must model."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The AAPCS defines the calling convention that lets runtime handlers access HAL function arguments and return values directly."}],"review_version":1}