arXiv CSopen access

FirmCure:Towards Autonomous and Adaptive Rehosting of Linux-Based Firmware

F IRM C URE : Towards Autonomous and Adaptive Rehosting of Linux-Based Firmware Chuan Hong* , Zheng Zhang, Lei Zhou*§ , Laisong Li, Chenyifan Liu, Ze Huang, Xu Zhou*§ , and Peihong Lin

arXiv:2606.24549v1 [cs.CR] 23 Jun 2026

National University of Defense Technology {hongchuan24, zhangzhengnudt, zhoulcs, lilaisong, liuchenyifan, huangze, zhouxu, phlin22}@nudt.edu.cn

Abstract—Full-system rehosting plays a critical role in the security analysis of Linux-based firmware. It matches commonly deployed firmware with sufficient background knowledge. However, for custom devices, existing approaches struggle to handle initialization and runtime obstacles in the rehosting process caused by specialized architectures and hardware-dependent configuration, which heavily rely on expert intervention. This ultimately creates fundamental bottlenecks and results in low rehosting efficiency. To address the above challenges, we propose F IRM C URE , the first LLM-driven full-system rehosting framework designed for autonomous and adaptive rehosting of Linux-based firmware. F IRM C URE develops an Adaptive Perception Inference mechanism to extract firmware structural dependencies via static analysis, followed by a Reflective Synthesis module for iterative configuration optimization, and finally an Autonomous Runtime Intervention module for real-time error remediation through runtime fault diagnosis and monitoring. We evaluated 21 IoT firmware images from 10 vendors across 5 architectures, while F IRM C URE achieved a 100% network port opening rate and 90.5% service interactivity, substantially outperforming state-ofthe-art baselines. Our experiments confirm that F IRM C URE ’s intervention strategies generalize across heterogeneous firmware. The framework successfully reproduces known vulnerabilities and discovers new security flaws.

I. I NTRODUCTION The rapid development of Internet of Things (IoT), projected to exceed 50 billion devices by 2035 [1], necessitates urgent security analysis, particularly for Linux-based firmware comprising 58% of devices [2]. Firmware rehosting technology, as base for dynamic analysis platform, can keep the services running without physical hardware dependency [3]– [6]. Especially for full-system rehosting, it can maintain the kernel interactions and runtime context, making it applicable for system-level vulnerability analysis [7]. For example, Recent studies, such as FirmSolo [8] and FirmDiff [9] pursue kernel compatibility by modifying the kernel. In contrast, Firmadyne [10] and FirmAE [11] substitute the original kernel with a pre-built kernel while retaining the target filesystem and user-space applications. However, the above approaches

preprint

adopt the controllable kernel deployment and fixed-ruled template mechanism to smoothly execute user-level applications, while avoiding complex system initialization issues caused by missing special hardware configuration. However, many issues remain unsolved, such as service crashes and deadlocks [12], which are still an unsolved challenge for firmware rehosting. In this work, we emphasize that the core obstacle of existing firmware rehosting approaches lies in case-specific and scenario-dependent complexities. First, complete initialization remains a key gap in firmware rehosting. The specialized hardware designs in custom devices are hard to be faithfully emulated, preventing existing approaches from achieving complete initialization. Full-system rehosting approaches [10], [11] treat the init routine as a black box and blindly execute, so any failure in a process unrelated to the target service can deadlock the entire initialization. User-mode rehosting approach Firmwell [12] attempts to mitigate this by running the full init and reactively fixing failures, but its heuristic repairs cannot handle unanticipated faults such as complex hardware probing or blocking ioctls. As a result, neither approach can balance preserving essential service dependencies against avoiding hardware-induced deadlocks, leaving the user-space environment inherently fragile. Second, resolving rehosting issues in custom firmware remains heavily manual and fails to scale. The process depends on either time-consuming manual intervention or pre-built rules that frequently fail. Booting a new firmware image requires carefully matching QEMU [13] parameters to the target architecture and filesystem layout, yet a single wrong combination causes a crash whose unstructured log rarely points to the faulty setting. Existing Approaches cannot derive the correct configuration automatically from such opaque feedback. Even after a successful boot, services run into unpredictable errors like binary crashes, missing files, or endless polling loops. FirmAE [11] carries a fixed catalog of heuristic arbitration strategies, and Greenhouse [14] relies on predefined intervention measures, but both only cover failures their designers have already seen. When a crash or hang falls outside that known set, the tool simply halts and offers no further help. Analysts must then reverse engineer the firmware, manually try different parameters, and improvise workarounds, a cycle that is slow, labor-intensive, and impossible to scale across diverse firmware images.

Third, existing LLM-based approaches remain confined to static analysis and struggle with runtime rehosting issues. The emergence of large language models (LLMs) [15]– [17] offers a new way to address the complexity of firmware rehosting, benefiting from their strong generalization ability to comprehend diverse hardware behaviors and runtime anomalies [18]–[20]. Nevertheless, simply deploying raw LLMs cannot achieve reliable rehosting in practice. In real scenarios, precise fault localization and reasonable remediation strategy formulation rely on customized prompt design and dedicated toolchain orchestration. However, existing LLMbased approaches [21] merely adopt LLMs for static knowledge extraction, such as parsing peripheral source code and modeling peripherals. They lack tailored customization and runtime tool cooperation, and thus fail to fully unleash the potential of LLMs in handling runtime failures. To address these limitations, we propose F IRM C URE , the first LLM-driven full-system rehosting framework for autonomous and adaptive rehosting of Linux-based firmware. F IRM C URE leverages the LLM-based agent’s ability to semantically understand heterogeneous initialization logic and its iterative reasoning cycle of planning, observation, and reflection [22]–[24] to dynamically diagnose and repair runtime failures. Moreover, the agent draws on embedded Linux domain knowledge and invokes specialized tools for binary analysis, filesystem repair, and network configuration verification. F IRM C URE organizes this intelligence into a closed-loop rehosting system structured around three sequential modules. The Adaptive Perception Inference module autonomously parses the firmware rootfs to extract architectural and service semantics, distinguishing hardware-dependent operations from critical service logic to synthesize a minimal context blueprint that isolates true execution dependencies. The Reflective Synthesis module translates this blueprint into a bootable environment through an iterative validation cycle, diagnosing boot failures from execution feedback and applying targeted repairs to kernel parameters or filesystem structures until kernel initialization and rootfs mounting are systematically stabilized. The Autonomous Runtime Intervention module continuously monitors post-boot execution states and dynamically routes runtime faults to specialized agents, resolving diverse anomalies through runtime binary execution bypass, environment remediation, and configuration adaptation to maximize progression across core rehosting metrics and continuously advance the rehosting state toward full service interactivity. We evaluated F IRM C URE on 21 firmware images from 10 vendors spanning 5 architectures. It achieves a 100% network port activation rate and 90.5% end-to-end service interactivity, substantially exceeding existing baselines. The multi-stage pipeline generalizes across heterogeneous targets, with each component independently resolving a distinct category of boot and runtime failures. F IRM C URE reproduced all ten target CVEs and discovered five previously unknown vulnerabilities in commercial devices, confirming its utility for practical security assessment.

In summary, we make the following contributions in this paper: We propose F IRM C URE , the first LLM-driven fullsystem rehosting framework that automates the entire rehosting lifecycle through a closed-loop pipeline of adaptive perception, reflective synthesis, and autonomous runtime intervention for Linux-based firmware. • We design a multi-agent runtime intervention mechanism that autonomously monitors post-boot execution states, dynamically routes diverse runtime faults to specialized agents, and orchestrates remediation strategies that continuously advance rehosting metrics toward full service interactivity. • We evaluate F IRM C URE on 21 IoT firmware images across 10 vendors and 5 architectures, achieving a 100% network port activation rate and 90.5% service interactivity, substantially outperforming state-of-the-art baselines. • We validate F IRM C URE ’s practical security impact by successfully reproducing known CVEs and discovering unknown vulnerabilities in commercial devices, demonstrating its effectiveness for real-world firmware security analysis. •

II. BACKGROUND A. Firmware Rehosting Firmware rehosting executes firmware images on a host via hardware emulation to enable dynamic analysis without physical devices [10], [13]. High-fidelity full-system rehosting of Linux-based firmware remains difficult because of heterogeneous hardware dependencies, driving state-of-the-art systems to prioritize restoring critical network services such as httpd and sshd for fuzzing [5], [10]–[12], [14]. User-mode Rehosting, as adopted by Greenhouse [14] and Firmwell [12], translates a single process and delegates syscalls to the host kernel, bypassing the original kernel and network stack. Fullsystem Rehosting, as demonstrated by Firmadyne [10] and FirmAE [11], virtualizes the entire platform, allowing the kernel to boot and network services to operate, making it the dominant choice for in-depth vulnerability analysis. Within full-system rehosting, handling the kernel follows two strategies, Kernel Modification and Kernel Replacement. The modification strategy, used by FirmSolo [8] and FirmDiff [9], reverse-engineers kernel configurations and corrects data-structure layouts, incurring heavy overhead from recompilation and manual alignment. The replacement strategy, pioneered by Firmadyne and extended by FirmAE, swaps the original kernel with a pre-compiled, closely-matching one while keeping user-space intact. This avoids the overhead of kernel modification and enables scalable automated testing. Because perfect hardware fidelity is infeasible, rehosting follows a best-effort principle, maximizing fidelity for securitycritical components and gracefully degrading non-essential dependencies, which is the core objective of F IRM C URE .

2

TABLE I FAILURE C ASES OF E XISTING F IRMWARE R EHOSTING A PPROACHES AND T HEIR M ANUAL R EPAIR S TRATEGIES Vendor

Device

Example

Failure Reason

Feasible Fix Strategy

Boot Stage

Totolink

NR1800X

Config Path Mismatch

lighttpd fails to locate config at non-standard path /lighttpd/lighttpd.conf

correct config path or create symlink

Service Runtime

Tenda

AC18

Service Early Exit

ConnectCfm routine invokes cfmd daemon, which terminates prematurely due to strict hardware dependencies

Bypass blocking calls via gdb breakpoints or dynamic instruction patching

Service Runtime

TP-Link

TL-IPC43AN

Missing Runtime Flag

Infinite polling loop waiting for missing flag file /tmp/jffs2_ready

Create file to break polling loop

Service Runtime

TRENDnet

TEW-813DRU

Initialization Deadlock

rcS script deadlocks due to unresolved hardware configuration dependencies

Inject minimal synthetic .cfg to decouple checks

User-space Init.

WAVLINK

NU516U1

Emulation Parameter Error

Kernel panic caused by CPU architecture mismatch during QEMU launch

Adjust -cpu 74Kf in QEMU launch command

Kernel Bootstrap

D-Link

DGL-5500

Filesystem Corruption

Broken symbolic links cause rootfs mount failure

Remove dangling symlinks & Restore missing libraries

Rootfs Mounting

C. LLM-Assisted Firmware Analysis

B. Runtime Environment Reconstruction

Recent advances in LLMs have demonstrated strong code comprehension and reasoning abilities [25]–[27]. The emergence of tool-use mechanisms [28]–[30], external knowledge bases [31], and LLM-based autonomous agents [32], [33] has further expanded the potential to automate complex systemlevel tasks. In the context of firmware rehosting, FlexEmu [21] leverages LLMs to model heterogeneous MCU peripherals by extracting semantic details from source code, reducing manual effort in peripheral emulation. These developments indicate that LLMs show growing promise for automating firmware rehosting tasks, though existing work remains focused on specific stages such as peripheral modeling.

