2.8pt

1 Introduction↩︎

IoT security analysis often starts from firmware images rather than source code or live devices. Analysts need to know which services actually start, which persistent configuration state gates them, and whether security tools can interact with the resulting runtime. Whole-system firmware rehosting answers this need by unpacking a firmware image, reconstructing a bootable environment, and executing it in QEMU so that network-facing behavior can be probed at scale [1], [2], [12].

The practical barrier is that rehosting remains brittle on heterogeneous firmware corpora [4], [13], [14]. A failed run is rarely caused by one missing command. Boot scripts, vendor wrappers, NVRAM-like key–value state, interface naming, and service launch order interact with each other; a change that makes the kernel boot may still leave the web stack disabled or bound to an unreachable interface. The available feedback is also partial because serial logs, reachability probes, and service snapshots expose symptoms rather than a complete specification of the original device environment.

This setting is well suited to LLM-based agents, which can interpret logs, scripts, and vendor-specific conventions. However, treating an LLM as an unconstrained operator is a poor fit for rehosting because edits affect boot-critical artifacts, success depends on repeated execution, and uncontrolled generation can make results irreproducible. A useful agentic system must therefore make model influence bounded and auditable. Decisions should be grounded in observed or retrieved evidence, actions should pass through typed interfaces, and claims should be validated by fixed probes rather than by model explanations.

We present FirmPilot, an evidence-guided multi-agent framework for firmware rehosting. FirmPilot treats rehosting as evidence-indexed environment reconstruction. The system indexes runtime observations and retrieved evidence, maps them to typed transitions over boot artifacts, persistent state, and network exposure, and accepts a transition only after re-execution and probing. A Search agent retrieves firmware-specific evidence, a Plan agent schedules environment-recovery actions, and File, NVRAM, and Network agents materialize structured deltas through bounded action interfaces. This design turns model reasoning into a constrained control plane for state and exposure recovery.

Beyond basic reachability, FirmPilot targets security-workflow fidelity, namely service-facing, protocol-consistent behavior that lets standard tools execute and leave auditable artifacts in a controlled offline environment. This shifts evaluation from root-page response to whether recovered firmware executions can sustain service discovery, protocol-aware fuzzing, and RouterSploit interactions.

We evaluate FirmPilot on 10,033 images from the large-scale, real-world LFwC firmware corpus and on the 1,122-image public FirmAE benchmark. On the LFwC corpus, FirmPilot improves web-service reachability over FirmAE from 25.49% to 52.39% and network reachability from 39.30% to 71.93%; on the public benchmark, where FirmAE already performs strongly, FirmPilot raises Web reachability from 79.4% to 82.2%. Full-corpus ablations attribute the gain to planning, state synthesis, network exposure recovery, retrieval, and filesystem/init recovery, while a Claude Code baseline reaches only 5.43% web-service reachability on the same corpus. Across all 5,256 web-reachable LFwC rehosts, downstream analyses enumerate services, validate HTTP/HTTPS fingerprints, support manual validation of 193 RouterSploit findings, and enable protocol-aware fuzzing.

We make the following contributions.

• We formulate firmware rehosting as evidence-indexed environment reconstruction under partial observability, where progress depends on resolving coupled boot, state, and network dependencies through execution-accepted transitions.

• We design FirmPilot, an evidence-guided multi-agent environment-recovery loop with typed action interfaces for filesystem/init recovery, NVRAM state synthesis, and network exposure recovery.

• We conduct a large-scale evaluation on 10,033 LFwC images and the public FirmAE benchmark, combining full-corpus ablations, a general-purpose coding-agent baseline, and downstream workflow analyses to show that FirmPilot improves rehosting success and produces 5,256 web-reachable executions that support service discovery, manually validated RouterSploit findings, and protocol-aware fuzzing.

2 Background↩︎

2.1 Firmware Emulation↩︎

Firmware emulation executes firmware code in a controlled environment so analysts can observe runtime behavior without physical devices. IoT-security systems range from whole-system QEMU rehosting to user-space service and dependency rehosting, hybrid execution, and peripheral/MMIO modeling; surveys show that these choices trade off scale, automation, and fidelity [13], [14]. Table 1 positions representative systems.

Whole-system pipelines remain the primary option for scalable service-facing analysis, but they are brittle on heterogeneous corpora because success depends on coupled init, persistent-state, and networking assumptions [13], [14]. Guidance systems improve observability, but they do not close the loop by converting evidence into bounded environment transitions [3], [4]. FirmPilot therefore targets whole-system rehosting as evidence-indexed environment reconstruction.

2.2 Rehosting Failure Modes↩︎

Typical pipelines perform extraction, architecture detection, image construction, init selection, networking setup, and service probing. Each stage can fail when the emulator diverges from the device environment and runtime feedback is incomplete. Common failure patterns are as follows.

• Boot and Init Discrepancies. Incorrect init selection, divergent init systems, or vendor wrappers that assume device-specific mounts and environment.