The kernel replacement approach shifts the core challenge to runtime environment reconstruction. Since the generic kernel lacks hardware-specific drivers and configurations, the rehosting environment must be carefully reconstructed to approximate the physical device’s conditions by aligning kernel arguments, filesystem layouts, and device node populations with the original execution profile. This process unfolds across a multi-stage initialization workflow [10], [11], where each phase introduces distinct hurdles that impede full automation. Kernel Bootstrap. This phase demands precise QEMU parameters, including CPU architecture, memory allocation, and kernel command-line arguments, alongside repair of root filesystem defects such as structural corruption or format mismatches. FirmAE mitigates some compatibility issues through runtime kernel arbitration, but remains reliant on architecturedefault parameter templates. For firmware with vendor-specific dependencies or non-standard boot sequences, generic templates readily trigger rootfs mounting failures or kernel panics. User-space Initialization. User-space boot is driven by /etc scripts (e.g., rcS, init) encoding network setup, service dependencies, and hardware checks. FirmAE [11] heuristically locates and executes the original init scripts, appending its own helper scripts at the end, thus preserving the full boot sequence. However, without any semantic analysis or filtering, it treats hardware-related failures and legitimate service commands equally, thereby conflating essential service logic with redundant hardware probes and leading to deadlocks, termination, or incomplete initialization. Service Runtime. Once initialization completes, network services (e.g., httpd, sshd) face silent crashes, segmentation faults, and infinite polling loops due to unemulated peripherals. FirmAE distills common failure patterns from 437 firmware images into five predefined arbitration strategies. While effective for known failure modes, this static, rule-bound approach cannot adapt to novel crashes or cascading dependencies. Consequently, runtime failures halt rehosting, forcing manual log inspection and a mix of dynamic and static analysis until the service becomes interactive.

III. M OTIVATION Existing full-system rehosting frameworks (e.g., Firmadyne [10], FirmAE [11]) address rehosting environmental reconstruction challenges through static arbitration mechanisms based on empirically derived rules. While effective for wellstudied datasets, these approaches exhibit fundamental limitations when encountering diverse, unseen firmware images with complex environmental dependencies. The empirically derived rules lack generalization capability, rendering them ineffective against vendor-specific initialization logic or nonstandard hardware configurations. Consequently, successful rehosting still relies heavily on human expertise to manually identify QEMU parameters, patch initialization scripts, and diagnose runtime crashes. These approaches lack the capability to semantically understand initialization logic, iteratively refine boot parameters based on execution feedback, or autonomously remediate runtime errors. Empirical Observations. Our large-scale analysis of over 100 firmware images reveals that rehosting failures are highly heterogeneous and systematically cascade across the entire boot lifecycle. As summarized in Table I, these obstacles manifest as distinct, stage-specific barriers that collectively stall the rehosting pipeline, which cannot be addressed by existing Approaches [11], [12], [14]. At the Kernel Bootstrap and Rootfs Mounting stages, fundamental environment mismatches trigger immediate breakdowns. For the WAVLINK

3

(IV-C) Adaptive Perception Inference RE Basic Profiling

Filesystem

File Binary Firmware

Scripts

Firmware Analyst Agent

Init Sequence Analysis Context Synthesis

Filesystem Pre-processing

Filesystem repair

Runtime Check

Boot Outcome Assesment Adjust No

(IV-D) Reflective Synthesis

Service Start& Accessment

Startup Configuration

Instance Construction

Success

Log Observability

Binding Service Startup Scripts

Fuzz & Test

Intervention Manager

Knowledge Base

Hardcode Config

Command Argument Synthesis

Boot Repair Engineer

Network Config

Diagnosis Expert

Fault Reason

Crash Expert

Kernel

File Expert

Context Report

Web Expert

Service

Generic Expert

…

Specialized Intervention Expert

QEMU Instance

(IV-E) Autonomous Runtime Intervention

❌

Premature Process Exit

❌

Symbolic Link Corruption

❌

Critical File Missing

❌

File and Permission Error

❌

Network Port Conflict

❌

External Dependency Wait Loop

❌

External Network Access Failure

❌

Other Special Cases

Fig. 1. Overview of the F IRM C URE

NU516U1, a kernel panic is caused by an unspecified CPU architecture during QEMU launch, and an feasible fix strategy is to explicitly adjust the -cpu 74Kf parameter. Concurrently, the D-Link DGL-5500 fails to mount its root filesystem due to corruption and dangling symbolic links. These issues can be resolved by pre-boot repair routines that remove broken links and restore missing shared libraries. During User-space Initialization, boot scripts frequently encounter unresolvable hardware dependencies. The TRENDnet TEW-813DRU enters an initialization deadlock when the rcS script awaits unresolved hardware configurations, and a feasible repair strategy is to inject minimal synthetic .cfg files to decouple dependency checks and resume execution. Finally, at the Service Runtime stage, services face structural and environmental mismatches.The Totolink NR1800X crashes due to lighttpd configuration path mismatches, which can be addressed by redirecting startup parameters to the correct path or creating a symlink. The Tenda AC18 experiences premature daemon termination when the ConnectCfm routine invokes cfmd under strict hardware bindings, a problem that can be bypassed by inserting gdb breakpoints or dynamically patching instructions. And the TP-Link TL-IPC43AN remains trapped in an infinite polling loop waiting for a missing /tmp/jffs2_ready flag, where a straightforward fix is to dynamically generate the required placeholder file.

and obstacles, as detailed in Section IV.

Collectively, these cases demonstrate that rehosting obstacles are fundamentally multi-dimensional and contextdependent, spanning structural inconsistencies, fragile boot parameters, and unpredictable runtime states. Static arbitration mechanisms inherently fail to address this spectrum, as their fixed heuristics cannot adapt to cross-stage dependencies or dynamically synthesize phase-specific repairs. This systemic fragmentation highlights the need for a closed-loop, autonomous rehosting pipeline that can dynamically handle these obstacles. To this end, we propose F IRM C URE , an autonomous and adaptive framework that handles these processes

B. System Overview

IV. D ESIGN In this section, we present the design of F IRM C URE . We first define the problem scope (Section IV-A) and provide a system overview (Section IV-B), followed by a sequential description of the Adaptive Perception Inference module (Section IV-C), the Reflective Synthesis module (Section IV-D), and the Autonomous Runtime Intervention module (Section IV-E). A. Problem Scope F IRM C URE targets Linux-based embedded firmware on common IoT architectures via QEMU full-system rehosting. Our goal is to ensure network service interactivity to support downstream security tasks, not just availability. We operate on the premise that firmware images are obtainable from public online repositories, vendor download portals, or through direct extraction from physical IoT devices. These acquired images supply the root filesystem required to construct a functional rehosting environment. This work focuses on vulnerability discovery via dynamic analysis. Success is defined by network services such as httpd and sshd starting, listening on expected ports, and responding to requests.

F IRM C URE operates as an LLM-guided, closed-loop firmware rehosting framework structured around three sequential phases. As illustrated in Figure 1, the architecture orchestrates a continuous pipeline that transforms raw firmware binaries into stable, interactive rehosting environments. Each phase implements a distinct mechanism to address a specific stage of the rehosting lifecycle, progressively improving rehosting metrics. Adaptive Perception Inference (A.P.I) (§IV-C) employs an LLM-driven multi-stage analysis pipeline to autonomously

4

parse firmware rootfs, extract architectural and service semantics, and classify components into hardware-dependent and service-critical categories. By treating firmware exploration as a goal-directed reasoning process, this phase resolves initialization decoupling challenges and synthesizes a structured context blueprint that grounds downstream operations in accurate firmware semantics. Reflective Synthesis (R.S) (§IV-D) translates the extracted context into a bootable environment through filesystem prerepair and parameter synthesis. A synthesis agent drives a validation loop that watches the boot progress, identifies failures from the output, and applies targeted fixes to launch arguments or filesystem structures. After each repair, the system repackages the environment before the next boot attempt. This process stabilizes kernel boot loading and rootfs mounting across heterogeneous architectures. Autonomous Runtime Intervention (A.R.I) (§IV-E) deploys a hierarchical multi-agent framework that observes postboot execution states and dynamically routes runtime faults to specialized domain experts. Through targeted binary bypass, environment remediation, and network configuration adaptation, this phase systematically resolves post-boot service blockers. By iteratively applying expert-driven repairs, the module progressively improves the rehosting metrics until full service interactivity is established. Together, these three phases form a closed-loop rehosting pipeline unified by a cross-phase context cascade. All agents share a common semantic context across the pipeline. This context helps agents track state, accumulate useful knowledge, and decide what to do next. Each phase uses it to guide repairs. All analytical and synthetic operations ultimately converge on a centralized QEMU Instance, which serves as the persistent execution substrate for orchestrating initialization, stabilizing boot sequences, and validating runtime service responsiveness.

CGI paths. These attributes collectively establish the baseline context for all downstream analysis tasks. Building on this baseline, the agent proceeds to init sequence analysis and hardware dependency decoupling. The design of this component addresses a central tension in boot sequence reconstruction, since the init system must be simplified enough to run inside QEMU, yet no critical service dependency can be severed. To navigate this, we design a twophase analysis pipeline. The agent first reconstructs the full boot sequence by parsing the init system (rcS, inittab, profile), tracing the exact chain of script invocations and services launches. Hardware dependency classification then proceeds through two complementary mechanisms. The first is a set of prompt constraints encoding domain knowledge. The agent flags processes known to deadlock or crash inside QEMU, such as vendor-specific hardware daemons, watchdog timers, and wireless-related processes. The second mechanism relies on programmatic binary analysis. The agent inspects symbol tables for hardware-facing calls, scans for systemcall patterns that probe absent device nodes, and matches log strings against known hardware-initialization idioms. Inspired by Housefuzz [34], a deliberate design choice concerns binaries that are tightly coupled with servicecritical processes yet also carry hardware-probe logic, such as system_manager and ncc. Simple removal would sever essential IPC channels or configuration delivery paths. We therefore add a deeper reverse-analysis step. The agent traces how the binary interacts with the target service daemon, identifies the IPC mechanisms that deliver configuration or control commands, and reconstructs the communication protocol. The output is a semantic dependency summary that records three things. First, it notes what the binary provides to the service. Second, it specifies how the binary expects to be launched. Third, it details what minimal logic can replace it without hardware probing. This summary, together with the hardwaredependency manifest, is preserved in the context object and handed to later stages to inform both boot synthesis and runtime intervention. Next, the pipeline moves to context synthesis, where the agent generates a minimal startup configuration that achieves service interactivity with zero hardware probing. It rewrites the initialization script to skip hardware-dependent sections. It then validates that service-critical daemons such as the HTTP server and DNS proxy still receive their required IPC, network bindings, and configuration files. The output is a verified startup script and an environment profile that guarantee a deadlock-free transition from kernel handoff to user-space service launch. The suppression manifest is preserved alongside this script, documenting exactly which services were excluded and which hardware events they were waiting for. This creates a direct regression pathway. The Autonomous Runtime Intervention module can later consult the manifest and re-insert a previously suppressed service once the runtime environment gains the necessary virtual devices or network interfaces. The pipeline concludes by assembling the Structured System

C. Adaptive Perception Inference The Adaptive Perception Inference module takes the extracted firmware rootfs as input and produces a Structured System Context Object. This object consolidates CPU architecture, web service entry points, initialization dependency maps, and validated boot configurations. At the core of this module is a Firmware Analyst Agent, whose objective is to produce a minimal, hardware-decoupled execution context that prevents early-boot deadlocks while retaining full dependency information. This allows the Autonomous Runtime Intervention stage to selectively restore suppressed services in a stable environment. The module is achieved through a three-stage, LLM-guided analysis pipeline that progressively decouples hardware-specific probing from essential service logic. The pipeline begins with reverse engineering and basic profiling, where the agent extracts foundational attributes by inspecting ELF headers, filesystem layouts, and binary strings. It determines CPU architecture, endianness, and C library variant. It also locates the primary httpd binary and extracts its compile-time parameters such as web root, port, and

5

Context Object, which bundles the architectural profile, the minimal startup script, the environment configuration, and the suppression manifest. This design achieves two critical goals. First, it gives the R.S module with a clean, hardware-agnostic boot blueprint that dramatically reduces the search space for kernel parameter tuning. Second, it equips the A.R.I modules with complete semantic knowledge of previously excluded components, enabling it to autonomously re-integrate services when the runtime environment becomes capable of handling them. In this way, F IRM C URE enables a progressive rehosting strategy. First launch the minimum set of services needed to establish basic connectivity, then selectively restore additional components based on runtime error feedback.

ELF DYNAMIC segment patcher, allowing the same compatibility shim to be loaded even when preload-based interposition is not usable. These operations are orchestrated as a non-destructive process. Dependency-aware modifications preserve the original filesystem structure while surgically neutralizing hardware-specific initialization blockers. By resolving structural and dependency faults before the first boot attempt, the filesystem significantly reduces early-stage failures and narrows the configuration adjustments required during subsequent iterative refinement. Command Argument Synthesis and Boot Outcome Assessment. Rather than enumerating a large space of possible QEMU configurations, the module synthesizes the initial boot command directly from the Structured System Context Object produced by A.P.I module. The extracted architecture, memory layout, and kernel entry point provide a grounded starting estimate. This rules out broad categories of invalid combinations and forms a high-confidence hypothesis, so that subsequent refinement only needs to correct a small number of residual mismatches. At each boot attempt, the module monitors the QEMU serial console output for a single success signal, namely the appearance of a stable user-space shell prompt that provides an unambiguous pass and fail boundary. When the prompt appears, the kernel has successfully mounted the root filesystem, executed the init sequence, and transitioned to user-space execution. when boot fails, the module captures the full console trace and extracts the failure signature (kernel panic, mount error, or init crash) into a structured diagnostic record that matches the failure categories in the agent’s knowledge base, enabling rapid, targeted repair without parsing raw logs. Agent-Driven Iterative Refinement. The Boot Repair Engineer Agent is built around two design choices. First, the agent is constrained to propose exactly one targeted modification per iteration. A single adjustment may be a QEMU parameter change or a filesystem patch, but never both simultaneously. Without this constraint, the agent tends to bundle multiple fixes into one response, making it impossible to attribute success or failure to a specific change. This constraint serves two purposes. First, it makes the effect of each action clearly attributable, keeping the search trajectory tractable. Second, it prevents over-correction that could destabilize a working configuration. Every iteration step is recorded as a discrete node with clear inputs and outputs, along with a success or failure label, making the entire refinement history auditable and reproducible. Second, the agent does not reason from scratch when a boot fails. The LLM often drifts into open-ended reasoning loops or proposes plausible but incorrect fixes based on general Linux knowledge rather than firmware-specific patterns. To ground the agent, we provide a knowledge base that maps failure signatures to their most probable root causes and corresponding repair actions. The agent uses this mapping to form an initial diagnostic hypothesis, then invokes dedicated verification tools to confirm the hypothesis before executing

D. Reflective Synthesis The Reflective Synthesis module translates the Structured System Context Object into a bootable, user-space-ready QEMU instance through a closed-loop refinement process. At the core of this module is a Boot Repair Engineer Agent. Static mapping of extracted architecture, memory, and kernel parameters cannot fully anticipate the precise combinations required by the target firmware. Mismatched CPU flags, insufficient memory, or incompatible kernel versions often surface only at runtime. Thus, the module does not rely on a single static configuration. Instead, it synthesizes an initial boot hypothesis and launches QEMU. If the boot fails, an LLM-guided agent assesses the outcome and iteratively adjusts the QEMU command line and root filesystem until a stable user-space prompt appears or the retry limit is reached. Filesystem Pre-processing. Prior to the first boot attempt, the module performs targeted, dependency-aware filesystem remediation guided by results of the A.P.I module. Drawing on practices established in prior work [11], [14], we preemptively resolve common structural and dependency faults to prevent excessive intervention during subsequent refinement: Inject missing or malformed system configuration files, such as /etc/passwd and /etc/group. • Deploy NVRAM virtualization libraries when proprietary hardware calls are detected, following Greenhouse [14]. • Reconstruct broken symbolic links. • Correct execute permissions on core binaries and dynamic linkers. • Package the hardware-decoupled startup scripts from the A.P.I module, along with service launch and network configuration scripts, into the filesystem at standard entry points.

•

By analyzing a set of hook-failure cases, we found that conventional environment-based hooking is often unreliable on stripped uClibc/musl firmware, where LD_PRELOAD support may be disabled and section metadata may be unavailable. To address this limitation, we complement these filesystem repairs with a dual-path library interposition strategy. When the target loader supports LD_PRELOAD, we use conventional environment-based injection. Otherwise, we inject a DT_NEEDED entry directly into the target binary through our

6

the planned adjustment. Only after tool-based confirmation does the agent apply the single modification. This diagnosethen-act workflow prevents wasteful replacement of functional components and limits the loop to a maximum of five iterations. The Agent handles two fault categories, distinguished by when they occur. Failures that surface before the kernel reaches user-space typically originate from virtual hardware misconfiguration, for example an Illegal instruction crash due to a mismatched CPU model or a kernel decompression panic from insufficient memory. For these, the agent performs QEMU Parameter Rectification. A concrete case is WAVLINK NU516U1, which triggers a kernel panic early in boot. The agent inspects the console log, cross-references the panic signature with the firmware’s architectural metadata supplied by the A.P.I module, and invokes its analysis tools to determine that the required -cpu parameter is missing. It then adjusts the QEMU command line to include -cpu 74Kf and reboots, after which the kernel panic disappears. Failures after kernel handoff, where processes fail to spawn or terminate unexpectedly, instead require Filesystem Remediation, which includes injecting missing shared libraries from a compatibility pool, resolving broken symbolic links, and correcting permission masks. All modifications are batched into a fresh disk image before the next boot attempt. Every intervention is appended to a structured, persistent repair history. Before proposing any new action, the agent explicitly checks this history to avoid repeating previously attempted fixes. This simple yet effective memoization mechanism prevents cyclic loops where the agent would otherwise oscillate between two conflicting adjustments. By coupling emulator configuration with rootfs integrity under LLMguided, evidence-driven reasoning, this reflection mechanism systematically eliminates boot-time blockers without manual intervention, ensuring that only fully initialized, user-spaceready instances are handed off to the subsequent Autonomous Runtime Intervention module.

faced with this overloaded context and broad tool set, tends to hallucinate diagnoses or apply overly broad fixes that disrupt previously working components. By partitioning responsibilities across a Manager Agent and domain-specific specialists, each agent operates within a focused context and a limited, relevant toolchain. This effectively mitigates context explosion and tool misuse. We adopt a multi-agent design in which a Manager Agent observes and routes faults, specialist agents repair within narrow domains, and the Manager coordinates sequential handoffs to resolve compound failures and progressively advance the rehosting metrics. Fault Observation and Routing. A Manager Agent sits at the center of the architecture, acting solely as an observer and router. This design strictly separates diagnosis from repair. In a single-agent setup, the LLM that diagnoses a fault also tries to fix it, often applying premature or incorrect repairs that corrupt the system. By keeping the Manager read-only, a misdiagnosis never damages the running instance, and specialists always receive a clean, consistent snapshot. The Manager continuously monitors the console output and process list for failure signatures such as repeated errors, persistent crash logs, or ports that remain unbound despite a launched service. When a fault is detected, the Manager classifies it by system layer and failure category. Failures matching known patterns with high confidence are routed directly to the appropriate specialist. For ambiguous or compound failures that cannot be confidently classified, the Manager delegates the task to a dedicated Diagnosis Agent. This agent performs deeper analysis to disambiguate the root cause. Once the fault is clearly identified, the Diagnosis Agent returns the result to the Manager, which then routes it to the correct specialist. Throughout this process, the Manager never executes repairs itself, so a misdiagnosis cannot compromise the system. Specialist Intervention Agents. We distribute remediation across specialist agents rather than a single general-purpose LLM. A monolithic agent, given all tools at once, often picks the wrong diagnostic path and misses domain-specific failure patterns. Scoping each specialist to one fault category with a focused toolchain keeps diagnoses grounded and repairs precise. The CrashExpert handles services that terminate early due to compulsory hardware presence checks. It first statically locates blocking code paths, then employs LLM-guided semantic understanding of the decompiled code to determine precisely where to insert breakpoints. Instead of applying binary patches [14] , we use breakpoint-chain intervention to bypass checks at runtime without modifying the binary. This eliminates the danger of an LLM agent introducing hard-to-detect damage into the firmware image. The FileExpert resolves runtime filesystem faults such as missing configuration files, broken symbolic links, or incorrect permissions. It correlates process access traces with the rootfs structure and consults binary metadata to infer expected file formats when surface-level errors are insufficient. The WebExpert bridges the gap from port availability to full HTTP interactivity. It follows an ordered diagnostic sequence that verifies web root permissions, validates CGI interpreter paths, and extracts

E. Autonomous Runtime Intervention Once the R.S module hands off a booted, user-spaceready QEMU instance, the Autonomous Runtime Intervention module takes over. It configures the virtual network interface and applies the minimal startup script produced by the A.P.I module, which launches only the service-critical daemons. After the script is applied, the module employs a multi-agent system to monitor the runtime state and advance the rehosting metrics in stages. Multi-Agent Design. Runtime failures at this stage, such as crashes, missing files, unbound ports, or misconfigured web services, rarely occur in isolation. Resolving one fault often exposes another, and the required diagnostics span multiple domains that a single LLM agent struggles to cover reliably. Moreover, firmware analysis involves extensive context, such as kernel logs, filesystem layouts, and binary disassembly, and a diverse set of tools spanning dynamic analysis, static analysis, and network validation. A monolithic agent, when

7

hard-coded compile-time paths from the httpd binary only when earlier checks pass. Failures that fall outside these three well-defined categories are escalated to the GenericExpert. Unlike the narrow specialists, the GenericExpert has unrestricted access to all tools and knowledge sources. This mirrors the monolithic agent discussed earlier, but with a critical difference. It is invoked only as a fallback when targeted repairs fail, not as the default for every fault. Its primary role is exploratory diagnosis for previously unseen or multi-domain failures. When no existing pattern matches, the GenericExpert investigates across layers, formulates a repair hypothesis. If successful, it will record the new pattern so that similar faults can be handled by the appropriate specialist without repeating costly exploration. Sequential Fault Handoff. This sequential handoff is essential for resolving compound failures. A single agent, when confronted with multiple overlapping faults, often attempts to fix them all at once and loses track of cause and effect. By contrast, our pipeline addresses one fault at a time and re-evaluates the system state after each repair, so that newly exposed failures are correctly attributed and routed. For example, the httpd daemon first crashes due to a hardware-probe check, which CrashExpert bypasses via GDB breakpoints. Once bypassed, the same daemon fails to start because a configuration file was never provisioned, which FileExpert resolves. Even after both fixes, the web service returns errors from mismatched compile-time paths, which WebExpert corrects. The Manager’s routing loop dispatches each emergent fault to the correct specialist and iterates until all symptoms are cleared. This design decomposes compound failures into a sequence of targeted, single-domain repairs validated at each step. Knowledge Reuse Across Firmware. Without reuse, the agent treats every fault as novel and invokes the full LLM diagnostic pipeline from scratch, which is both slow and costly. To avoid this, every validated repair trajectory records the fault signature, diagnostic steps, specialist invoked, and applied fix in a structured knowledge base indexed by failure category and architectural context. When the Manager Agent encounters a fault on a subsequent firmware image, it first queries this knowledge base for signatures that match within a similarity threshold. A successful match allows the corresponding specialist to apply the proven fix directly after a lightweight verification step, bypassing the full diagnostic pipeline. Unsuccessful matches still benefit from partial knowledge. The Manager can narrow the routing decision by comparing the new fault against previously catalogued patterns even when no exact match exists. Over a sequence of firmware images, this feedback loop accumulates a growing library of reusable solutions, progressively reducing the average intervention cost per firmware.