• Missing Persistent Configuration State. Absent NVRAM-backed values for interface naming, addressing, service toggles, and authentication settings, preventing services from starting even when the kernel boots.

• Network Configuration Discrepancies. Inconsistent interface naming, bridging, or routes, leading to reachability without usable service exposure.

• Cross-Binary Service Dependencies. Multi-process service stacks that fail under incomplete state or partial startup, leading to fragile partial progress [15].

These failures often cascade as a filesystem transition changes init progress, new logs reveal missing state keys, constrained defaults enable interface setup, and services then become observable under probing. Static one-shot pipelines do not exploit this feedback. User-space rehosting [5]–[7], hybrid execution [8], [16], and peripheral/MMIO modeling [9], [10] improve fidelity in complementary settings, but whole-system service analysis still needs scalable environment recovery.

2.3 LLM Agent Foundations↩︎

Large language models can interpret heterogeneous logs and scripts, but rehosting decisions must be grounded in verifiable signals and bounded in what they can change. We use retrieval-augmented prompting [17] and role-specific prompts for multi-step decisions [18]–[20]. Unlike security agents for penetration-testing orchestration, fuzzing guidance, and program/binary analysis [21]–[24], our agents act on boot-critical artifacts under strict budgets, so each role has a bounded action surface.

3 Motivation and Design Challenges↩︎

Whole-system rehosting is the most direct path to scaling service-facing security workflows on heterogeneous IoT firmware, yet progress depends on iterative environment reconstruction across init, persistent state, networking, and services. A practical agentic system must interpret partial runtime evidence, apply small artifact deltas under fixed budgets, and avoid drift into unrealistic device state. This yields three design challenges.

• C1–Limited Domain Knowledge in Firmware Emulation. General-purpose models have uneven coverage of firmware rehosting toolchains and device-specific boot conventions, so plausible suggestions can still conflict with emulator constraints and lead to fragile fixes.

• C2–Inference Under Partial and Noisy Observability. Agents must infer the next environment transition from incomplete, vendor-specific logs, probes, and filesystem evidence while avoiding unsupported causal claims.

• C3–Constrained and Convergent Environment Actuation. Actions can mutate boot scripts, configuration files, and emulator arguments, so deltas must be typed, and the loop must converge under strict budgets without drifting toward unrealistic state injection.

These challenges motivate a separation between semantic inference and environment transition. In firmware rehosting, the unknown object is not a source-level patch but an execution environment whose state is only partially observable through logs and probes. FirmPilot therefore treats LLM outputs as hypotheses over a constrained transition space, while state changes are performed by typed operators and accepted through execution evidence. This turns environment recovery into an evidence-conditioned search problem in which the model helps identify likely missing dependencies, the system exposes only the corresponding action surface, and progress is attributed to observed state changes, not model rationales.

4 System Design↩︎

4.1 Overview↩︎

Figure 1 illustrates FirmPilot as an iterative environment-recovery loop over a shared context. Each iteration executes the current artifacts in QEMU, collects serial logs and probe results ((n)1;), retrieves firmware-specific evidence ((n)2;), plans a dependency-aware transition schedule ((n)3;), and asks specialized agents to emit typed deltas ((n)4;). The orchestrator applies accepted deltas, reboots the firmware, and reruns fixed probes ((n)5;). The loop addresses C1 through retrieval, C2 through execution-grounded planning, and C3 through budgeted, typed, and replayable actuation.

4.2 Environment-Recovery Loop Formalization↩︎

We model FirmPilot as a bounded transition system. At iteration \(t\), artifact state \(x_t\) contains filesystem overlays, launch configuration, NVRAM overrides, and network exposure scripts. Executing \(x_t\) in QEMU yields observations \(o_t\) such as serial logs, reachability results, and service snapshots. The orchestrator extracts evidence \(E_t\) and maintains \(c_t=\langle x_{\le t}, o_{\le t}, E_{\le t}\rangle\); Search augments this context and Plan selects an ordered environment-recovery plan \(p_t\).

Each action agent \(a\in p_t\) models a bounded function from context to an artifact delta, \(a(c_t)=\delta_{t,a}\). Applying these deltas yields the next artifact state. \[x_{t+1} \gets x_t \oplus \bigoplus_{a\in p_t} \delta_{t,a}.\] The operator \(\oplus\) applies a delta to the current artifacts, and \(\bigoplus_{a\in p_t}\) denotes sequential composition in plan order. The agent set is \[\mathcal{A}=\{\mathrm{\small Search},\mathrm{\small Plan},\mathrm{\small File},\mathrm{\small NVRAM},\mathrm{\small Network}\},\] where Search and Plan acquire evidence and schedule actions, while File, NVRAM, and Network update \(x_t\) through filesystem/init deltas, NVRAM overlays, and network artifacts. Model outputs are treated as candidate environment transitions rather than direct authority over the firmware image. A transition becomes part of the run state only after it is emitted through a typed interface, rendered by deterministic tooling, and validated by the next execution and fixed probes. The loop stops when Web reachability is achieved, no admissible action remains under unchanged evidence, or the outer budget is exhausted. The context records artifact versions, observations, retrieved support, and accepted deltas as an execution-indexed causal trace, preserving attribution between evidence, action, and outcome even when progress is non-monotonic.