orchestration framework. We leverage CrewAI’s Flow module to coordinate the three-phase pipeline as an event-driven state machine. Multi-agent architecture. F IRM C URE organizes agents into phase-specific crews. A.P.I employs a single analyst agent that sequentially executes subtasks to extract firmware primitives. The R.S module employs an LLM-driven reflective synthesis process, in which the agent proposes QEMU configurations and filesystem repair, validates them against boot telemetry, and iteratively refines the configuration on failure. In Phase 3, we use a hierarchical arrangement. A manager agent first diagnoses the fault. It then hands the fault over to one of four specialist agents, namely CrashExpert, FileExpert, WebExpert, or GenericExpert. Each specialist is equipped with a carefully chosen set of allowed tools and a knowledge base tailored to its domain. Prompt and knowledge design. Each agent in F IRM C URE is guided by carefully crafted prompts that define its role, reasoning strategy, and expected output format, steering the LLM to accomplish domain-specific tasks reliably. Beyond per-agent prompt engineering, F IRM C URE decouples domain knowledge from agent logic via JSON-structured knowledge schemas. Each expert is associated with a knowledge file defining fault classification rules, repair workflows, and domain heuristics, which are injected at runtime through CrewAI’s StringKnowledgeSource. Task prompts enforce structured JSON output, enabling the flow controller to track each intervention action. Tool design. F IRM C URE provides seven specialized tools following a unified pattern in which a backend class encapsulates implementation logic and a CrewAI BaseTool wrapper exposes it to agents. The tools cover static analysis powered by radare2 [36], dynamic debugging via GDB remote protocol, disk image manipulation on ext4 through debugfs, QEMU lifecycle management, file system operations, network testing, and multi-tier validation. Tools are filtered per expert via an EXPERT_TOOL_MAP. Backend. F IRM C URE communicates with LLMs through the LiteLLM [37] gateway, which normalizes provider-specific APIs into a unified interface. It currently supports QEMU [13] emulation targeting ARM and MIPS variants. VI. E VALUATION To evaluate the effectiveness of F IRM C URE , we conducted a comprehensive set of experiments designed to address the following research questions: RQ1: How does F IRM C URE compare to existing stateof-the-art tools across key rehosting metrics? • RQ2: How effectively do F IRM C URE ’s specialized components generalize to diverse firmware rehosting obstacles across heterogeneous targets? • RQ3: How effectively does F IRM C URE enable highfidelity vulnerability reproduction and novel security analysis? •

V. I MPLEMENTATION Our prototype implementation of F IRM C URE comprises roughly 16,000 lines of code, primarily written in Python, and is built on top of CrewAI [35], an open-source multi-agent

8

•

RQ4: How do F IRM C URE ’s token consumption and execution latency vary across heterogeneous firmware samples?

This represents the highest fidelity level, strictly required for downstream vulnerability analysis such as web fuzzing or exploit reproduction. This multi-stage design captures whether firmware progresses from basic execution to full service interactivity, ensuring it reaches a state viable for security analysis. Since F IRM C URE operates as a full-system rehosting framework, it is evaluated across all four hierarchical stages to demonstrate end-to-end kernel-to-service readiness. In contrast, user-space baselines such as Greenhouse and Firmwell inherently bypass kernel initialization and virtual network stack provisioning. For these frameworks, we consolidate the initial boot and network phases into a unified Execute metric, which quantifies successful user-space service launch and runtime binding [12], [14]. We therefore evaluate each baseline strictly on the stages natively supported by its architectural paradigm, ensuring a fair and technically sound cross-paradigm comparison.

A. Evaluation Setup Dataset. To evaluate F IRM C URE under heterogeneous conditions, we use a deliberately diverse set of 21 representative samples drawn from 10 major vendors. These samples span five diverse architectures and cover multiple device types such as routers, cameras, and IoT devices. This heterogeneous composition ensures a robust test of F IRM C URE ’s adaptability while allowing detailed manual verification of rehosting fidelity. Baselines. We compare F IRM C URE against three state-ofthe-art frameworks representing distinct technical paradigms. FirmAE [11] stands as a leading approach in full-system rehosting by introducing arbitrated emulation, which applies targeted heuristic fixes at specific arbitration points during firmware boot to maximize the launch of user-space services rather than faithfully emulating all hardware. User-space approaches Greenhouse [14] and Firmwell [12] represent the state-of-the-art in user-mode rehosting and dependency-aware rehosting. Greenhouse pioneers dynamic API virtualization by mapping hardware dependencies to eight barrier types and applying ten predefined interception templates, while Firmwell advances rehosting by leveraging native firmware initialization routines to materialize runtime dependencies within a coordinated multi-process environment, augmented by dependency profiling and automated error inference. Environment. All experiments were conducted on a server cluster equipped with Intel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz and 320GB RAM. Each firmware sample was allotted a maximum execution time of 45 minutes. Rehosting Metrics. To evaluate rehosting fidelity for security research, we adopt a hierarchical metric progression centered primarily on web services. Web interfaces constitute the most critical attack surface in IoT firmware and are highly sensitive to runtime environment correctness. We measure progression through four sequential stages that reflect increasing levels of service readiness, aligned with Table II: 1) Kernel Boot (Ker.): The percentage of samples that successfully boot the kernel and mount the root filesystem. This indicates whether basic system initialization completes without kernel panics. 2) Network Connectivity (Net.): The percentage of samples where the emulated network stack is functional and the device obtains a valid IP address. This verifies that virtualized network interfaces are properly initialized for external reachability. 3) Service Port Availability (Port): The percentage of samples where the target web service successfully spawns and binds to its expected listening port. This confirms process readiness and accessibility for network scanning. 4) Service Interactivity (Inter.): The percentage of samples capable of processing stateful HTTP requests (e.g., authentication, configuration retrieval, CGI execution).

B. Firmware Rehosting Results We compare the rehosting performance of F IRM C URE against FirmAE, Greenhouse, and Firmwell across 21 heterogeneous firmware images. The evaluation tracks rehosting progression in stages, from kernel or user-space execution through network initialization and port binding to final service interactivity. We further analyze the technical reasons behind the successes and failures across all firmware samples. Overall Results. We evaluate F IRM C URE against FirmAE, Greenhouse, and Firmwell across 21 firmware samples spanning nine vendors. As shown in Table II, F IRM C URE reaches a 100% success rate at the Kernel, Network, and Port stages, and achieves a 90.5% end-to-end interaction rate—the only tool to systematically advance beyond early execution stages across all architectures. In contrast, FirmAE, Greenhouse, and Firmwell stall at substantially lower interaction rates (9.5%, 9.5%, and 19.0% respectively). The performance gap widens sharply at the Port stage. FirmAE exposes only 14.3% of targets at the port level, while Greenhouse and Firmwell reach 9.5% and 19.0%. F IRM C URE eliminates this bottleneck entirely, progressing all 21 samples to a listening port. This stark disparity stems from concrete technical obstacles that static heuristics cannot overcome. On WAVLINK NU516U1, all three baselines fail because the firmware requires a specific CPU model and memory layout that their fixed rehosting profiles do not satisfy. F IRM C URE detects the mismatch and adjusts the QEMU command accordingly. For DIR823X, an ARM64 firmware, FirmAE provides no ARM64 support, while Greenhouse and Firmwell, upon detecting ARM64, report an error and fail to identify the architecture. F IRM C URE correctly extracts the ISA and boots it successfully. TL-IPC43AN hangs on a /tmp/jffs2_ready wait loop, a file-system-level deadlock that no baseline resolves. Our analysis recognizes and removes the blocking condition. Tenda AC15 and AC18 contain a ConnectCfm hardwarepresence check in their service binaries that permanently stalls user-space initialization under FirmAE, Greenhouse, and Firmwell. F IRM C URE bypasses this check via breakpoint

9

TABLE II F IRMWARE R EHOSTING R ESULTS ACROSS F IRM AE, G REENHOUSE , F IRMWELL AND F IRM C URE No

Vendor

Device

FirmAE

Arch

Greenhouse

Firmwell

F IRM C URE Port

Inter.

Totolink

NR1800X N150RT

mipsel mipsel

✓ ✓

✓ ✓

✗ ✓

✗ ✓

✓ ✓

✓ ✗

✓ ✗

✓ ✓

✓ ✗

✓ ✗

✓ ✓

✓ ✓

✓ ✓

✓ ✓

3 4 5 6

D-link

DAP-1522 dsp-w215 DGL-5500 DIR823X

mipsel mipsel mipsel arm64

✓ ✓ ✗ ✗

✓ ✓ ✗ ✗

✓ ✓ ✗ ✗

✓ ✗ ✗ ✗

✓ ✓ ✓ ✗

✗ ✗ ✗ ✗

✗ ✗ ✗ ✗

✓ ✓ ✓ ✗

✗ ✗ ✗ ✗

✗ ✗ ✗ ✗

✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

7 8

WAVLINK

NU516U1 WN531P3

mipsel mipsel

✗ ✓

✗ ✓

✗ ✗

✗ ✗

✗ ✓

✗ ✗

✗ ✗

✗ ✓

✗ ✗

✗ ✗

✓ ✓

✓ ✓

✓ ✓

✓ ✓

9 10 11 12

Tenda

AC15 AC18 AC500 AX1806

armhf armhf armhf armhf

✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

✗ ✗ ✗ ✗

✗ ✗ ✗ ✗

✓ ✓ ✓ ✓

✗ ✗ ✗ ✗

✗ ✗ ✗ ✗

✓ ✓ ✓ ✓

✗ ✗ ✗ ✗

✗ ✗ ✗ ✗

✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

13

1 2

Ker.

Net.

Port

Inter.

Exe.

Port

Inter.

Exe.

Port

Inter.

Ker.

Net.

Draytek

Vigor3900

armel

✗

✗

✗

✗

✗

✗

✗

✗

✗

✗

✓

✓

✓

✓

14 15

Netgear

wn1000rp XR500

mipsel armhf

✓ ✓

✓ ✗

✗ ✗

✗ ✗

✓ ✓

✓ ✗

✓ ✗

✓ ✓

✓ ✗

✓ ✗

✓ ✓

✓ ✓

✓ ✓

✓ ✗

16 17

TRENDnet

TEW-711BR TEW-813DRU

mipseb mipseb

✓ ✓

✓ ✓

✗ ✗

✗ ✗

✓ ✗

✗ ✗

✗ ✗

✗ ✗

✗ ✗

✗ ✗

✓ ✓

✓ ✓

✓ ✓

✓ ✓

18 19

TP-LINK

TL-IPC43AN RE580D

armhf armel

✓ ✓

✓ ✓

✗ ✗

✗ ✗

✗ ✗

✗ ✗

✗ ✗

✗ ✗

✗ ✗

✗ ✗

✓ ✓

✓ ✓

✓ ✓

✓ ✓

FW WL500gPv2 2015

mipsel

✓

✓

✗

✗

✓

✗

✗

✓

✓

✓

✓

✓

✓

✓

AX9000

arm64

✗

✗

✗

✗

✗

✗

✗

✗

✗

✗

✓

✓

✓

✗

76.2%

71.4%

14.3%

9.5%

66.7%

9.5%

9.5%

61.9%

19.0%

19.0%

100.0%

100.0%

100.0%

90.5%

20

Asus

21

XIAOMI

Total

TABLE III C ASE S TUDY: D IVERSITY OF R EHOSTING O BSTACLES AND TARGETED I NTERVENTIONS ID

Device Model

Trigger / Cause

1

Tenda AC15

ConnectCfm failure

2

3

D-Link DGL-5500

WAVLINK NU516U1

5

Dlink DSP-W215

6

WAVLINK WN531P3

Targeted Action

(CrashExpert) A.R.I GDB breakpoint & alter register to bypass

libm.so.0 missing

R.S

Null symlink config

(FileExpert) A.R.I

IPv6 unsupported in VM

(FileExpert) A.R.I

File descriptor limit

(FileExpert) A.R.I

Search lib for injection & replace symlink Restore lighttpd.conf from lighttpd_base.conf sed disable server.use-ipv6 sed cap server.max-fds=512, max-connections=256

(FileExpert) A.R.I

Symlink /www to hardcoded path

(FileExpert) A.R.I

mkdir -p /var/run

Missing hardcoded TRENDnet TEW-711BR doc_root Missing PID directory

4

Repair Phase

Kernel panic Unextracted www.tgz

R.S

Adjust QEMU -cpu 74Kf parameter

(WebExpert) A.R.I

Extract to specified directory /www

—

—

chaining. On DAP-1522, FirmAE achieves interaction by intercepting system calls to generate the required rgdb configuration, a capability that Greenhouse and Firmwell lack. F IRM C URE reaches the same result through LLM-guided configuration synthesis. For TEW-813DRU, FirmAE opens the web port but fails to deliver interaction due to missing web-specific configuration files. F IRM C URE advances to full interaction by inferring and synthesizing the required files.

Direct Boot