4.3 Search Agent for Evidence Acquisition↩︎

Role and Evidence Flow. The Search agent gives the loop a controlled path to outside knowledge. Its query packet is built from firmware metadata, vendor/model/board identifiers, architecture, recent serial-log windows, probe summaries, missing binary or library names, NVRAM key names, service binaries, port/banner observations, and compact failure tokens. Retrieval targets Web and GitHub-visible evidence such as vendor documentation, public code repositories, support/forum threads, and prior snippets cached by provenance. Retrieved resources enter the shared context only as cited snippets with query, URL, timestamp, source type, and similarity score. Search keeps a bounded candidate set and admits only the highest-ranked cited snippets to the shared context. It is read-only and cannot change files, state keys, or network parameters. This makes external evidence available to the planner without turning retrieval into an environment-transition mechanism [17].

4.4 Plan Agent for Orchestration and Scheduling↩︎

Responsibilities and Feedback. The Plan agent is the loop control point. It consumes artifact readiness, init and service candidates, probe outcomes, recent error signatures, retrieved snippets, port signals, and accepted deltas, then emits an ordered schedule over File, NVRAM, and Network with a failure class and stop/retry condition. The schedule is explicit because persistent-state recovery can enable service startup, and exposure recovery is meaningful only after a daemon binds or a likely bind address appears. Actions execute through typed interfaces. File emits entrypoint and startup deltas, NVRAM emits key/value/source/guard tuples, and Network emits IP, interface, bridge/VLAN, port, and QEMU-argument tuples. The planner never writes artifacts directly; the next plan observes updated logs and probe state after emulation-relevant mutations.

0pt

Table 2 defines the role contract. Search and Plan reason over evidence and ordering, while File, NVRAM, and Network enact typed transitions over boot artifacts, persistent state, and exposure state.

4.5 File Agent for Boot-Environment Recovery↩︎

Objective and Artifacts. The File agent recovers boot-time filesystem artifacts so static firmware contents reach a runnable user space. It maintains candidate init entrypoints and service-launch specifications, emitting minimal filesystem deltas plus replayable records of inferred init paths, startup commands, and evaluated variants.

Discovery and Service Selection. Figure 4 separates boot-environment inference from artifact mutation. The agent ranks init candidates from filesystem enumeration, common init locations, kernel command-line hints, and retrieved evidence. The LLM may add vendor-specific hypotheses, but it must express them as typed startup deltas and may abstain when evidence is insufficient. FirmPilot validates paths, normalizes arguments, rejects shell metacharacters and destructive utilities, and defaults to existing on-image init scripts when external evidence is insufficient.

4.6 NVRAM Agent for Persistent State Synthesis↩︎

Purpose and Motivation. The NVRAM agent reconstructs persistent configuration dependencies required for service startup. Embedded services consult NVRAM-like stores for interface naming, access control, feature flags, and management-service settings; missing keys can keep daemons disabled even after boot and network recovery. Reconstructed state is materialized as an external key–value overlay rather than a root-filesystem mutation.

Grounded State Synthesis. Figure 5 shows the state-recovery boundary. The agent does not apply a universal NVRAM template; it treats persistent state as a per-firmware inference problem. It builds candidates from runtime NVRAM reads, default files, configuration strings, and model/board/serial/MAC/LAN/Web evidence, then asks the LLM to resolve only prioritized keys not already determined by firmware evidence. Each proposal must be expressed as a key, value, source, and guard. The action interface preserves identity values, rejects malformed fragments and broad credential-series artifacts, and drops empty entries before producing the runtime overlay. State recovery runs when execution evidence shows missing NVRAM devices, invalid flash configuration, pre-bind crashes, or missing product identity; the transition is accepted only when the next execution supports it.

4.7 Network Agent for Connectivity and Exposure Recovery↩︎

Purpose and Design Goal. The Network agent recovers the exposure layer needed for firmware-started services to become reachable, including guest-side connectivity and host-side forwarding/TAP state. It maps noisy logs and vendor-specific interface conventions into a structured network representation, then selects the smallest evidence-consistent update that improves reachability while preserving application behavior.

Inference, Exposure, and Validation. Figure 6 separates exposure inference from environment mutation. The agent reasons over interfaces, addresses, VLANs, bridges, MAC transitions, and service bind addresses using serial logs, probes, NVRAM LAN evidence, and the FirmAE-compatible seed. It then emits a typed exposure delta rather than a broad forwarding rule. The action interface materializes only the selected IP/interface, bridge/VLAN, port, and QEMU-argument tuples. DHCP-like guests use user-mode forwarding for observed bind ports, TAP mode preserves guest subnets and exported probe IPs, and ARM runs keep one active interface with additional probe IPs for multi-address stacks. Updates are accepted only when re-execution confirms both network reachability and a live service endpoint under the fixed probes.