request handling, rooted in deeply entangled dependencies across multiple proprietary daemons. The complexity of the failure pattern makes accurate root-cause identification infeasible within the bounded intervention cycles. For XR500, the obstacle centers on the ubusd daemon, which fails to start during user-space initialization. Without a functional ubus IPC bus, CGI scripts cannot communicate with backend services, leaving the web server stuck at port-open with no responsive content. Despite extended diagnostic effort, the agent could not resolve the ubus startup failure within the iteration budget, and this state persisted in follow-up experiments. These edge cases highlight a boundary condition where the most complex modern firmware demands longer diagnostic horizons or deeper architectural knowledge than the

The two remaining outliers, XIAOMI AX9000 and Netgear XR500, represent newer and more complex firmware on which F IRM C URE successfully advances to the Port stage through targeted intervention but cannot reach full interaction within the time budget. For AX9000, postexperiment analysis reveals a segmentation fault during HTTP

10

current time budget allows, pointing to a direction for future improvement.

unclassified failures in 2 cases. These results show that the specialist agents collectively cover process, filesystem, webservice, and general fault domains, and their sequential orchestration under the Manager Agent enables systematic resolution of compound failures. Taken together, these three levels form a progressive intervention spectrum. Level 1 handles cleanly separable hardware dependencies through semantic decoupling. Level 2 resolves boot-time blockers before Kernel Boot through Reflective Synthesis. Level 3 addresses diverse post-boot failures through coordinated specialist agents. Removing any single stage leaves its failure category unresolved, validating the staged architecture of F IRM C URE .

C. Intervention Strategies Across Diverse Obstacles To understand how F IRM C URE handles diverse rehosting obstacles, we conducted a detailed analysis of the boot processes across all 21 firmware samples and identified three distinct levels at which our pipeline resolves failures. Table III summarizes representative cases for each level. Level 1: Semantic Decoupling at the Perception Stage. The A.P.I module executes for every firmware image and produces a hardware-decoupled startup configuration that feeds into the subsequent runtime environment reconstruction. For a subset of firmware, this stage alone suffices to achieve functional rehosting without any subsequent intervention. In our evaluation, 6 out of the 21 samples boot directly to full service interactivity with no further repairs, as listed in Appendix VI. A representative case is WAVLINK WN531P3. Under FirmAE, the device deadlocks due to vendor-specific hardware daemons probing absent physical devices. Our perception stage strips these processes while preserving servicecritical daemons, allowing clean boot with zero downstream intervention. For these part of firmwares where hardware and software configurations are clearly separated during initialization, they can boot normally after the A.P.I stage. Level 2: Reflective Synthesis via Boot-Time Configuration and Filesystem Repair. A second class of failures surfaces during kernel bootstrap or filesystem mounting and must be resolved before user-space execution can begin. Only 3 of the 21 firmware samples require intervention at this stage, as listed in Appendix VI. Case 4 (WAVLINK NU516U1) triggers a kernel panic due to a mismatched CPU model, which the Reflective Synthesis stage fixes by adjusting the QEMU -cpu parameter. Case 2 (D-Link DGL-5500) has a missing shared library libm.so.0 that causes /bin/sh to fail, preventing the system from reaching user space. These cases confirm that failures at this stage, if left unresolved, permanently stall rehosting progress before Kernel Boot, making the Reflective Synthesis stage essential for advancing the pipeline. Level 3: Runtime Fault Resolution by Specialist Agents. Even after the first two stages have delivered a booted, user-space-ready instance, diverse runtime failures can still unexpectedly emerge. Of the 21 firmware samples, 12 require intervention at this stage, totaling 26 targeted repairs across four specialist agents, as detailed in Appendix VI. Among them, the CrashExpert handles 4 cases involving processlevel deadlocks, such as Case 1 (Tenda AC15), where the ConnectCfm hardware-presence check blocks the web service and is bypassed via GDB breakpoint chaining without modifying the binary. The FileExpert is the most frequently invoked, resolving 18 filesystem-level issues including null symlink configurations, IPv6 unavailability, file descriptor limits (Case 2, D-Link DGL-5500), and hardcoded path reconciliation (Case 3, TRENDnet TEW-711BR). The WebExpert addresses web-layer faults such as unextracted web roots (Case 5, Dlink DSP-W215), while the GenericExpert handles

D. Vulnerability Reproduction and Discovery To assess the practical security value of F IRM C URE , we evaluate its ability to reproduce known vulnerabilities and discover new ones in real-world firmware. Effective dynamic analysis requires a stable, interactive service runtime that survives initialization deadlocks and remains reachable over extended periods. F IRM C URE achieves this by autonomously stripping hardware-dependent boot logic and intervening at runtime to keep critical services alive. We apply the framework to a set of router firmware images and perform both targeted proof-of-concept validation and semi-automated fuzzing, resulting in the reproduction of ten existing CVEs and the discovery of five previously unknown vulnerabilities. Reproduced Vulnerabilities. Table IV lists 15 reproduced or discovered CVEs. Several of these target firmware images could not be rehosted by prior tools. Tenda AC15 and WAVLINK NU516U1, for instance, cannot be emulated by FirmAE, Greenhouse, or Firmwell due to hardware deadlocks and kernel panics. Only F IRM C URE restores them to an interactive state, enabling reproduction of seven CVEs. F IRM C URE also boots Totolink NR1800X, which FirmAE cannot support, to reproduce three more CVEs. TABLE IV R EAL - WORLD V ULNERABILITIES D ISCOVERED OR R EPRODUCED USING F IRM C URE . CVE-ID

Device

Type

F IRM C URE

CVE-2025-25634 CVE-2025-25632 CVE-2025-3992 CVE-2025-3993 CVE-2025-3994 CVE-2025-3995 CVE-2025-3996 CVE-2025-9149 CVE-2026-2615 CVE-2026-3704 CVE-2026-3612 CVE-2026-3613 CVE-2026-1326 CVE-2026-1327 CVE-2026-1328

Tenda AC15 Tenda AC15 Totolink N150RT Totolink N150RT Totolink N150RT Totolink N150RT Totolink N150RT WAVLINK NU516U1 WAVLINK NU516U1 WAVLINK NU516U1 WAVLINK NU516U1 WAVLINK NU516U1 Totolink NR1800X Totolink NR1800X Totolink NR1800X

Buffer Overflow Cmd Injection Buffer Overflow Buffer Overflow XSS XSS XSS Cmd Injection Cmd Injection Cmd Injection Cmd Injection Buffer Overflow Cmd Injection Cmd Injection Buffer Overflow

Reproduced Reproduced Discovered Discovered Discovered Discovered Discovered Reproduced Reproduced Reproduced Reproduced Reproduced Reproduced Reproduced Reproduced

CVE-2025-25634 is a stack-based buffer overflow in the Tenda AC15 web interface, triggered by an oversized

11

src parameter sent to the goform dispatcher. CVE-202525632 is a command injection in the same device via the /goform/telnet endpoint. CVE-2025-9149 is a command injection in WAVLINK NU516U1 through the sysinit endpoint. On Totolink NR1800X, CVE-2026-1326 and CVE2026-1327 are command injections in the setWanCfg and setTracerouteCfg handlers, while CVE-2026-1328 is a buffer overflow in setWizardCfg. In each case, F IRM C URE restored the vulnerable service to a listening state and maintained it long enough to deliver the payload and confirm the expected side effect. Discovered Vulnerabilities. F IRM C URE uncovered five new security flaws in Totolink N150RT firmware. CVE2XXX-3XX2 and CVE-2XXX-3XX3 are buffer overflows in the /boafrm/formWlwds and /boafrm/formWsc handlers. The submit-url parameter is copied via strcpy into a fixed-size buffer without any length checking, causing the Boa web server to crash. CVE-2XXX-3XX4, CVE2XXX-3XX5, and CVE-2XXX-3XX6 are stored cross-site scripting (XSS) vulnerabilities found in the IP Port Filtering, LAN Settings, and MAC Filtering configuration pages, where user-supplied strings are saved and later reflected without proper sanitization. These findings were enabled by F IRM C URE ’s ability to achieve stable rehosting of the target firmware, which subsequently allowed us to systematically explore attack surfaces and perform manual PoC testing to confirm each vulnerability. Overall, F IRM C URE reproduced all of the target CVEs and identified five previously unknown vulnerabilities. The results confirm that the system’s closed-loop rehosting pipeline does not merely boot firmware, but transforms it into a reliable platform for dynamic vulnerability discovery.

Dlink DGL5500 Tenda AC15 Tenda AX1806 Wavlink NU516U1 Wavlink WN531P3 TRENDnet TEW-711BR 0

500

1,000

1,500

Time Cost(s)

Adaptive Perception Inference Autonomous Runtime Intervention

Reflective Synthesis

Fig. 2. Time Cost of F IRM C URE across Different Firmware Samples (Using GLM-5.1).

such as TRENDnet TEW-711BR and D-Link DGL5500, and Tenda AC15, trigger heavy A.R.I usage (1.09M–1.9M input tokens) and reach total costs of $2.32–$3.74. Across the six samples, the average total cost is approximately $2.18 per firmware. This on-demand resource allocation means that simpler firmware incurs minimal LLM expense, while complex cases receive the additional token budget they require.

TABLE V T OKEN & M ONEY C OST OF F IRM C URE ACROSS F IRMWARE S AMPLES (U SING GLM-5.1). Firmware

A.P.I In

E. Efficiency and Resource Consumption Analysis We measured the token consumption and end-to-end time cost of F IRM C URE across six representative firmware samples. All experiments were conducted using the GLM-5.1 model. The monetary cost is calculated based on the API pricing of $1.4 per million input tokens and $0.26 per million output tokens. Table V reports per-sample token counts and total dollar cost, while Figure 2 shows the corresponding time distribution. Token Cost. Table V breaks down the token consumption across the three pipeline stages. The A.P.I module forms the stable baseline of every rehosting task. Its input tokens range from 557K to 1,084K and output tokens from 18K to 29K, reflecting the fixed cost of static analysis, architecture detection, and init-sequence reasoning that all firmware images undergo. The subsequent stages activate only on demand. For firmware that boots cleanly after perception, such as Wavlink WN531P3, both Reflective Synthesis and Autonomous Runtime Intervention consume zero tokens, resulting in the cost of $1.19. Samples that require kernel parameter tuning or filesystem repair, e.g., Wavlink NU516U1 and Tenda AX1806, incur moderate R.S costs (33K–77K input tokens) and total costs of $1.18–$1.57. Firmware with complex runtime failures,

R.S Out

In

A.R.I Out

In

$ Cost Out

TRENDnet TEW-711BR 726,415 22,469 0 0 1,928,593 78,869 843,264 23,716 0 0 0 0 Wavlink WN531P3 Wavlink NU516U1 759,997 29,219 77,322 3,335 0 0 1,084,402 25,883 33,917 1,193 0 0 Tenda AX1806 Tenda AC15 557,254 18,722 0 0 1,087,882 59,164 Dlink DGL5500 718,024 18,641 69,049 1,604 1,418,802 40,580

$3.74 $1.19 $1.18 $1.57 $2.32 $3.10

Union (Avg.)

$2.18

781,559 23,108 30,048 1,022

739,213 29,769

Time Cost. Figure 2 visualizes the end-to-end latency decomposed by stage. The A.P.I stage dominates the time profile, varying from roughly 520 to 850 seconds depending on firmware size and binary complexity. When no token-consuming intervention is needed, the R.S module still executes a lightweight inspection, resulting in baseline runtimes (21–88 s). When it actively repairs the environment, the time rises to 156–370 s. When A.R.I specialists are activated, they contribute 467–720 seconds. The total time ranges from about 13 minutes for Wavlink WN531P3 to 27 minutes for D-Link DGL5500. Since the R.S and A.R.I modules are conditional, the average time cost stays moderate, and no firmware exceeded 30 minutes in our experiments. This latency is acceptable for automated firmware security testing, especially considering that manual debugging of the same failures often takes several hours per firmware. The predictable baseline of the A.P.I stage and the bounded nature of the refinement loops together ensure that F IRM C URE operates within a practical time budget for large-scale firmware analysis.

12

VII. R ELATED W ORK