5 Experimental Evaluation↩︎

2.55pt

We evaluate FirmPilot as an environment-aware firmware rehosting system. The experiments ask four questions about end-to-end effectiveness, mechanism contribution, domain specificity, and downstream workflow evidence.

• RQ1 Rehosting effectiveness. Does FirmPilot improve network and web-service reachability over a widely used automated rehosting baseline on a large firmware corpus?

• RQ2 Mechanisms. Which environment-recovery mechanisms account for the observed improvement, and are their effects measurable at full-corpus scale?

• RQ3 Domain specificity. Can a general-purpose coding agent substitute for a firmware-specific recovery workflow?

• RQ4 Downstream security workflow support. Do web-reachable FirmPilot rehosts support downstream security workflows beyond reachability?

Dataset and baselines. The primary large-scale dataset is LFwC [25], a public Linux-firmware corpus built for reproducible firmware vulnerability research with documented acquisition metadata, unpacking checks, deduplication, content identification, and ground-truth annotations. Its metadata snapshot contains 10,913 records; 880 vendor or archival links were no longer reachable, leaving 10,033 locally executable images. These 10,033 images are the fixed denominator for all main LFwC comparisons, ablations, and general-agent baselines. We compare FirmPilot against FirmAE [2], a QEMU-based rehosting pipeline from the Firmadyne lineage [1] that produces comparable disk images, run scripts, logs, and probes.

We also evaluate on the public FirmAE benchmark, which contains 1,122 images across 8 vendors and ARM-LE/MIPS-BE/MIPS-LE architectures. This established benchmark is closely aligned with FirmAE’s original templates and provides a comparability point, while LFwC supplies the main corpus.

Comparison and ablation protocol. The evaluation separates three sources of evidence, namely a deterministic rehosting baseline, an internal role ablation, and a general-purpose coding-agent baseline. FirmAE represents the template-driven deterministic alternative, with fixed image construction, boot inference, NVRAM defaults, network heuristics, QEMU execution, and the same probes, but no retrieval, planning, or typed agent actions. RQ1 measures the deterministic-to-FirmPilot gap under identical predicates. RQ2 keeps FirmPilot’s runnable substrate while replacing one adaptive role at a time with its deterministic fallback. In this setting, no-Search uses only local evidence, no-Plan follows a fixed dependency order, no-File uses baseline-style init and launch candidates, no-NVRAM retains FirmAE-compatible defaults, and no-Network retains deterministic network inference. RQ3 replaces the specialized action space with a general coding agent under the same dataset, timeout, input evidence, and success predicates.

Execution policy and metrics. All RQ1–RQ3 systems use a QEMU-based execution path [12], fixed probes, and identical success predicates. All agents use DeepSeek V4 Flash as the LLM backend throughout the evaluation. Consistent with FirmAE’s Docker evaluation workflow, which uses a 2,400-second per-firmware emulation-result check, each RQ1–RQ3 image receives the same 2,400-second wall-clock budget for rehosting and probing; FirmAE, FirmPilot, and Claude Code all use this cap, and FirmPilot runs at most three planner rounds within it. Network reachable requires a standardized ICMP response. Web-service reachable requires a completed HTTP(S) transaction to an exported guest-IP candidate, using bounded GET requests to /. HTTPS candidates complete the TLS handshake before request delivery, and the probe records status, redirects, authentication challenges, banners, and fingerprints when present. Success includes root pages, redirects, authentication gates, and other parseable management responses; status 200 is not required. Each request uses a two-second timeout inside the image budget.

The predicates separate network liveness from service readiness. ICMP measures packet exchange, while Web success requires a reachable and parseable management endpoint. This keeps Ping/Web columns directly comparable across FirmAE, FirmPilot, and the general-agent baseline.

RQ4 evaluates whether the recovered rehosts can support downstream analysis workflows beyond basic reachability. The audit reruns service discovery with nmap -O -sV, retries incomplete scans with nmap -Pn -n -sV, and credits valid scans only when complete XML contains auditable service records. HTTP/HTTPS evidence requires an endpoint, service label, protocol, and available banner/fingerprint fields from nmap or confirmation probes. RouterSploit and protocol-aware fuzzing then operate on this recovered surface. Counts use the 10,033-image denominator unless a table states otherwise.

Evaluation records. All reported counts are computed from per-image execution records rather than ad hoc log inspection. Each record binds the firmware identifier, execution budget, generated artifacts, serial output, probe transcript, and final reachability labels. RQ4 records additionally attach the service-discovery, RouterSploit, and fuzzing artifacts credited in the downstream workflow. This common record structure keeps the LFwC, ablation, and general-agent comparisons aligned at the image level.

5.1 RQ1 Overall Rehosting Effectiveness↩︎

Overall reachability. RQ1 tests the central rehosting claim that a rehost becomes useful for interactive analysis only when the firmware exposes an externally reachable service, not merely when the kernel boots or a network stack responds. Under identical probes on the full 10,033-image LFwC set, FirmAE makes 3,943 images network reachable and 2,557 images web-service reachable, corresponding to 39.30% and 25.49% of the corpus. FirmPilot increases these numbers to 7,217 network-reachable images and 5,256 web-service-reachable images, corresponding to 71.93% and 52.39%. This is an absolute improvement of 3,274 network-reachable images and 2,699 web-service-reachable images over FirmAE; Table 3 reports the public-benchmark and LFwC vendor results under the same Ping/Web-service columns.

Benchmark and long-tail effects. On the public FirmAE benchmark, where existing templates already cover many cases, FirmPilot preserves the high reachability level expected on this established setting and raises Web-service reachability from 79.4% to 82.2%. The LFwC results expose a larger gap under heterogeneous, long-tail firmware images. For Netgear, ASUS, TP-Link, Linksys, and EnGenius, FirmPilot reaches web-service rates above 50%. For D-Link, Ubiquiti, and AVM, the absolute rates remain lower, but FirmPilot still substantially improves over FirmAE, especially on Ubiquiti where FirmAE reaches only 13 web services while FirmPilot reaches 396. This contrast shows that environment recovery is most valuable when template coverage is sparse and reachability depends on coordinating boot, persistent state, and network exposure.

Architecture split. Figure 7 complements the vendor view with an endian-aware primary firmware architecture split of the same 10,033 LFwC images. FirmPilot reaches Web services on 1,588 MIPS-BE, 942 MIPS-LE, and 2,192 ARM-LE images, while making 2,309, 1,389, and 2,951 images network-reachable in the same groups. These router-class architecture groups account for 4,722 of the 5,256 Web-service successes; PowerPC, x86, unresolved-endian, and rare groups are aggregated into the long tail.

Residual failure modes. The final-state distribution in Figure 8 shows that FirmPilot’s failures are not dominated by one residual bottleneck. Among the 10,033 images, 5,256 reach a web service. The remaining images primarily fail because of runtime emulation failures (2,604 images), extraction or registration failures (1,675 images), and architecture-handling failures (498 images). This distribution shows that the remaining failures are spread across extraction, architecture handling, runtime execution, and late-stage service launch rather than concentrated in one probe or service check.

Interpretation. The RQ1 result is strongest on the large LFwC corpus because LFwC contains vendor and version diversity that stresses fixed templates. FirmPilot does not merely increase Ping success and then inherit Web success automatically. The absolute Web gain of 2,699 images is close to the network gain in scale but not identical in source, since many additional successes require persistent-state synthesis for service toggles and exposure recovery for bind-address mismatches after basic boot progress. The vendor-level table makes this visible. Large gains on Ubiquiti, Linksys, EnGenius, and D-Link indicate that environment reconstruction exposes service paths left dormant by static baselines.

5.2 RQ2 Contribution of Specialized Agents↩︎

Ablation setup. RQ2 evaluates specialized roles after holding the deterministic execution substrate fixed. The deterministic alternative is template-driven rehosting represented by FirmAE, which fixes image construction, boot inference, NVRAM defaults, and network setup through heuristic templates. We run leave-one-module ablations for SearchAgent, PlanAgent, FileAgent, NVRAMAgent, and NetworkAgent on the same 10,033-image LFwC set. Each ablation keeps QEMU execution, boot hooks, overlay infrastructure, renderers, and probes runnable while replacing one agent’s adaptive decisions with the closest deterministic fallback used by the substrate.

State and exposure fidelity. The ablation results treat persistent state and network exposure as first-order recovery dimensions rather than implementation details. NVRAMAgent admits candidate keys from execution-consulted reads, missing-key traces, defaults and configuration files, static strings, and device/LAN/Web identity evidence. Its typed action interface preserves source and guard fields, while deterministic filters reject malformed fragments, web assets, symbol-like tokens, broad credential-series artifacts, and empty values before overlay materialization. NetworkAgent follows the same evidence discipline by deriving exposure deltas from interface/IP traces, bridge/VLAN/MAC events, service bind addresses, NVRAM LAN evidence, and the FirmAE-compatible seed, then rendering only selected interface, address, bridge/VLAN, port, and QEMU-argument tuples.

Full-success state/exposure distribution. We audit the same 5,256 Web-success images used throughout the downstream workflow analysis. NVRAM key files appear on 1,975 images, and nonempty NVRAM materialization covers 1,971 images with 479,440 key entries and 5,320 file-backed entries. The dominant key classes are system/default state (170,925), wireless/region state (119,536), LAN/interface state (105,064), WAN/DNS/gateway state (33,391), service exposure (30,995), identity/model state (13,068), and authentication/access state (11,781). Network exposure artifacts cover 5,191 images, materializing 5,370 exported IP entries, 2,703 QEMU network-argument artifacts, 2,607 bridge/VLAN/interface setup scripts, 161 multi-IP cases, and service-probe records on 2,696 images.