through plausible but ineffective fixes without converging on a valid solution. For highly complex, heavily customized firmware, or targets that fall outside the model’s knowledge scope, the system cannot resolve the underlying dependencies and rehosting will ultimately fail. This can be mitigated by equipping the agent with a curated knowledge base of firmware-specific solutions to ground its reasoning and reduce unproductive exploration. Firmware Unpacking. While not our core contribution, robust unpacking is essential for handling complex formats like UBI/UBIFS. We integrated an iterative unpacking module that combines specialized tools ubireader and ubidump with recursive binwalk extraction. This automatically resolves nested structures to isolate the rootfs, ensuring valid input for the rehosting engine without manual intervention. Scalability. The framework aligns emulated kernel versions with original firmware build signatures to construct tailored rehosting environments. We maintain compiled Linux kernels spanning major versions 2 through 5 across mipsel, mipseb, armel, and armhf architectures, alongside the latest kernel for arm64. The build pipeline supports compiling additional kernel versions per architecture, and architecture-specific layers remain decoupled from the core engine, enabling straightforward extension to new instruction sets. Our evaluation focuses on home routers, IP cameras, and Linux-based IoT firmware. The architecture-agnostic rehosting engine and modular peripheral abstraction enable straightforward adaptation to other device categories, including smart home hubs, industrial control systems, and automotive infotainment units. It integrates directly into vendor CI/CD pipelines, bug discovery platforms, and regulatory testing workflows.

Embedded device firmware can be classified into three types: Type-I with general-purpose OS such as Linux, TypeII with Real-time Operating System (RTOS) such as VxWorks [38] and ZephyrOS [39], and Type-III bare-metal firmware, which has no OS [40]. Linux-based firmware accounts for roughly 50% of public images and is our focus. Foundational emulators such as QEMU [13], Unicorn [41], and Ghidra Emulator [42] provide cross-ISA execution but lack the peripheral models necessary for full-system rehosting. To overcome this, researchers have pursued two broad strategies, including hardware-dependency layer replacement and peripheral modeling. Hardware-dependency layer replacement intercepts and substitutes hardware-specific calls. Firmadyne [10] introduced a custom kernel with NVRAM emulation for Linux firmware, and FirmAE [11] improved boot rates through arbitrated emulation. HALucinator [43] replaces HAL calls for RTOSbased firmware. These methods work well when hardware interfaces are clearly library-based but fail on direct registerlevel interactions. Peripheral modeling builds software approximations of hardware behaviour. Hardware-in-the-loop methods forward peripheral accesses to real devices [44]–[47]. Symbolic execution approaches treat peripheral values as symbolic to infer constraints from firmware paths [48]–[52]. Specificationdriven techniques extract rules from datasheets using NLP [53]. Fuzzing-based methods mutate MMIO without explicit models [54], [55], while behavioral-equivalence models abstract peripherals into generic categories [56], [57]. More recently, FlexEmu [21] leverages LLMs to synthesize peripheral models from driver code, demonstrating the potential of LLMs to reduce manual effort. Our framework targets Linux-based firmware and complements, rather than replaces, existing rehosting methods such as Firmadyne [10], FirmAE [11], Greenhouse [14], and Firmwell [12]. It extends the rehosting ecosystem by addressing complex scenarios where static heuristics prove insufficient.

IX. C ONCLUSION We identified three fundamental gaps in existing rehosting. First, full initialization remains unattainable owing to unemulated custom hardware. Second, existing methods depend heavily on manual intervention and non-scalable, handcrafted rules. Third, LLM-driven techniques are restricted to static analysis and lack dynamic runtime feedback. To address these limitations, we proposed F IRM C URE , the first LLM-driven full-system rehosting framework for autonomous and adaptive rehosting of Linux-based firmware. F IRM C URE autonomously extracts true execution dependencies, iteratively stabilizes kernel boot and filesystem mounting, and employs the multi-agent system to diagnose and repair diverse runtime failures. Evaluated on 21 firmware images from 10 vendors, F IRM C URE achieves 100% port activation and 90.5% service interactivity, surpassing existing baselines. It reproduces 10 known CVEs and discovers 5 previously unknown vulnerabilities, demonstrating strong practical impact on IoT firmware security analysis. Our work shows that LLM-based agents open a new direction for adaptive, autonomous dynamic analysis of embedded systems.

VIII. D ISCUSSION Limitations. Our framework automatically selects an approximately matching kernel to replace the original, enabling scalable rehosting. While this preserves core software execution, it cannot analyze vulnerabilities that strictly depend on the original kernel or dedicated hardware such as hardware supported cryptographic functions. This can be addressed by incorporating peripheral emulation techniques to replicate the behavior of dedicated hardware components. The system also relies on an LLM for automation, which introduces practical constraints. LLMs can hallucinate or fall into repetitive reasoning loops, especially with complex or unfamiliar firmware logic. In our experiments, two firmware images, XIAOMI AX9000 and Netgear XR500, could not reach full service interactivity within the 45-minutes time limit. Post-experiment analysis showed that the agent spent most of the time cycling

13

R EFERENCES

[22] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “React: Synergizing reasoning and acting in language models,” arXiv preprint arXiv:2210.03629, 2022. [23] N. Shinn, F. Cassano, A. Gopinath, K. Narasimhan, and S. Yao, “Reflexion: Language agents with verbal reinforcement learning,” Advances in neural information processing systems, vol. 36, pp. 8634–8652, 2023. [24] J. Wei, X. Wang, D. Schuurmans, M. Bosma, F. Xia, E. Chi, Q. V. Le, D. Zhou et al., “Chain-of-thought prompting elicits reasoning in large language models,” Advances in neural information processing systems, vol. 35, pp. 24 824–24 837, 2022. [25] X. Hou, Y. Zhao, Y. Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, and H. Wang, “Large language models for software engineering: A systematic literature review,” ACM Transactions on Software Engineering and Methodology, vol. 33, no. 8, pp. 1–79, 2024. [26] Z. Luo, C. Xu, P. Zhao, Q. Sun, X. Geng, W. Hu, C. Tao, J. Ma, Q. Lin, and D. Jiang, “Wizardcoder: Empowering code large language models with evol-instruct,” arXiv preprint arXiv:2306.08568, 2023. [27] B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y. Adi, J. Liu, R. Sauvestre, T. Remez et al., “Code llama: Open foundation models for code,” arXiv preprint arXiv:2308.12950, 2023. [28] Z. Shen, “Llm with tools: A survey,” arXiv preprint arXiv:2409.18807, 2024. [29] Y. Qin, S. Hu, Y. Lin, W. Chen, N. Ding, G. Cui, Z. Zeng, X. Zhou, Y. Huang, C. Xiao et al., “Tool learning with foundation models,” ACM Computing Surveys, vol. 57, no. 4, pp. 1–40, 2024. [30] X. Hou, Y. Zhao, S. Wang, and H. Wang, “Model context protocol (mcp): Landscape, security threats, and future research directions,” ACM Transactions on Software Engineering and Methodology, 2025. [31] P. Lewis, E. Perez, A. Piktus, F. Petroni, V. Karpukhin, N. Goyal, H. Küttler, M. Lewis, W.-t. Yih, T. Rocktäschel et al., “Retrievalaugmented generation for knowledge-intensive nlp tasks,” Advances in neural information processing systems, vol. 33, pp. 9459–9474, 2020. [32] H. Jin, L. Huang, H. Cai, J. Yan, B. Li, and H. Chen, “From llms to llmbased agents for software engineering: A survey of current, challenges and future,” arXiv preprint arXiv:2408.02479, 2024. [33] L. Wang, C. Ma, X. Feng, Z. Zhang, H. Yang, J. Zhang, Z. Chen, J. Tang, X. Chen, Y. Lin et al., “A survey on large language model based autonomous agents,” Frontiers of Computer Science, vol. 18, no. 6, p. 186345, 2024. [34] H. Xiao, Z. Wei, J. Dai, B. Li, Y. Zhang, and M. Yang, “Housefuzz: Service-aware grey-box fuzzing for vulnerability detection in linuxbased firmware,” in 2025 IEEE Symposium on Security and Privacy (SP). IEEE, 2025, pp. 3801–3819. [35] CrewAI Team, “Crewai: The leading multi-agent platform,” https:// crewai.com/, 2025. [36] Radare Project, “Radare2: Unix-like reverse engineering framework and commandline toolset,” https://www.radare.org/, 2026. [37] BerriAI, “Litellm documentation,” https://docs.litellm.ai/, 2024. [38] Wind River, “VxWorks,” https://www.windriver.com/products/vxworks, commercial real-time operating system developed by Wind River. [39] Zephyr Project, “About the Zephyr Project,” https://www.zephyrproject. org/, open-source real-time operating system hosted by the Linux Foundation. [40] M. Muench, J. Stijohann, F. Kargl, A. Francillon, and D. Balzarotti, “What you corrupt is not what you crash: Challenges in fuzzing embedded devices.” in NDSS, 2018. [41] N. A. Quynh and D. H. Vu, “Unicorn: Next generation cpu emulator framework,” BlackHat USA, vol. 476, 2015. [42] National Security Agency, “Ghidra: Software reverse engineering framework,” https://github.com/NationalSecurityAgency/ghidra, 2019. [43] 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,” in 29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 1201– 1218. [44] J. Zaddach, L. Bruno, A. Francillon, D. Balzarotti et al., “Avatar: A framework to support dynamic security analysis of embedded systems’ firmwares.” in NDSS, vol. 14, no. 2014, 2014, pp. 1–16. [45] M. Muench, D. Nisi, A. Francillon, and D. Balzarotti, “Avatar 2: A multi-target orchestration platform,” in Proc. Workshop Binary Anal. Res.(Colocated NDSS Symp.), vol. 18, 2018, pp. 1–11. [46] M. Kammerstetter, C. Platzer, and W. Kastner, “Prospect: peripheral proxying supported embedded code testing,” in Proceedings of the

[1] IoT Analytics, “Connected iot device market update – fall 2025 and 2026 – 2035,” https://iot-analytics.com/number-connected-iot-devices/, 2025. [2] CommandLinux, “Linux in iot devices statistics,” https://commandlinux. com/statistics/linux-in-iot-devices-statistics/, 2024. [3] X. Zhou, P. Wang, L. Zhou, P. Xun, and K. Lu, “A survey of the security analysis of embedded devices,” Sensors, vol. 23, no. 22, p. 9221, 2023. [4] Q. Yin, X. Zhou, and H. Zhang, “Firmhunter: State-aware and introspection-driven grey-box fuzzing towards iot firmware,” Applied Sciences, vol. 11, no. 19, p. 9094, 2021. [5] Y. Zheng, A. Davanian, H. Yin, C. Song, H. Zhu, and L. Sun, “{FIRM-AFL}:{High-Throughput} greybox fuzzing of {IoT} firmware via augmented process emulation,” in 28th USENIX Security Symposium (USENIX Security 19), 2019, pp. 1099–1114. [6] P. Srivastava, H. Peng, J. Li, H. Okhravi, H. Shrobe, and M. Payer, “Firmfuzz: Automated iot firmware introspection and analysis,” in Proceedings of the 2nd International ACM Workshop on Security and Privacy for the Internet-of-Things, 2019, pp. 15–21. [7] I. Angelakopoulos, G. Stringhini, and M. Egele, “Pandawan: quantifying progress in linux-based firmware rehosting,” in 33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 5859–5876. [8] ——, “{FirmSolo}: Enabling dynamic analysis of binary linux-based {IoT} kernel modules,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 5021–5038. [9] ——, “Firmdiff: Improving the configuration of linux kernels geared towards firmware re-hosting.” Workshop on Binary Analysis Research (BAR’24), 2024. [10] D. D. Chen, M. Woo, D. Brumley, and M. Egele, “Towards automated dynamic analysis for linux-based embedded firmware.” in NDSS, vol. 1, 2016, pp. 1–1. [11] M. Kim, D. Kim, E. Kim, S. Kim, Y. Jang, and Y. Kim, “Firmae: Towards large-scale emulation of iot firmware for dynamic analysis,” in Proceedings of the 36th Annual Computer Security Applications Conference, 2020, pp. 733–745. [12] C. Qin, C. Zhang, Y. Zheng, P. Liu, J. Zhang, Y. Li, W. Zhang, Y. Liu, and L. Sun, “User-space dependency-aware rehosting for linux-based firmware binaries,” in Network and Distributed System Security (NDSS) Symposium 2026, 2026, pp. 23–27 February 2026, San Diego, CA, USA. [Online]. Available: www.ndss-symposium.org [13] F. Bellard, “Qemu, a fast and portable dynamic translator.” in USENIX annual technical conference, FREENIX Track, vol. 41, no. 46. California, USA, 2005, pp. 10–55. [14] H. J. Tay, K. Zeng, J. M. Vadayath, A. S. Raj, A. Dutcher, T. Reddy, W. Gibbs, Z. L. Basque, F. Dong, Z. Smith, A. Doup’e, Y. Shoshitaishvili, and R. Wang, “Greenhouse: Single-service rehosting of linuxbased firmware binaries in user-space emulation,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 5791–5808. [15] A. Radford, K. Narasimhan, T. Salimans, I. Sutskever et al., “Improving language understanding by generative pre-training,” 2018. [16] A. Radford, J. Wu, R. Child, D. Luan, D. Amodei, I. Sutskever et al., “Language models are unsupervised multitask learners,” OpenAI blog, vol. 1, no. 8, p. 9, 2019. [17] T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell et al., “Language models are few-shot learners,” Advances in neural information processing systems, vol. 33, pp. 1877–1901, 2020. [18] X. Shang, Z. Fu, S. Cheng, G. Chen, G. Li, L. Hu, W. Zhang, and N. Yu, “An empirical study on the effectiveness of large language models for binary code understanding,” Empirical Software Engineering, vol. 31, no. 1, pp. 1–38, 2026. [19] J. Ye, X. Fei, X. d. C. de Carnavalet, L. Zhao, L. Wu, and M. Zhang, “Detecting command injection vulnerabilities in linux-based embedded firmware with llm-based taint analysis of library functions,” Computers & Security, vol. 144, p. 103971, 2024. [20] S. Pordanesh and B. Tan, “Exploring the efficacy of large language models (gpt-4) in binary reverse engineering,” arXiv preprint arXiv:2406.06637, 2024. [21] C. Lei, Z. Ling, X. Xu, S. Li, G. Liu, K. Dong, and J. Luo, “Flexemu: Towards flexible mcu peripheral emulation,” in Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, 2025, pp. 2609–2623.