Paired full-success effect. RQ2 measures each role on the 5,256 accepted Web-success executions from the full system. A loss is counted when one of these executions no longer reaches Web under the corresponding deterministic fallback. Replacing PlanAgent loses 2,472 images across 590 brand-device families; replacing NVRAMAgent loses 2,003 images across 462 families, with 1,671 also losing Ping; replacing SearchAgent, NetworkAgent, and FileAgent loses 1,568, 1,558, and 1,525 images, respectively. The NVRAM and Network dependency sets are coupled but distinct. In this split, 1,484 images fail under both removals, 519 only without NVRAMAgent, and 74 only without NetworkAgent. In an ASUS DSL-N10_C1 case, the full run reconstructs 198 execution-consulted NVRAM keys across LAN, WAN, UPnP, region, and interface state, starts /usr/sbin/httpd, and passes both probes; the no-NVRAM run loses Web reachability. In an ASUS DSL-AC88U case, the full run recovers br0 at 192.168.1.1, maps the management address through the observed bridge/interface relation, and exposes HTTP to the probe path; the no-Network run loses Web reachability. These cases link aggregate losses to concrete transitions and show corpus-scale state and exposure recovery.

Agent contributions. Figure 9 reports how many full-system Web successes remain reachable after each leave-one-module replacement. The full system reaches 5,256 images. Replacing PlanAgent with a fixed schedule causes the largest drop, retaining 2,784 of them and losing 2,472. Replacing NVRAMAgent with deterministic defaults retains 3,253 and loses 2,003. Replacing FileAgent, NetworkAgent, and SearchAgent with their deterministic fallbacks retains 3,731, 3,698, and 3,688, respectively. These paired losses show that the agents are complementary. Planning, persistent-state synthesis, network exposure, retrieval, and filesystem/init recovery each contribute measurable gains beyond template-driven fallbacks.

Mechanism interpretation. PlanAgent is the most influential component because environment transitions are order-sensitive. Network exposure before persistent-state recovery, or startup changes without runtime evidence, can create conflicting states. NVRAMAgent confirms the importance of execution-consulted state such as region, device mode, interface names, and authentication defaults, accounting for 2,003 lost Web successes when replaced by deterministic defaults. SearchAgent, NetworkAgent, and FileAgent each account for more than 1,500 lost Web successes, covering long-tail evidence retrieval, log-grounded interface and address exposure, and boot/init recovery. The different loss patterns show that FirmPilot’s gain comes from coordinated agent roles validated through execution feedback, rather than from a single permissive rule or isolated artifact edit.

5.3 RQ3 General-Purpose Coding Agent Baseline↩︎

Baseline protocol. RQ3 tests whether general coding-agent capability transfers to firmware rehosting without the domain-specific recovery structure used by FirmPilot. We evaluate Claude Code as a single general-purpose coding-agent baseline on the same 10,033-image LFwC set and the same 2,400-second per-image wall-clock budget as FirmPilot. For each image, the baseline receives the same firmware package, extracted workspace, low-level rehosting utilities, run-script context, serial-log evidence, and probe-output format available to the recovery workflow, but it is isolated from FirmPilot’s multi-agent orchestrator and typed action interfaces. The comparison uses the same Ping and Web-service predicates defined above, the same guest-IP and HTTP(S) probe logic, and one latest-result record per firmware image for reachability and resource accounting. Under this controlled protocol, Claude Code reaches 729 images by Ping and 545 images by Web, corresponding to 7.27% and 5.43%. In contrast, FirmPilot reaches 7,217 images by Ping and 5,256 images by Web.

2.4pt

Success-set overlap. The Web-success partition in Table 4 further clarifies the difference between generic exploration and domain-specific environment recovery. Only 314 web successes are shared between Claude Code and FirmPilot. Claude Code has 231 unique web successes, but FirmPilot has 4,942 unique web successes. Measured against FirmPilot’s web-success set, Claude Code recovers only 5.97% of the images that FirmPilot can expose as web services. This gap indicates that the task is not simply to generate plausible shell commands or code edits. The system must identify firmware-specific state assumptions, apply bounded artifact transitions through structured interfaces, and accept changes only after execution-grounded validation.

Resource profile. The token profile strengthens this conclusion. Using the same 10,033-image LFwC denominator, Claude Code’s latest-result aggregation consumes 36.23B model tokens, corresponding to 3.61M tokens per firmware. FirmPilot’s main-run logs consume 12.4 thousand tokens per firmware. Claude Code therefore uses about 291 times more model context while recovering far fewer services.

Failure pattern. The baseline often spends its budget exploring a local workspace without converging on the coupled device environment assumptions that govern firmware startup. In contrast, FirmPilot exposes these assumptions as explicit recovery surfaces covering filesystem/init selection, persistent key–value state, and network exposure. The evidence is cumulative. RQ1 separates FirmPilot from template-driven deterministic rehosting, RQ2 identifies which specialized decisions carry the gain after the shared substrate is held fixed, and RQ3 shows that a strong general coding agent does not recover the same service surface when it lacks the domain action space and feedback loop. Scalable firmware rehosting therefore benefits from a domain-specific control plane that decides when model reasoning may enter the loop, what form its output may take, and how execution results accept or reject that output.

5.4 RQ4 Support for Downstream Security Workflows↩︎

Workflow scope. RQ4 evaluates whether web-reachable rehosts preserve enough service behavior for standard downstream security workflows. We analyze all 5,256 LFwC web-success images, covering 622 brand-device families after collapsing firmware-version variants by brand and device_name. The audit uses service discovery, RouterSploit known-check interaction, and protocol-aware fuzzing, crediting only per-firmware artifacts written by the workflow.

Audit coverage. Figure 10 summarizes the downstream artifact scale. Each audited image contributes service-discovery records, web-fingerprint evidence, RouterSploit transcripts, and protocol-input artifacts. These records bind the recovered endpoint to the tool interaction that exercised it, so RQ4 measures executable workflow evidence rather than raw open-port counts.

2.0pt

Service discovery. Table 5 shows that the recovered environments expose a substantially broader service surface than the deterministic baseline. Across the same LFwC denominator, FirmPilot increases the average number of detected services per firmware from 0.86 to 1.62. The valid service records include protocol labels, endpoints, and available banners or fingerprints, giving downstream tools concrete targets rather than only reachability labels.

1.3pt

Known-check interaction. RouterSploit turns the recovered service surface into executable known-check workflows. We run RouterSploit over the full 5,256-image RQ4 audit set and obtain output and module records for every recovered web-success image. Across this full set, 63,561 module runs span 586 brand-device families and 33 public router modules covering command execution, information disclosure, path traversal, authentication bypass, default credentials, and related checks. Because these modules require service dialogue, request paths, authentication state, or protocol exchanges, positive transcripts validate behavior beyond service discovery.

Positive transcripts. The CVE-linked checks cover Netgear password disclosure (CVE-2017-5521), D-Link HNAP RCE (CVE-2015-2051), and Misfortune Cookie (CVE-2014-9222). The strict subset contains 408 module-confirmed positives across 336 images and 309 families, including 65 known-check positives from exploit-oriented modules and 343 FTP/SSH/Telnet default-credential authentications across 302 images. Manual validation confirms 193 reproducible RouterSploit findings, including 30 known-vulnerability findings and 163 authentication-exposure findings. These results show that the recovered service surface supports stateful validation of known-vulnerability paths and authentication exposures.

Protocol-aware testing. The recovered service surfaces also support protocol-aware input delivery. The fuzzer derives input sites from recovered CGI parameters, forms, HNAP or SOAP fields, UPnP and SSDP identifiers, and cookie-bearing entries. CI mode exercises command-oriented inputs, while BOF mode stresses request and protocol parsers with cyclic or fixed-size buffers. Crash triage uses runtime log tails and deduplicates signals by image, mode, phase, crash kind, marker, and excerpt.

2.0pt

Runtime feedback. Table 7 reports 4,012 CI crash hits, 4,591 BOF hits, and 1,565 images with at least one image-level crash candidate. The 1,288-image CI/BOF overlap shows that recovered services expose input paths with both semantic reachability and memory-stress feedback, giving downstream testing tools concrete endpoint, protocol, and process context.

RQ4 takeaway. RQ4 shows that FirmPilot turns reachability gains into downstream workflow support. The recovered environments expose broader service surfaces than FirmAE, sustain RouterSploit known-check interactions with manually validated findings, and support protocol-aware input delivery with runtime feedback. These results show that evidence-guided environment recovery improves not only Web reachability but also the practical utility of rehosted firmware executions.

5.5 Threats to Validity and Mitigations↩︎

Dataset scope. LFwC provides metadata for 10,913 firmware records; the executable set contains the 10,033 records whose packages remained downloadable from recorded vendor or archival locations, and all main LFwC comparisons use this denominator.

Workflow fidelity. RQ4 counts service discovery, fuzzing, and RouterSploit evidence only from per-image workflow records, making the evaluation stricter than raw reachability.

Baseline scope. FirmAE is the direct deterministic baseline because it supports the same full-image QEMU execution and Ping/Web predicates. Claude Code evaluates the separate question of whether a general-purpose coding agent can substitute for the domain-specific action space under the same denominator, timeout, evidence bundle, and success predicates.

LLM variability. FirmPilot reports outcomes through fixed probes and per-image execution records, while constraining model outputs to typed actions and deterministic artifact renderers. Replications should keep probes and denominators fixed across models.

6 Related Work↩︎