14

All 21 firmware images are publicly available from their respective vendor websites. Together with the source code and pre-built resources provided in our repository, reviewers can fully reproduce the rehosting pipeline and verify the reported results on each firmware.

9th ACM symposium on Information, computer and communications security, 2014, pp. 329–340. [47] 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 rehosting,” in 22nd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2019), 2019, pp. 135–150. [48] C. Cao, L. Guan, J. Ming, and P. Liu, “Device-agnostic firmware execution is possible: A concolic execution approach for peripheral emulation,” in Proceedings of the 36th Annual Computer Security Applications Conference, 2020, pp. 746–759. [49] W. Zhou, L. Guan, P. Liu, and Y. Zhang, “Automatic firmware emulation through invalidity-guided knowledge inference,” in 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 2007–2024. [50] E. Johnson, M. Bland, Y. Zhu, J. Mason, S. Checkoway, S. Savage, and K. Levchenko, “Jetset: Targeted firmware rehosting for embedded systems,” in 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 321–338. [51] C. Lei, Z. Ling, Y. Zhang, Y. Yang, J. Luo, and X. Fu, “A friend’s eye is a good mirror: Synthesizing {MCU} peripheral models from peripheral drivers,” in 33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 7085–7102. [52] Y. Wei, Y. Wang, L. Zhou, X. Zhou, and Z. Jiang, “Iemu: Interrupt modeling from the logic hidden in the firmware,” Journal of Systems Architecture, vol. 154, p. 103237, 2024. [53] 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,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 3269–3283. [54] 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,” in 31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 1239–1256. [55] G. Farrelly, M. Chesser, and D. C. Ranasinghe, “Ember-io: Effective firmware fuzzing with model-free memory mapped io,” in Proceedings of the 2023 ACM Asia Conference on Computer and Communications Security, 2023, pp. 401–414. [56] B. Feng, A. Mera, and L. Lu, “{P2IM}: Scalable and hardwareindependent firmware testing via automatic peripheral interface modeling,” in 29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 1237–1254. [57] A. Mera, B. Feng, L. Lu, and E. Kirda, “Dice: Automatic emulation of dma input channels for dynamic firmware analysis,” in 2021 IEEE Symposium on Security and Privacy (SP). IEEE, 2021, pp. 1938–1954.

B. Ethical Considerations F IRM C URE enables automated rehosting and dynamic analysis of IoT firmware in a controlled QEMU sandbox, eliminating the need for physical devices and lowering the barrier for security assessment. This helps vendors identify and patch flaws before exploitation. All evaluated firmware images are publicly available; we introduce no new attack vectors and follow responsible disclosure, as the security benefits of improved firmware analysis clearly outweigh the potential risks. C. F IRM C URE Agent Role We list the role definitions of all agents across the three stages below. Each role specifies the agent’s domain expertise, operational goal, and key behavioral constraints. For clarity, we present condensed versions of the actual prompts, which were designed to strictly encode these constraints and procedural steps, allowing readers to see exactly how each agent is guided during diagnosis and repair. 1) Adaptive Perception — Firmware Analyst: Prompt Template Role: Embedded Firmware Reverse Engineering Analyst. Goal: Perform deep analysis of firmware rootfs to accurately identify CPU architecture, httpd web server type and configuration, startup script sequences, shared library dependencies, and NVRAM dependencies, producing a structured JSON analysis report. Backstory: You are a senior embedded firmware reverse engineer specializing in IoT device firmware analysis. You are proficient in MIPS and ARM embedded CPU architectures, familiar with embedded web servers such as BusyBox, GoAhead, Boa, and lighttpd. You can rapidly extract critical firmware information through filesystem structure analysis, ELF binary analysis, and radare2 reverse engineering, providing precise parameters for QEMU emulation environment construction. You consult the expert knowledge base for analysis, paying special attention to: selecting the configuration file whose web root matches the extraction directory when multiple configs exist; detecting runtime content generation patterns; detecting NVRAM/apmib dependencies; ensuring the startup script includes only service-critical daemons.

A PPENDIX A. Open Science To support reproducibility, we make the following artifacts publicly available in our anonymous repository: • Source Code. The complete implementation of F IRM C URE , including all three pipeline stages (firmware analysis, QEMU emulation environment construction, and multi-agent runtime intervention), the CrewAI-based agent orchestration framework (flow.py), agent definitions, task prompts, and the 42 specialized tools across Radare2, GDB, system operations, and network validation. • Expert Knowledge Base. All domain-specific knowledge files that guide each expert agent, covering firmware analysis patterns, QEMU boot failure diagnostics, GDB breakpoint chaining strategies, and historical intervention case libraries. • Dataset. A curated dataset of 21 real-world IoT firmware images spanning multiple vendors (Tenda, D-Link, TPLink, Netgear, ASUS) and architectures (ARM, MIPS, MIPSEL).

15

2) Reflective Synthesis — Boot Repair Engineer: Prompt Template

success; only accept success=true when accompanied by a passing three-layer validation result.

Role: QEMU Emulation Environment Diagnostic and Repair Engineer. Goal: Analyze QEMU boot failure logs, check rootfs filesystem integrity, identify root cause of boot failure, and immediately execute repairs (supplement missing libraries, fix symbolic links, adjust QEMU parameters) to enable the firmware to boot successfully in the QEMU virtual machine. Backstory: You are a QEMU virtualization and embedded Linux systems expert. You excel at diagnosing QEMU boot faults across MIPS/ARM architectures, including kernel panic, shared library missing, dangling symbolic links, and missing init programs. Working Principles: (1) Execute first, summarize later — upon discovering a problem, immediately invoke tools to repair it; do not wait for complete analysis. (2) Fix only one key issue per iteration; return results after each fix for re-testing. (3) Do not repeatedly analyze the same problem — once the root cause is confirmed, fix it directly. Common faults include: kernel panic with VFS rootfs mount failure , CPU ISA mismatch , missing shared libraries, missing /bin/sh (ensure busybox exists and symlink is correct).

4) Autonomous Runtime Intervention — Crash Expert: Prompt Template Role: Binary Crash Analysis and Repair Expert. Goal: Analyze httpd program crash causes through GDB remote debugging and radare2 reverse engineering, and apply fixes using the breakpoint chain accumulation strategy. Backstory: You are an embedded binary reverse engineering and debugging expert. You are proficient in MIPS/ARM assembly and skilled in GDB remote debugging and radare2 static analysis. Your core capability is the breakpoint chain accumulation strategy: (1) Discover the first crash point, set a breakpoint to bypass it. (2) The program continues and hits a second crash point — accumulate all breakpoints (old + new) and bypass again. (3) Repeat until all crash points are bypassed. Key principles: set breakpoints at comparison/conditional branch instructions, not at call instructions; always pass the complete breakpoint chain including all historical breakpoints; register modifications must include values for all breakpoints. You handle two fault types: premature exit (httpd crashes with SIGSEGV/SIGABRT) and dependency wait (httpd stuck in a blocking loop with process running but port not open).

3) Autonomous Runtime Intervention — Manager: Prompt Template

5) Autonomous Runtime Intervention — File Expert: Prompt Template

Role: Firmware Runtime Intervention Commander. Goal: Analyze httpd service fault symptoms, accurately diagnose fault type, delegate repair tasks to the most appropriate specialist agent, and review repair results. If repair is incomplete or new issues are discovered, re-delegate to other specialists. Backstory: You are the commander of the firmware runtime intervention team. You excel at rapidly analyzing logs and status information, accurately classifying fault types, and delegating repair tasks to specialists with the corresponding expertise. You manage a team of five specialists: crash expert handles program crashes (premature exit) and wait loops (dependency wait), skilled in GDB debugging and radare2 reverse analysis; file expert handles file missing, permission errors, and symlink corruption; web expert handles HTTP 500/404 and CGI errors; generic expert handles unclassifiable complex problems with full tool access. Execution Style: Require specialists to perform brief analysis before immediately implementing the first minimal repair action. Do not allow prolonged pure reasoning without actual fixes. Each specialist must call validate_network_stack() before reporting

Role: Firmware Filesystem Repair Expert. Goal: Repair filesystem issues in the QEMU virtual machine: missing files, permission errors, symbolic link corruption, and device node absence. Backstory: You are an embedded Linux filesystem expert. You are familiar with the filesystem structure of embedded devices and know which files and directories are necessary for httpd service to function properly. Your core principle: always collect context before creating files — never generate content by guesswork. When a configuration file is missing because the dynamic generation system is unavailable in the emulation environment, you create static replacements based on actual filesystem evidence. You consult the knowledge base for filesystem repair workflows, standard device node lists, and httpd configuration file formats specific to common firmware vendors.

16

6) Autonomous Runtime Intervention — Web Expert: Prompt Template

1) Adaptive Perception — Firmware Analyst: Prompt Template

Role: httpd Web Service Content Repair Expert. Goal: Repair web-layer issues of the httpd service: HTTP 500/404 errors, CGI script failures, configuration file problems, and web content mapping errors. The httpd process is already running; focus on the web content layer, not binary crashes or network infrastructure. Backstory: You are an embedded web server configuration expert. You are familiar with the configuration and runtime mechanisms of embedded web servers such as GoAhead, Boa, and lighttpd. Your default analysis order must be: (1) first check whether the web directory, pages, and resources exist and are complete; (2) then check configuration files and path mappings; (3) only when both previous steps reveal no obvious issues, escalate to binary analysis. If the httpd process is running and the port is open, startup logs are only supplementary clues, not your primary analysis target. A 302 redirect to main.html should be treated as success.