Scalable Firmware Rehosting. Prior systems improve different parts of the firmware-analysis stack. Firmadyne-style systems construct disk images, infer architecture and kernels, synthesize run scripts, and derive network parameters through deterministic templates [1]. FirmAE strengthens this full-image lineage with arbitrated emulation, NVRAM defaults, and network heuristics, making it the closest template-driven deterministic baseline for the Ping/Web reachability protocol used in this work [2]. FirmGuide and PANDaWAN focus on diagnosing or guiding rehosting failures [3], [4], while Greenhouse, FIRMWELL, and user-space dependency-aware rehosting reduce execution complexity by isolating services or user-space dependency environments [6], [7]. FirmPilot targets a different point in this space because it keeps the full-system execution setting but replaces fixed environment templates with evidence-grounded recovery over boot, persistent state, and exposure artifacts.

The distinction is important for scale. Identifying a missing init dependency, state key, or service condition is not enough unless the system can translate that evidence into a repeatable execution environment. FirmPilot makes that path part of the system. Evidence is converted into typed deltas, deltas are applied through deterministic renderers, and the resulting firmware execution is re-probed under the same predicates. This design keeps the evaluation aligned with executable environment recovery rather than isolated failure explanation.

Emulation Fidelity. Hybrid execution combines emulation with hardware for complex peripherals [8], [16], while modeling and abstraction improve portability and fuzzing effectiveness [9], [10], [26]. Invalidity-guided inference uses execution failures to discover missing assumptions [27]. These works enrich the execution substrate; FirmPilot instead coordinates cross-layer service recovery on scalable whole-system rehosts.

Firmware Security Analysis. Embedded security analyses require reachable services and stable execution for validation and triage. Prior work covers authentication-bypass detection [28], application-driven IoT fuzzing [29], keyword-based bug discovery [30], greybox fuzzing [31], firmware fuzzing [11], [32], driver/peripheral analysis [33], [34], and tracing/replay [35], [36]. FirmPilot complements these tools by making more firmware executions reachable and analyzable.

LLM Agents for Automated Analysis. Agentic LLM systems support penetration testing [21], fuzzing guidance [22], program/binary analysis [23], [24], multi-agent coordination [20], [37], and program-transformation pipelines with retrieval, planning, patch generation, and validation [38]–[40]. FirmPilot adapts this paradigm to firmware rehosting by binding agent decisions to typed environment updates, where retrieval supplies evidence, planning orders recovery actions, specialized agents update state and exposure, and reruns with fixed probes validate the resulting artifacts.

Firmware rehosting differs from many code-repair or penetration-testing settings because the target behavior is not specified by a test suite or a live remote service. The desired environment must be reconstructed from partial device assumptions, including init scripts, persistent-state reads, network-interface conventions, and probe responses. FirmPilot therefore uses LLM agents as bounded environment-recovery components rather than open-ended operators. The Claude Code baseline in RQ3 shows why this distinction matters because broad coding ability does not replace domain-specific evidence routing, action schemas, and execution-grounded acceptance.

7 Discussion↩︎

Rationale for a Multi-Agent Architecture. Rehosting failures are cross-layer and sequential, so progress requires coordinated evidence interpretation and constrained actuation. Role specialization separates what to infer from what to change by assigning Search and planning to symbolic evidence and File, NVRAM, and Network agents to concrete artifact surfaces. The ablations show that removing one role disables a specific recovery channel rather than a monolithic prompt.

Security-Workflow Fidelity. Web reachability is only the entry criterion. RQ4 requires recovered services to sustain enumeration, manual validation of 1-day and credential-path findings, protocol-input delivery, and crash triage, turning reachability into an execution substrate for security analysis.

Verifiability. The unit of evidence is a per-image execution trace rather than a model explanation. Each trace links observations, retrieved support, typed deltas, rendered artifacts, probes, final labels, and downstream tool outputs. This structure makes the reported counts auditable from the same records that drive the recovery loop and keeps failures inspectable at the transition where execution stopped.

Limitations and Future Work. FirmPilot does not fully address peripheral and device-specific I/O modeling, and customized stacks can still fail because of late-stage dependencies such as missing libraries, certificates, or vendor wrappers. Future work can combine environment recovery with hardware-in-the-loop execution [8], [16] and MMIO modeling [11].

Security and Ethical Considerations. The evaluation runs offline in isolated rehosting environments and does not scan live devices; generated deltas target analysis artifacts, and real-device follow-up should follow responsible disclosure.

8 Conclusion↩︎

FirmPilot addresses firmware-rehosting brittleness through an evidence-guided multi-agent environment-recovery loop over boot, state, and network layers. Specialized agents interpret runtime evidence and apply typed, replayable artifact deltas. Across LFwC and the public FirmAE benchmark, FirmPilot improves service reachability and supports service discovery, manual validation of RouterSploit findings, and protocol-aware fuzzing. The results show that agentic reasoning is effective for firmware rehosting when constrained by evidence, explicit transition interfaces, and repeated execution.

References↩︎