Input: Extracted firmware root filesystem directory. Objective: Extract emulation primitives and classify hardware dependencies for QEMU execution. Analysis Steps: 1) Architecture & Service Profiling: Parse ELF headers (elf_info) to identify CPU architecture, endianness, and libc type. Locate the httpd binary and extract web root, port, and CGI paths via radare2 static string analysis. 2) Init Sequence Reconstruction: Parse /etc/inittab, rcS, and rc.init to build the boot execution graph. For each daemon, use binary string analysis to classify it as hardware-dependent (WiFi, GPIO, PHY, watchdog) or service-critical (logging, message bus, timer). 3) Dependency & NVRAM Analysis: Extract shared library dependencies (readelf_deps) and imported symbols (list_imports). Detect NVRAM/apmib API dependencies that require runtime emulation injection. 4) Configuration Synthesis: Generate a minimal startup script preserving only service-critical daemons. Extract QEMU parameters including kernel arguments, console device, memory, and root filesystem type. Output: Structured JSON containing architecture metadata, httpd configuration, daemon classification, validated startup script, dependency map, NVRAM requirements, and QEMU execution parameters.

7) Autonomous Runtime Intervention — Generic Expert: Prompt Template Role: Firmware Runtime General-Purpose Repair Expert. Goal: Handle failures that cannot be classified into a specific category, comprehensively applying all available tools and expert knowledge bases to diagnose and repair. Backstory: You are a versatile firmware debugging expert. When other specialists cannot handle a problem, you take over. You have access to all tools and all expert knowledge bases (crash analysis, file repair, network configuration, web debugging, fault diagnosis). Your knowledge includes: GDB remote debugging and breakpoint chain workflows; reverse engineering string localization and cross-reference analysis; filesystem repair including configuration synthesis and symlink restoration; network interface and DNS configuration; HTTP error cause analysis and CGI debugging. You approach problems from multiple angles simultaneously — process state, filesystem integrity, network connectivity, and web behavior — selecting the most appropriate strategy based on the diagnosed fault type.

2) Reflective Synthesis — Boot Repair Engineer: Prompt Template Input: QEMU boot log, rootfs directory path, current QEMU command, architecture. Objective: Diagnose QEMU boot failure, apply minimal repair, and produce corrected QEMU parameters. Analysis Steps: 1) Priority Diagnosis: Scan boot log for kernel panic, VFS mount failure, CPU ISA mismatch, or missing /bin/sh. Address the first critical error only. 2) Root Cause Localization: Map error signature to repair action. 3) Repair Execution: Apply a single targeted fix to the rootfs or QEMU parameters. Do not batch multiple repairs in one iteration. 4) Parameter Adjustment: Output corrected QEMU command-line parameters (CPU model, memory, root device, kernel version, DTB) if boot configuration changes are needed.

D. Task Prompts We list the simplified task prompts for all agents below. Each prompt specifies the input, objective, analysis steps, and expected output for the corresponding agent. These condensed prompts are designed to explicitly encode the agent’s behavioral constraints and procedural steps, illustrating how each agent is guided step-by-step during diagnosis and repair.

17

Output: JSON with diagnosis string, applied repairs list, optional QEMU parameter adjustments, and kernel version switch directive.

3) Breakpoint Chain Construction: Record the branch instruction address as breakpoint. Set register to bypass the check (e.g., $v0=1 for success). Accumulate all historical breakpoints to form a complete chain. 4) GDB Execution: Call gdb_run_script with the full breakpoint chain and register modifications. The tool automatically: kills stale processes → sets breakpoints → launches httpd → modifies registers at each hit → checks process survival. 5) Validation: Call validate_network_stack() for threelayer verification (ICMP + port scan + HTTP). Output: JSON with success status, complete breakpoint chain, register modifications, actions taken, and three-layer network validation result.

3) Autonomous Runtime Intervention — Manager: Prompt Template Input: Service status JSON, httpd startup logs, breakpoint chain history, Adaptive Perception analysis context. Objective: Diagnose runtime failure type and delegate to the optimal specialist agent. Analysis Steps: 1) Log-Tail Priority Analysis: Prioritize errors in the last lines of the log, as they are closest to the actual failure point. 2) Fault Classification: Classify the failure into one of: PREMATURE_EXIT (crash), DEPENDENCY_WAIT (blocked), FILE_MISSING, NETWORK_ERROR, WEB_ERROR, or UNKNOWN. 3) Expert Routing: Delegate to the appropriate specialist — crash expert for binary-level failures, file expert for missing resources, network expert for connectivity issues, web expert for HTTP errors, or generic expert for unclassifiable problems. 4) Result Arbitration: Validate specialist output against actual three-layer network verification (ping + port scan + HTTP request). Reject claims of success without passing validation. Output: Final intervention report with fault type, specialist used, actions taken, breakpoint chain, and validated network stack status.

5) Autonomous Runtime Intervention — File Expert: Prompt Template Input: Fault info (file missing / permission denied / symlink corruption), rootfs path. Objective: Restore missing or corrupted filesystem resources required by the httpd service. Analysis Steps: 1) Resource Localization: Use find_files and read_file to locate missing files, broken symlinks, or incorrect permissions in the rootfs. 2) Context Gathering: Before creating any file, collect context from existing similar files, configuration templates, or binary string references — never generate content by guesswork. 3) Repair Execution: Create missing device nodes (mknod), fix file permissions (chmod), restore symbolic links, copy missing libraries from lib_base, or generate static configuration files from templates. 4) Service Restart & Validation: Launch httpd via start_httpd tool and validate with validate_network_stack(). Output: JSON with success status, list of modified/created files, actions taken, and three-layer network validation result.

4) Autonomous Runtime Intervention — Crash Expert: Prompt Template Input: Fault info (crash signal or hang detection), httpd binary path, architecture, breakpoint chain history. Objective: Identify crash root cause via static reverse engineering and bypass failure checks via GDB breakpoint chain. Analysis Steps: 1) Error String Extraction: Extract the last meaningful error/output string from the crash log. This string is adjacent to the failure point. 2) Static Reverse Engineering (radare2): Open binary → analyze (level 2) → list_strings(keyword) → xrefs_to → disassemble_function. Locate the comparison/conditional branch instruction (beqz/bnez/cmp+bne) that follows the error print call.

18

6) Autonomous Runtime Intervention — Web Expert: Prompt Template

7) Autonomous Runtime Intervention — Generic Expert: Prompt Template

Input: Fault info (HTTP 500/404/empty response), HTTP status code, rootfs path. Objective: Diagnose and fix httpd web-layer issues while the binary process is already running. Analysis Steps: 1) Web Directory Inspection (priority): Verify web root content exists, is non-empty, and contains index files. Check for missing static assets, CGI scripts, or runtime-generated content. 2) Configuration Verification: Check httpd configuration files for correct DocumentRoot, alias mappings, CGI paths, and URL rewrite rules. Ensure configuration targets match actual filesystem layout. 3) Binary Analysis (escalation only): Only when web directory and configuration both appear correct, use radare2 to search for hardcoded paths or vendor-specific routing logic in the binary. 4) Repair & Validation: Fix path mappings, restore missing pages, correct permissions. Validate with validate_network_stack(). A 302 redirect to main.html is considered success. Output: JSON with success status, web-layer repairs, actions taken, and three-layer network validation result.

Input: Unclassified fault info, full tool access, all expert knowledge bases injected. Objective: Handle multi-factor or ambiguous failures that cannot be routed to a single specialist. Analysis Steps: 1) Cross-Domain Diagnosis: Apply the fault routing knowledge base to classify the problem. Inspect process status (vm_exec ps), filesystem integrity, network connectivity, and HTTP behavior simultaneously. 2) Strategy Selection: Based on diagnosis, adopt the corresponding specialist strategy: (a) Crash/GDB for binary failures — string extraction → reverse engineering → breakpoint chain; (b) File for missing resources; (c) Network for connectivity; (d) Web for HTTP errors. For mixed issues, address in priority order one at a time. 3) Execution: Apply the selected strategy with full tool access (radare2, GDB, filesystem, network). Follow the same tool usage discipline as specialist agents — sequential r2 analysis, single-fixper-iteration, immediate validation. 4) Escalation: If the problem can be clearly classified mid-analysis, set needs_rediagnosis=true to route to the appropriate specialist. Output: JSON with fault type, success status, breakpoint chain (if GDB used), actions taken, and threelayer network validation result. E. Intervention strategies for all 21 firmware images. This appendix provides the complete case study data for all 21 firmware images evaluated in our experiments, as detailed in Table VI.. For each device, the table reports the specific rehosting obstacle encountered, the repair phase in which it was resolved, and the targeted intervention applied by F IRM C URE . It extends the representative examples discussed in Section VI-C, offering a comprehensive view of the diversity of boot and runtime failures and the corresponding autonomous repair strategies.

19

TABLE VI C ASE S TUDY: D IVERSITY OF R EHOSTING O BSTACLES AND TARGETED I NTERVENTIONS ( EXTENDED TO ALL 21 FIRMWARE IMAGES ) ID

Device Model

1

Totolink NR1800X

—

2

Totolink N150RT

save_cs_to_file failure

(CrashExpert) A.R.I GDB breakpoint & alter register to bypass

3

D-Link DAP-1522

Missing cfg file

(FileExpert) A.R.I

Reverse Engineering and Create new cfg file

4

D-Link DSP-W215

Unextracted www.tgz

(WebExpert) A.R.I

Extract to specified directory /www

libm.so.0 missing

R.S

Null symlink config

(FileExpert) A.R.I

IPv6 unsupported in VM

(FileExpert) A.R.I

File descriptor limit

(FileExpert) A.R.I

5

D-Link DGL-5500

6

D-Link DIR823X

7

Trigger / Cause

Repair Phase —

Targeted Action Direct boot

Search lib for injection & replace symlink Restore lighttpd.conf from lighttpd_base.conf sed disable server.use-ipv6 sed cap server.max-fds=512, max-connections=256

—

—

Direct boot

WAVLINK NU516U1

Kernel panic

R.S

Adjust QEMU -cpu 74Kf parameter

8

WAVLINK WN531P3

—

—

Direct boot

9

Tenda AC15

ConnectCfm failure

(CrashExpert) A.R.I GDB breakpoint & alter register to bypass

10

Tenda AC18

ConnectCfm failure

(CrashExpert) A.R.I GDB breakpoint & alter register to bypass

11

Tenda AC500

checknetwork failed

(FileExpert) A.R.I

12

Tenda AX1806

kernel too old

13

Draytek Vigor3900

R.S

Missing PATH /usr/sbin IPv6 unavailable Syntax error

(FileExpert) A.R.I (FileExpert) A.R.I (FileExpert) A.R.I (GenericExpert) A.R.I (GenericExpert) A.R.I

Unknown Unknown

Fix path in httpd_start.sh (FileExpert) Remove IPv6 from serverport.conf (FileExpert) Rewrite lighttpd.conf (FileExpert) Simplify serverport.conf (GenericExpert) Extract ajax.zip (GenericExpert)

Netgear WN1000RP

15

Netgear XR500

net-cgi PATH missing /usr/sbin os.distribution() returns unknown

(FileExpert) A.R.I (FileExpert) A.R.I

Symlink net-cgi to /usr/bin and /sbin Create board name, board model id, model files

16

TRENDnet TEW-711BR

Missing hardcoded doc_root Missing PID directory

(FileExpert) A.R.I (FileExpert) A.R.I

Symlink /www to hardcoded path mkdir -p /var/run

17

TRENDnet TEW-813DRU

startup.sh mount order bug jhttpd.conf parsing error (\r\n) PID file creation failure

(FileExpert) A.R.I (FileExpert) A.R.I (FileExpert) A.R.I

Reorder mkdir after ramfs mount Fix config line endings Create /var/run directory

18

TP-Link TL-IPC43AN

Missing /tmp/jffs2_ready flag

(CrashExpert) A.R.I Create marker file via touch

19

TP-LINK RE580D

—

—

Direct boot

20

Asus FW WL500gPv2 2015

—

—

Direct boot

Xiaomi AX9000

—

Adjust kernel version

14

21

—

Create br0 bridge in QEMU VM

Missing PID file directory

(FileExpert) A.R.I

Missing runtime directories

(FileExpert) A.R.I

Nginx upstream unreachable Proxy redirect loop due to upstream missing

(WebExpert) A.R.I (WebExpert) A.R.I

20

Direct boot

Read nginx config, create /tmp/run Create /tmp/sysapihttpd/lock, /tmp/uploadfiles, /tmp/syslogbackup Analyze rewrite rules in miwifi-webinitrd.conf Attempt to disable proxy condition or stub upstream response