Firmware Reverse Engineering: A Comprehensive Review and Directions

Abstract

Firmware forms the persistent software layer controlling embedded and Internet-of-Things (IoT) devices, industrial controllers, automotive systems, and cyber-physical infrastructure. Vulnerabilities in firmware enable remote compromise, supply-chain attacks, and long-lived implants that survive operating-system reinstallation. This review synthesises 118 works published from 2014 to 2026—comprising 78 primary research studies; 23 surveys and systematisations of knowledge; and 17 benchmarks, tools, and background references—covering the full firmware reverse engineering (FRE) pipeline: physical acquisition (including fault injection and side-channel extraction), format analysis and unpacking, static analysis (binary code similarity detection, protocol reverse engineering, and patch diffing), dynamic analysis and hardware emulation, fuzzing-based vulnerability discovery, and artificial intelligence (AI) and large language model (LLM)-assisted analysis. Three additional dimensions are surveyed: digital twin-assisted firmware security testing; secure boot, trusted execution environment (TEE), and over-the-air (OTA) update security; and firmware rootkit and implant detection. Coverage spans two axes—the firmware class (Linux-based IoT, microcontroller-unit bare-metal, RTOS, UEFI/BIOS, PLC/ICS, and automotive ECU) and analysis depth (surface scanning to exploit-validated vulnerability chains). We identify ten structural gaps, including the absence of unified evaluation benchmarks, fragmented peripheral modelling, the scalability–fidelity trade-off in re-hosting, and insufficient grounding of LLM tools in firmware-specific realities. We conclude with six research directions for trustworthy, scalable, and infrastructure-aware firmware analysis.

1. Introduction

Firmware is the low-level software embedded in microcontrollers, systems-on-chip (SoCs), network appliances, industrial controllers, and consumer IoT devices. Firmware executes with hardware-level privileges and without runtime memory protection, making it a persistent, high-value attack target [1,2]. Known vulnerabilities propagate across device generations and vendor product lines [3,4], and firmware compromises in safety-critical domains—automotive, industrial control, and medical systems—carry consequences beyond data loss [5,6,7]. The embedded attack surface is vast: consumer, industrial, and infrastructure devices all run firmware that receives infrequent or no security updates, and supply-chain studies confirm that third-party library vulnerabilities reappear in products from unrelated vendors [3,8].

Firmware reverse engineering (FRE) encompasses the extraction, parsing, and analysis of firmware binaries without source code or hardware documentation. It underpins vulnerability disclosure, patch diffing, malware attribution, supply-chain verification, and compliance auditing [4,9]. Several properties specific to embedded binaries make this analysis harder than desktop software. Symbols and debug metadata are absent. Execution depends on undocumented hardware peripherals—memory-mapped I/O registers, DMA channels, interrupt controllers—that must be modelled to achieve emulation without physical hardware. The instruction-set landscape is heterogeneous: ARM Cortex-M, MIPS, RISC-V, Xtensa, and PowerPC targets coexist, each requiring separate toolchains. Proprietary packing or encryption must be reversed before any analysis can begin. These obstacles compound: a single vulnerability campaign may require successful extraction, cross-architecture disassembly, peripheral-aware emulation, coverage-guided fuzzing, and binary code similarity detection to confirm cross-product scope [9,10].

The problem of FRE has advanced across all pipeline stages since 2018. Scalable emulation platforms [11,12], HAL-level re-hosting [13,14], MMIO modelling [15], and firmware-adapted coverage-guided fuzzing [16,17] each address a specific stage. Large language models (LLMs) have entered the pipeline most recently: FirmAgent [18] combines LLM-guided reasoning with directed fuzzing for IoT vulnerability discovery; neural decompilers [19,20] produce near-source output from stripped binaries. Renewed regulatory pressure on embedded product security—from the EU Cyber Resilience Act to US Executive Order 14,028—has further elevated demand for systematic FRE methodology. No prior survey covers the complete analysis pipeline from acquisition through AI-assisted analysis with smart-infrastructure framing and an explicit gap taxonomy; this review fills that gap.

1.1. Scope and Contributions

This review makes the following contributions:

• A structured survey of FRE techniques across the full analysis pipeline, synthesising 118 referenced works published from 2014 to 2026, of which 78 are primary research studies; the remainder comprise 23 prior surveys and systematisations of knowledge, four benchmark studies, and 13 tools, standards, and background references (Section 2, Section 3, Section 4, Section 5, Section 6, Section 7, Section 8, Section 9 and Section 10).
• A cross-cutting taxonomy by firmware class and analysis depth (Section 2).
• Identification of ten structural gaps and their relationship to smart-infrastructure deployment (Section 11).
• Six prioritised research directions for unified, trustworthy, and infrastructure-aware firmware analysis (Section 12).

1.2. Differentiation from Existing Surveys

Several surveys address aspects of firmware security; none covers the complete FRE pipeline.

Table 1. Comparison with closely related prior surveys across pipeline and framing dimensions, based on each survey’s stated scope. Acq = acquisition and unpacking; Stat = static analysis and binary code similarity; Emu = emulation and re-hosting; Fuzz = fuzzing and dynamic discovery; AI = AI/LLM-assisted analysis; OTA/SB = OTA update, secure boot, and TEE security; Infra = smart-infrastructure case studies; Gaps = consolidated gap taxonomy. ✓= covered; − = not covered.

Survey	Year	Acq	Stat	Emu	Fuzz	AI	OTA/SB	Infra	Gaps
IoT firmware vulns [1]	2024	−	✓	−	−	−	−	−	−
IoT/embedded fw security [4]	2023	✓	✓	−	−	−	−	−	−
Taxonomy and analysis techniques [9]	2022	−	✓	−	−	−	−	−	−
Vuln detection survey [8]	2023	−	✓	−	✓	−	−	−	−
Auto vuln detection [21]	2022	−	✓	−	−	−	−	−	−
Symbolic execution survey [22]	2025	−	✓	−	−	−	−	−	−
Re-hosting challenges [10]	2020	−	−	✓	✓	−	−	−	−
This review	2026	✓	✓	✓	✓	✓	✓	✓	✓

positions this review against the most directly related prior works.

Surveys S1–S5 are vulnerability-centric: they catalogue weakness classes and detection methods but do not treat the analysis pipeline as their primary subject. S6 surveys symbolic execution across multiple domains; firmware is one of many targets, not the focus. S7 [10] is the closest predecessor and provides thorough re-hosting coverage but predates LLMs, does not survey post-2020 fuzzing systems, and omits smart-infrastructure deployment contexts. Domain-specific surveys S8–S13 cover single sub-topics (hardware Trojans, TEE security, OTA updates, ICS protocol RE, automotive OTA) and are complementary.

This review advances the prior body in four ways:

• Full-pipeline integration: Every analysis phase—acquisition, unpacking, static analysis, emulation, fuzzing, AI-assisted analysis—is surveyed as part of one integrated pipeline, with explicit discussion of inter-stage dependencies.
• AI/LLM coverage: LLM-based decompilation, agentic firmware analysis, and AI-driven malware detection are surveyed for the first time in a firmware-focused review, covering tools from 2023 to 2026.
• Smart-infrastructure framing: Domain case studies span automotive, ICS/PLC, medical, and smart-grid firmware, matching the safety-critical deployment contexts that motivate systematic FRE.
• Consolidated gap taxonomy: Ten structural gaps and six research directions are stated explicitly as an actionable agenda rather than a generic future-work section.

Ethical and Legal Scope

All analysis surveyed in this review was conducted on publicly released firmware images, research testbeds, or devices owned by the respective researchers. No live production systems were targeted without authorisation. Responsible disclosure practices are assumed to apply to any vulnerability discovery work cited; readers applying these techniques to production systems should operate within applicable legal frameworks (e.g., the EU NIS2 Directive, US Computer Fraud and Abuse Act, and relevant national cybersecurity legislation) and coordinate disclosure with device vendors prior to public release.

1.3. Literature Selection Methodology

This review follows a structured narrative methodology rather than a systematic literature review (SLR) protocol such as PRISMA: the aim is analytical synthesis of a fast-moving and venue-fragmented field, not exhaustive enumeration. To make the selection process transparent and repeatable, the search protocol, screening workflow, counting rules, and quality-appraisal approach are documented below.

1.3.1. Search Protocol

Literature searches were performed between 19 April and 3 May 2026, with a final update pass in June 2026 covering NDSS 2026 and recent preprints. Nine databases and venue libraries were queried: IEEE Xplore, ACM Digital Library, ScienceDirect, Springer Nature Link, the USENIX Security and NDSS open proceedings archives, the MDPI library, arXiv, and Semantic Scholar. Rather than a single frozen Boolean expression, each database was queried once per technique area, using the following search strings verbatim: firmware reverse engineering, firmware emulation, firmware re-hosting, firmware fuzzing, binary code similarity, firmware unpacking, LLM binary analysis, LLM decompilation, hardware Trojan detection, secure boot, OTA update security, and digital twin firmware security.

1.3.2. Screening Workflow

The initial two-pass harvest yielded 115 candidate works. Backward snowballing from the reference lists of the included surveys and targeted per section searches during drafting (notably for digital twins, medical-device, and smart-grid firmware) contributed further candidates. Duplicates across databases were removed by title and DOI matching. Each candidate was screened against the inclusion and exclusion criteria below; surviving entries were verified against DBLP and publisher metadata to confirm venue, year, and peer-review status. Candidates excluded at screening were predominantly software-only malware analyses without firmware specificity, HDL-level hardware-design works, and records whose venue or peer-review status could not be verified. Because the harvest was iterative—snowballing and per section searches continued during drafting—stage-by-stage record counts were not frozen as they would be in a PRISMA flow; the quantities reported here are therefore the two that are auditable: the initial harvest size and the composition of the final corpus. The final corpus comprised 118 works: 78 primary research studies; 23 surveys and systematisations of knowledge; 4 benchmark studies; and 13 tools, standards, and background references. A primary research study presents a novel technique, system, attack, or empirical measurement; works whose principal contribution is synthesis of the prior literature are counted as surveys, and non-peer-reviewed tool documentation, technical reports, and peer-reviewed system-level context studies outside the FRE scope (such as cyber-physical power-system resilience models) are counted separately as background references.

1.3.3. Inclusion and Exclusion Criteria

Inclusion criteria were as follows: peer-reviewed papers (plus a small number of widely cited preprints and technical reports, flagged as such) on firmware acquisition, unpacking, static or dynamic analysis, emulation and re-hosting, fuzzing, AI/ML-assisted binary analysis, hardware security, digital twin security, OTA update security, or domain case studies in automotive, industrial, medical, or smart-grid firmware. Exclusion criteria were as follows: software malware analysis without firmware specificity, HDL-level hardware design, and non-security firmware engineering. The primary window is 2018–2026; seminal earlier works (2005–2017) were retained where they established concepts still in active use, such as large-scale firmware analysis [2] and symbolic vulnerability detection [23].

1.3.4. Quality Appraisal and Scope of Claims

Primary systems are compared along explicit dimensions—target firmware class, evaluation corpus, peripheral support, coverage metrics, artefact availability, and real-device validation—in the comparison tables of Section 4, Section 5, Section 6 and Section 7 and the maturity assessment of Section 11.1. Given the narrative methodology, the corpus should be read as a representative, venue-verified cross-section of the field rather than an exhaustive census; the gap analysis in Section 11 is quantified against this corpus.

1.4. Paper Organisation

Section 2 introduces firmware classes and the FRE workflow. Section 3 covers acquisition, unpacking, side-channel extraction, and anti-analysis countermeasures. Section 4, Section 5, Section 6 and Section 7 survey each analysis phase, with Section 4 additionally covering protocol reverse engineering (Section 4.6), patch diffing (Section 4.7), and a tool comparison table. Section 8, Section 9 and Section 10 cover domain case studies, digital twins, and platform security (including firmware rootkit and implant detection in Section 10.5). Section 11 synthesises ten structural gaps, and Section 12 proposes research directions. Section 13 concludes.

2. Firmware Architecture and Classification

Firmware is the software layer permanently stored in a device’s non-volatile memory that initialises hardware and implements the device’s core logic. Unlike general-purpose software, firmware is tightly coupled to specific hardware: the instruction set, memory map, and peripheral interface determine what analysis techniques are feasible and which attack surfaces are reachable. The diversity of firmware classes—from monolithic bare-metal binaries for microcontrollers to multi-component Linux distributions in IoT routers—means that no single toolchain or methodology applies uniformly across targets. Classifying firmware is therefore not merely taxonomic: identifying a target’s class determines which extraction methods, emulators, and analysis pipelines apply. The classification framework in this section underpins the remainder of the review.

2.1. Firmware Classes

Firmware is not a monolithic category. Analysis challenge, tooling requirements, and security attack surfaces differ substantially across the following classes [10,24]:

• Linux-based IoT firmware: The most extensively studied class [2,11,17]. Typically a uClibc/Busybox userland over a Linux kernel, packaged as SquashFS or JFFS2 inside a proprietary image. QEMU-based emulation is well-established. Weaknesses include exposed web interfaces, hard-coded credentials, and unpatched third-party libraries.
• MCU bare-metal firmware: Monolithic binaries for ARM Cortex-M, MIPS, and similar microcontrollers. No OS; direct register and peripheral access. Re-hosting requires peripheral modelling [13,14,15]. Attack surfaces include MMIO interfaces and interrupt handlers.
• RTOS-based firmware: FreeRTOS, VxWorks, and ThreadX images with task scheduling, shared-memory IPC, and hardware abstraction layers. Analysis challenges overlap MCU and Linux classes [13].
• UEFI/BIOS firmware: Platform firmware on x86 systems, structured as EFI modules, DXE drivers, and PEI modules. Targeted by advanced persistent threats; BootKit implants survive OS reinstallation [25,26].
• PLC/ICS firmware: Programmable logic controllers and industrial gateways with domain-specific instruction sets and fieldbuses. RE requires protocol and semantic recovery [6,7,27].
• Automotive ECU firmware: Multi-domain ECUs, AUTOSAR stacks, and CAN/LIN/Ethernet interfaces. Extraction is vendor-specific; multi-ECU interactions create cross-domain attack paths [5,28].

Table 2. Firmware class taxonomy: primary RE challenge, dominant technique, and representative tools or works.

Class	Primary RE Challenge	Dominant Technique	Representative Work
Linux-based IoT	Web interface attack surface; library debt	Full-system emulation; taint analysis	FIRMADYNE [12], Pandawan [29]
MCU bare-metal	Peripheral dependence; no OS	Peripheral modelling; coverage fuzzing	P2IM [14], Fuzzware [15]
RTOS	Task scheduling; shared-memory races	HAL emulation; symbolic execution	HALucinator [13]
UEFI/BIOS	Pre-OS execution; EFI module complexity	Interface fuzzing; bootloader analysis	FUZZUER [25], BootStomp [26]
PLC/ICS	Domain ISA; proprietary protocols	Semantic recovery; control invariants	ICSREF [6], ARES [27]
Automotive ECU	Vendor toolchains; CAN/LIN protocols	Protocol RE; binary similarity	[5,28]

summarises these classes along their primary RE challenges and representative tools.

2.2. The FRE Workflow

A complete firmware RE pipeline consists of six phases, which are not always linear—static analysis informs emulation targets, and fuzzing results guide deeper symbolic inspection:

• Acquisition and Unpacking: Obtaining the binary from device flash, update packages, or vendor portals, then identifying compression, encryption, and filesystem layouts (Section 3).
• Static Analysis: Disassembly, CFG recovery, symbolic execution, and binary code similarity detection (Section 4).
• Dynamic Analysis and Emulation: Re-hosting the binary in a controllable execution environment (Section 5).
• Fuzzing and Vulnerability Discovery: Generating inputs to trigger bugs and crashes (Section 6).
• AI/LLM-Assisted Analysis: Applying machine learning to accelerate labelling, decompilation, and triage (Section 7).
• Reporting and Exploitation: Validating findings, producing proof-of-concept exploits, and communicating results to vendors.

Figure 1 visualises these phases and their principal feedback paths.

2.3. Security Relevance for Smart Infrastructure

Smart infrastructure encompasses power grids, industrial gateways, transport control systems, medical devices, and connected vehicles. Each sector relies on embedded firmware whose security properties are difficult to verify without source code. The consequences of compromise extend beyond data theft: a vulnerable ICS controller can enable physical process manipulation [30], a compromised medical implant can threaten patient safety [31], and a hijacked smart-grid RTU can affect grid stability [7]. Firmware RE is the primary means by which researchers identify these risks, verify patch coverage, and guide secure-by-design improvements. Section 3 addresses the first practical challenge: obtaining and unpacking the firmware binary itself.

3. Firmware Acquisition and Unpacking

Firmware acquisition is the process of obtaining a complete binary image of the target firmware—whether from flash memory, vendor update portals, OTA traffic, or a running device’s memory. Unpacking refers to identifying and extracting the internal structure of that image: decompression layers, encryption wrappers, bootloader segments, and embedded filesystems. Together, acquisition and unpacking form the mandatory first stage of any firmware RE pipeline; without a usable binary, no subsequent static or dynamic analysis is possible. This phase transforms an opaque physical artefact into an accessible, structured representation from which individual software components can be analysed independently.

3.1. Hardware-Level Extraction

Hardware extraction methods directly access the storage medium or debug interfaces of the target device:

• JTAG/SWD boundary scan: IEEE 1149.1 [32] JTAG and ARM Serial Wire Debug interfaces provide low-level access to processor registers and memory, enabling both firmware dump and live debugging. Many production devices disable JTAG after manufacturing, but physical glitching or voltage-fault injection can sometimes re-enable it.
• UART serial console: Many embedded Linux devices expose a boot console on UART pins. Physical access to the PCB header pins provides a Linux shell from which filesystem contents can be read.
• Flash chip reading: SPI NOR/NAND, eMMC, and SD flash chips can be read using clip-on probes (in-circuit) or after desoldering (chip-off). The OWASP Firmware Security Testing Methodology (FSTM) documents this process [33].
• Side-channel and fault injection: For devices with read-protection fuses, fault-injection attacks—voltage glitching, clock glitching, electromagnetic pulse injection, and laser fault injection—can bypass read protection and dump protected flash. Bozzato et al. [34] demonstrate extraction from six commercial read-protected MCUs by optimising glitch waveforms with off-the-shelf equipment; Van den Herrewegen et al. [35] extend this with a grey-box methodology combining binary analysis with glitching to exploit bootloaders across multiple commercial MCU families. Complementary to fault injection, side-channel analysis—differential power analysis (DPA) and electromagnetic (EM) emanation analysis—recovers cryptographic keys from devices that encrypt their firmware storage. Camurati et al. [36] demonstrate that mixed-signal SoCs unintentionally leak AES key material through their radio transceivers as EM emissions, enabling remote key recovery without physical probing—a directly relevant attack path for encrypted IoT firmware.

3.2. Software-Level Extraction

Firmware is frequently obtainable without hardware access:

• Vendor update portals: Many vendors distribute firmware images publicly for manual update installation. Costin et al. [2] demonstrated large-scale harvesting by scraping 32,000 images from 42 vendors’ portals, enabling the first systematic security analysis at this scale.
• OTA packet capture: Devices that perform automatic updates over unencrypted channels (HTTP and plain TFTP) expose their firmware to a network-based man-in-the-middle. Encrypted channels require certificate pinning bypass or key extraction from the device’s trust store.
• Memory scraping from a running device: When a shell is available (via UART, SSH, or an exploited web interface), the /dev/mem interface or dd on the block device yields a complete firmware image from a live device.

3.3. Format Identification and Filesystem Extraction

Raw firmware images arrive as opaque byte sequences. Identification tools match known signatures, file system magic bytes, and entropy profiles to locate embedded components [33]:

• Binwalk [37] is the de facto standard tool for firmware format identification. It applies a database of magic byte signatures, entropy analysis, and recursive extraction to recover nested filesystems, compressed archives, and executable images from a single binary blob.
• Entropy analysis identifies compressed or encrypted regions: high, flat entropy indicates compression or encryption, while low-entropy regions indicate plaintext code or data. Regions with high entropy that do not match known compression formats signal possible encryption.
• Filesystem extraction: Common embedded filesystems include SquashFS (read-only, widely used in consumer routers), JFFS2 and YAFFS2 (flash-native, journalled), UBIFS (NAND-optimised), cramfs, and vendor-proprietary formats. Automated classification of images was addressed early by firmware-type identification approaches [38].

3.4. Encryption and Anti-Analysis

An increasing proportion of commercial firmware images are encrypted, particularly in automotive and industrial domains. Vendor-specific symmetric keys are often stored in device-bound secure elements, making offline decryption impossible without key extraction. Approaches include extracting decryption keys through JTAG or side-channel methods, intercepting plaintext images in memory after the device decrypts them at boot, or recovering keys from companion software (desktop update agents and mobile apps).

Beyond encryption, firmware vendors deploy obfuscation and anti-analysis countermeasures to impede reverse engineering. These include: custom packers that compress or scramble code sections (identifiable through entropy analysis or signature databases but requiring tool-specific unpacking logic); anti-disassembly sequences that exploit disassembler assumptions about instruction alignment or branch semantics to produce misleading CFGs; and control-flow flattening that transforms structured loops and conditionals into dispatcher-driven state machines, dramatically increasing manual analysis effort. Cyr et al. [39] demonstrate firmware obfuscation as a vendor defence against device cloning, illustrating that techniques deployed offensively against analysts have direct defensive analogues. Together, encryption and obfuscation represent a structural and growing barrier to independent firmware security research, identified as a gap in Section 11. With the binary accessible, Section 4 surveys the static analysis techniques applied to extract vulnerability signals without execution.

4. Static Analysis and Binary Code Similarity

Static analysis operates on firmware binaries without executing them, examining code structure, data flow, and program semantics directly from raw bytes. It encompasses disassembly, control flow graph (CFG) recovery, symbolic execution, taint tracking, and binary code similarity detection—each of which extracts meaningful information from a binary without requiring a running device or hardware access. Static analysis pursues three aims: identifying exploitable vulnerabilities through automated reasoning over all possible execution paths, recovering program semantics that aid human analysts, and detecting reused or known-vulnerable code across large firmware collections. It scales to thousands of images and applies even when dynamic execution is infeasible due to missing peripherals or encryption barriers.

Table 3. Core static analysis platforms used in firmware RE.

Tool	Primary Capability	Cross-Arch	Firmware RE
IDA Pro [40]	Disassembly; CFG; scripting	Yes	Commercial standard; IDAPython SDK widely used
Ghidra [41]	Disassembly; decompilation; binary diffing	Yes	NSA-released, open source; active plugin ecosystem
radare2 [42]	Disassembly; analysis; CLI/API	Yes	Scriptable; suited to pipeline automation
Binary Ninja	Disassembly; IL lifting; API	Yes	BNIL intermediate language; commercial
angr [43]	Symbolic execution; CFG recovery	Yes	Python API; dominant substrate for RE research tools

summarises the primary static analysis platforms used across the firmware RE literature.

The platforms in Table 3 divide into interactive workbenches (IDA Pro, Ghidra, Binary Ninja), optimised for a human analyst, and programmable frameworks (angr, radare2), optimised for building automated pipelines. The research systems surveyed in this review build almost exclusively on the programmable group plus Ghidra: open licensing and scriptability matter more for reproducible tooling than the maturity of IDA’s interactive analysis, and Ghidra’s decompiler supplies the pseudocode consumed by the LLM-assisted systems of Section 7. All five platforms also share a firmware-specific weakness: their automatic analysis assumes an identifiable entry point, loader metadata, and memory map. Monolithic MCU images provide none of these, so analysis of bare-metal firmware begins with manual or heuristic recovery of the load address and interrupt-vector table before any platform in the table becomes useful.

4.1. Disassembly and Control Flow Graph Recovery

Disassembly converts machine code bytes into human-readable assembly instructions; CFG recovery identifies the set of possible execution paths through the binary. Both are complicated in firmware by stripped symbol tables, indirect branches through function pointer tables, exception/interrupt-driven control transfers, and mixed Thumb/ARM encoding. Tools include IDA Pro [40] (the commercial standard), Ghidra [41] (NSA-released, open source), radare2 [42] (open-source CLI/API), and Binary Ninja.

FFXE [44] addresses CFG recovery for stripped embedded firmware by combining static analysis with selective concrete execution to resolve indirect branches that defeat purely static approaches. This is particularly important for MCU firmware where interrupt vector tables and peripheral-driven control flow dominate the structure.

4.2. Symbolic Execution

Symbolic execution replaces concrete input values with symbolic variables and explores feasible program paths, enabling reasoning about program behaviour across all inputs in a given class.

The angr framework [43] provides a Python platform for binary-level symbolic execution and has become the dominant substrate for firmware analysis tools requiring deep program reasoning. Firmalice [23] applied symbolic execution to detect authentication-bypass paths in binary firmware, combining program slicing with symbolic path exploration. FirmUSB [45] used domain-informed symbolic execution to vet USB device firmware, exploiting USB protocol constraints to prune infeasible paths and dramatically reduce analysis time. dAngr [46] extends angr with a debugger-level interface for interactive symbolic investigation.

Comparing these systems reveals a common precondition for success: symbolic execution scales on firmware only where a domain oracle prunes the state space. Firmalice slices the program to authentication-relevant paths, FirmUSB constrains exploration with USB protocol semantics, and Jetset (Section 5) steers execution towards a concrete boot target; absent such an oracle, environmental modelling and path explosion dominate [22]. The systems also differ in what they assume is available before analysis starts: Firmalice requires the authentication point to be identified, FirmUSB is specific to 8051-class USB firmware, and dAngr assumes an analyst in the loop. None of this line of work symbolically models interrupt-driven state machines—the control-flow idiom that dominates MCU firmware—which is precisely where the dynamic approaches of Section 5 take over.

4.3. Taint Analysis

Taint analysis tracks the propagation of potentially attacker-controlled data through a program, identifying where untrusted input can reach security-sensitive operations. FirmCross [47] detects taint-style vulnerabilities in C–Lua hybrid web services found in modern Linux-based IoT firmware, a class of interface not addressed by earlier taint trackers. Karonte [48] performs multi-binary taint analysis across inter-process communication boundaries, identifying vulnerabilities that require data to cross process boundaries before reaching a dangerous sink.

4.4. Heap and Memory Allocator Analysis

Dynamic memory corruption behaves differently in firmware than on desktop systems because the allocator itself is different. Monolithic firmware images rarely link a standard library such as glibc; a vendor instead compiles in a custom allocator or forks an open-source one—an RTOS heap, newlib malloc, or a stripped bespoke design—and ships it without symbols. These allocators store their bookkeeping metadata inline, next to the data they hand out, and omit the hardening that mainstream allocators added years ago: no safe unlinking; no heap cookies; and, in a single flat address space, no ASLR to separate the heap from code or peripheral registers. A linear overflow therefore writes straight into allocator metadata, and corrupting that metadata turns a bounded overflow into an arbitrary write. Desktop heap-analysis tooling assumes a known allocator with published internals and does not transfer to these targets.

HEAPSTER [49] addresses this gap. It first locates the heap-management code inside a stripped monolithic image, identifying the allocation and free routines through symbolic exploration rather than signature matching—inlined and forked code defeats fingerprints—and then models that allocator to check a set of heap-safety properties. The analysis surfaces heap overflows and use-after-free conditions, and because many vendors embed the same open-source allocator, a flaw found in one image often recurs unchanged across unrelated products. Two limits define the open problem. Allocator identification stays fragile: a vendor that rewrites the allocation interface or interleaves it with application logic can hide the heap from automated discovery. And the evaluated targets are almost entirely bare-metal monolithic firmware, a class this review shows to be under-served next to Linux-based IoT (Section 11); no shared, labelled corpus of firmware allocators yet exists to measure progress against.

4.5. Binary Code Similarity Detection

Binary Code Similarity Detection (BCSD) identifies reused, ported, or vulnerable code across firmware images without source code, enabling detection of known-vulnerable third-party libraries embedded in thousands of vendor images.

Gemini [50] introduced Attributed CFG (ACFG) embeddings via Siamese neural networks for cross-architecture similarity detection. $\alpha$Diff [51] extended this to cross-version detection using deep neural networks at module, function, and basic-block levels. FIT [52] combined deep learning with bipartite matching for cross-architecture vulnerability detection. More recent approaches apply graph contrastive learning on intermediate representations [53] and naming-function-based vector spaces [54]. IoTBec [55] applies recurring vulnerability detection across black-box IoT devices using binary similarity patterns learned from known-vulnerable code.

Table 4. Binary code similarity detection systems: comparison of architecture support, representation, and scope.

System	Representation	Cross-Arch	Primary Application
Gemini [50]	ACFG + Siamese NN	Yes	Firmware vuln search
$\alpha$Diff [51]	DNN (module/func/block)	Yes	Cross-version diffing
FIT [52]	DL + bipartite match	Yes	Cross-arch vuln detect
GCL on IRs [53]	Graph contrastive learning	Yes	General BCSD
Naming-based [54]	Common vector space	Yes	Function identification
IoTBec [55]	Pattern matching	Partial	Recurring IoT vulns

summarises key BCSD systems.

Across these systems a shared evaluation blind spot deserves emphasis. BCSD models are trained and tested on corpora compiled from open-source projects at known optimisation levels then deployed against vendor firmware built with unknown toolchains, aggressive inlining, and SDK forks—exactly the conditions that degrade similarity signals. Function-level matching additionally presupposes reliable function-boundary identification, which is itself unsolved for stripped monolithic images (Section 4, FFXE). Published accuracies should therefore be read as best-case: the deployment scenario the technique targets—locating a known-vulnerable library inside a stripped vendor image—is the setting its benchmarks least resemble. IoTBec’s black-box variant [55] sidesteps binary access entirely by matching interface-level behaviour, trading localisation precision for deployability on devices whose firmware cannot be extracted at all.

4.6. Protocol Reverse Engineering

Many firmware binaries implement proprietary or undocumented application-level protocols over standard transport layers. Protocol reverse engineering (PRE) infers message-format grammars and state machines from binary code or network traces without access to specifications. This is essential for fuzzing firmware network interfaces, understanding ICS/SCADA communication semantics, and identifying authentication weaknesses in proprietary update channels.

Caballero et al. [56] introduced the first dynamic binary analysis approach to automatically extract protocol message field boundaries from unknown application protocols. Lin et al. [57] extended this with context-aware monitored execution (AutoFormat), which recovers hierarchical message structure and field semantics from binary execution traces. Bossert et al. [58] present Netzob, which combines execution-trace semantics with clustering to infer both message formats and protocol state machines, enabling generation of valid protocol messages for subsequent fuzzing. PRE is particularly relevant to industrial firmware analysis, where proprietary fieldbuses (Modbus, PROFINET, and DNP3 variants) and vendor-specific update protocols represent under-documented attack surfaces.

4.7. Patch Diffing and Vulnerability Propagation

Patch diffing identifies code-level changes between successive binary versions of firmware to locate security-relevant modifications—revealing which functions were patched, what the pre-patch code contained, and whether the fix is complete or partial. This enables rapid exploit development against unpatched devices and cross-product vulnerability propagation analysis.

BinDiff [59] is the standard tool for structural binary comparison: it constructs call graphs and CFGs for both versions and matches functions using a graph-isomorphism heuristic, surfacing changed, added, and deleted functions across binary versions without source code. Brumley et al. [60] demonstrated that automatic patch-based exploit generation is practical—given a patched and unpatched binary pair, their system automatically generates a working exploit for the pre-patch vulnerability, quantifying the exposure window for devices awaiting firmware updates. In the firmware context, patch diffing is critical for supply-chain vulnerability analysis: when a vendor backports a CVE fix to one product line while neglecting others built on the same library, diffing reveals the gap before the CVE is publicly disclosed. Static analysis alone, however, cannot observe runtime behaviour; Section 5 addresses how firmware is executed in controlled environments to enable dynamic vulnerability discovery.

5. Firmware Emulation and Re-Hosting

Dynamic analysis requires executing firmware in a controllable environment to observe runtime behaviour, inject inputs, and detect faults that static analysis cannot reach. Since firmware is designed for specific hardware, executing it on commodity machines requires re-hosting: replacing or accurately modelling the hardware environment—processor peripherals, memory-mapped I/O, interrupt controllers, and bus interfaces—so that the firmware executes correctly outside its native context [10,24]. Emulation and re-hosting unlock coverage-guided fuzzing, symbolic exploration, and automated vulnerability scanning on firmware that cannot be safely or conveniently tested on physical hardware, enabling scalable dynamic analysis without device access.

5.1. Taxonomy of Re-Hosting Approaches

Wright et al. [24] classify re-hosting into five families: (1) full-system emulation, (2) process-level user-space emulation, (3) single-service emulation, (4) HAL-level abstraction, and (5) partial emulation with hardware-in-the-loop (HIL). These families trade execution fidelity against scalability and manual effort.

5.2. Full-System and Process-Level Emulation

FIRMADYNE [12] established the baseline for automated dynamic analysis of Linux-based IoT firmware using QEMU-based full-system emulation. Despite emulating 14,000 images and identifying web-interface vulnerabilities via automated network crawling, it fails to boot approximately 40% of collected images due to peripheral and kernel module dependencies.

FirmAE [11] improved this to approximately 79% boot success through five augmentation heuristics covering service emulation, inittab patching, and network initialisation. Pandawan [29] revisited Linux re-hosting with rigorous progress metrics that define what “successful” re-hosting actually means in terms of service reachability rather than mere boot completion.

Single-service approaches narrow the scope to improve fidelity: FirmSolo [61] specifically enables dynamic analysis of Linux kernel modules (LKMs) in firmware, a class of binary previously excluded from re-hosting pipelines. Greenhouse [62] achieves single-service user-space emulation by lifting individual firmware services into a host process, avoiding full-system boot dependencies while retaining per service analysis fidelity.

5.3. HAL-Level Emulation and Peripheral Modelling

For MCU and RTOS firmware, the dominant re-hosting challenge is hardware-peripheral dependence. Several complementary systems address different aspects:

• HALucinator [13] intercepts calls to hardware abstraction layer (HAL) functions and replaces them with library-level models, enabling MCU/RTOS firmware execution without hardware.
• P2IM [14] automatically models processor-peripheral interfaces (MMIO register behaviour) by observing access patterns during boot, without requiring manual peripheral specifications.
• Pretender [63] learns stateful peripheral models interactively through hardware trace replay.
• Fuzzware [15] uses constraint solving to determine how MMIO values influence control flow, concentrating fuzzing effort on semantically meaningful peripheral inputs and achieving 3.25× coverage improvement.
• Jetset [64] uses targeted symbolic execution to identify the MMIO values required for firmware to reach a specific execution target, enabling re-hosting of firmware that would otherwise halt at uninitialised peripheral reads.
• DICE [65] emulates DMA input channels, extending firmware fuzzing to DMA-driven code paths that MMIO-only approaches cannot reach, achieving 79× path coverage improvement on DMA-using firmware targets.
• GDMA [66] fully automates DMA re-hosting via iterative type overlays, resolving DMA descriptor layouts without manual annotation and substantially reducing the manual effort that DICE-style approaches require.
• Ember-IO [67] reduces dependence on handcrafted MMIO models through model-free memory-mapped IO handling, trading some precision for automation.
• PHI [68] identifies pseudo-HAL interfaces for scalable fuzzing without requiring complete HAL source coverage.
• DyMA-Fuzz [69] provides dynamic DMA abstraction for re-hosted monolithic firmware fuzzing, addressing DMA-dependent code paths in systems without explicit DMA drivers.

Viewed comparatively, these systems encode different assumptions about where hardware knowledge resides, and each assumption is also a failure mode. HALucinator locates it in HAL library signatures, so it degrades on statically linked, aggressively optimised, or vendor-custom HALs; P2IM assumes MMIO registers fall into generalisable behavioural categories, which stateful protocol peripherals violate; Pretender assumes hardware traces can be recorded, reintroducing the device dependence the others remove; Fuzzware assumes the MMIO bits that matter are those constraining control flow, which becomes expensive at checksum and cryptographic comparisons; and DICE and GDMA assume recognisable DMA descriptor idioms. Each system’s blind spot is another’s core case, which is the strongest evidence for the integration argument of Gap 2 (Section 11): the components of a general peripheral model exist, but they have never been composed.

5.4. Partial Emulation and Hardware-in-the-Loop

When full peripheral modelling is impractical, partial emulation forwards specific hardware accesses to real devices. Avatar² [70] provides a multi-target orchestration platform that forwards peripheral accesses to physical hardware while enabling symbolic execution of the remaining firmware logic. CO3 [71] applies concolic co-execution, combining symbolic path exploration with concrete execution to improve coverage on MCU firmware where pure fuzzing stalls. SHiFT [72] uses semi-hosted execution in which the real MCU handles peripheral interactions while a host-side fuzzer drives program inputs, combining hardware fidelity with fuzzer throughput.

5.5. Scalability vs. Fidelity

The re-hosting literature divides into two camps that have not yet been unified. Scalable systems (FIRMADYNE, FirmAE, and Pandawan) operate on thousands of Linux images but sacrifice execution realism for peripheral-dependent code paths. High-fidelity systems (HALucinator, Pretender, and Fuzzware) provide accurate execution for specific firmware classes but require per-target manual effort or narrow architecture assumptions. Neither camp generalises across all firmware classes relevant to smart infrastructure. This tension is identified as Gap 3 in Section 11. Figure 2 positions representative systems on these two axes.

Table 5. Firmware re-hosting systems: approach, primary target class, peripheral handling, and key evaluation metric.

System	Approach	Target Class	Key Metric
FIRMADYNE [12]	Full-system (QEMU)	Linux IoT	Boot rate, web crawl
FirmAE [11]	Full-system + heuristics	Linux IoT	79% boot success
Pandawan [29]	Full-system + measurement	Linux IoT	Service reachability
Greenhouse [62]	Single-service, user-space	Linux IoT	Per-service fidelity
FirmSolo [61]	Kernel module emulation	Linux IoT	LKM coverage
HALucinator [13]	HAL-level	MCU/RTOS	Function coverage
P2IM [14]	Peripheral interface modelling	MCU	Peripheral response accuracy
Fuzzware [15]	MMIO modelling + fuzzing	MCU	3.25× coverage
Jetset [64]	Targeted symbolic re-hosting	MCU	Execution target reach
DICE [65]	DMA channel emulation	MCU	79× path coverage
GDMA [66]	Automated DMA via type overlays	MCU	No manual annotation
Ember-IO [67]	Model-free MMIO	MCU	Crash count, CVEs
Pretender [63]	Learned peripheral models	MCU	Execution fidelity
Avatar2 [70]	Multi-target HIL	Any	Symbolic reach
CO3 [71]	Concolic co-execution	MCU	Branch coverage
SHiFT [72]	Semi-hosted fuzzing	MCU	Coverage, CVEs

summarises representative re-hosting systems.

Read by firmware class, Table 5 yields concrete selection guidance. For Linux-based IoT images, FIRMADYNE, FirmAE, and Pandawan re-host complete images at corpus scale, while Greenhouse and FirmSolo trade whole-image fidelity for higher success on a single service or kernel module. For monolithic MCU and RTOS firmware, HALucinator applies when the HAL library is identifiable; P2IM, Ember-IO, and Fuzzware infer MMIO behaviour without source or hardware access; and DICE and GDMA extend these models to DMA-driven peripherals. Pretender instead learns stateful peripheral models from recorded hardware interactions. Avatar², SHiFT, and CO3 require the physical device on the bench and suit targets whose peripherals resist modelling altogether. The practical decision sequence is therefore: firmware class first (Linux-based vs. monolithic), peripheral complexity second (MMIO-only vs. DMA-driven and stateful devices), and hardware availability last. Re-hosting enables execution; Section 6 shows how that execution environment is exploited for systematic vulnerability discovery through fuzzing.

6. Fuzzing and Dynamic Vulnerability Discovery

Fuzzing is an automated testing technique that generates large volumes of structured or semi-structured inputs to trigger unexpected behaviour—crashes, hangs, or memory-safety violations—in the target program. Coverage-guided greybox fuzzing, as implemented by AFL [73], instruments the binary to collect branch-coverage bitmaps and prioritises inputs that exercise new code paths, directing exploration towards uncovered firmware logic. Applying this approach to firmware requires overcoming the absence of an OS process model, blocked execution on unmodelled peripheral I/O, and the difficulty of restarting firmware state between test cases. Fuzzing discovers memory-safety bugs, logic errors, and exploitable crash conditions unreachable through static analysis alone, providing empirical evidence of vulnerability under realistic, input-driven execution.

6.1. Linux Firmware Fuzzing

FIRM-AFL [17] introduced augmented process emulation for Linux-based IoT firmware, running firmware services in QEMU user-mode while retaining the AFL coverage bitmap, enabling high-throughput greybox fuzzing of web and network-facing services. SAFIREFUZZ [74] further accelerates firmware fuzzing through re-hosting optimisations including selective instrumentation and state checkpointing, achieving throughput improvements over FIRM-AFL. FirmCorn [75] targets IoT firmware with vulnerability-oriented mutation strategies that guide test-case generation towards dangerous code regions.

6.2. MCU and Bare-Metal Firmware Fuzzing

Fuzzware [15] uses constraint solving to determine precisely how MMIO register values influence control flow, concentrating the fuzzer’s byte budget on semantically meaningful peripheral interactions. This approach discovered six new CVEs in industrial and medical device firmware. HOEDUR [76] extends this line by structuring fuzzer inputs as multiple typed streams aligned to peripheral channel semantics, yielding higher coverage on complex MCU firmware targets than single-stream mutation. MultiFuzz [16] extends coverage-guided fuzzing to monolithic MCU firmware with multiple concurrent input channels (interrupts, DMA, and MMIO), replacing the single-stream model assumed by AFL. SHiFT [72] uses semi-hosted execution to fuzz embedded applications with the real peripheral hardware in the loop, combining hardware fidelity with AFL-level throughput. FirmReBugger [77] provides a benchmark framework specifically designed for evaluating monolithic firmware fuzzers, enabling systematic comparison of coverage and bug-finding capabilities across the systems above.

6.3. Multi-Binary and Cross-Component Fuzzing

Karonte [48] identifies vulnerabilities that span multiple binaries within a firmware image by statically identifying shared-memory and environment-variable communication channels between processes, then applying taint analysis across boundaries. It discovered 47 new zero-day vulnerabilities across consumer routers. FirmCross [47] detects taint-style vulnerabilities in C–Lua hybrid web service architectures increasingly common in modern Linux-based firmware.

6.4. UEFI and Specialised Targets

FUZZUER [25] specifically targets UEFI EDK-2 interface functions, using reaching-definition and value-set analysis to auto-generate source-level harnesses for interface functions and drivers that execute before the OS and are unreachable from OS-level fuzzers. HEAPSTER [49] combines static analysis of allocator code with dynamic testing to detect heap vulnerabilities in monolithic firmware images without source code.

6.5. LLM-Assisted Fuzzing

FirmAgent [18] augments fuzzing with an LLM-based reasoning agent that interprets firmware structure, identifies semantically meaningful input constraints, and generates seed inputs that are more likely to reach deep program paths than random or mutation-based seeds. FirmAgent marks an early integration of agentic AI into firmware fuzzing, with measured improvements in path coverage and bug discovery rate.

Table 6. Firmware fuzzers: target class, peripheral handling, and primary outcome.

Fuzzer	Target	Peripheral Handling	Key Outcome
FIRM-AFL [17]	Linux IoT	Process emulation	Web vuln discovery
SAFIREFUZZ [74]	Linux IoT	Selective re-hosting	Throughput gains
FirmCorn [75]	IoT	Virtual execution	Targeted mutation
Fuzzware [15]	MCU	MMIO modelling	3.25× coverage; 6 CVEs
HOEDUR [76]	MCU	Multi-stream typed	Higher coverage
MultiFuzz [16]	MCU	Multi-stream	Monolithic firmware
SHiFT [72]	MCU	Semi-hosted (real HW)	High-fidelity testing
Ember-IO [67]	MCU	Model-free	No manual models
HEAPSTER [49]	Monolithic	N/A	Heap bugs
Karonte [48]	Linux multi-binary	N/A	47 zero-days
FirmCross [47]	Linux C–Lua	N/A	Hybrid service vulns
FUZZUER [25]	UEFI (EDK-2)	Generated harnesses	20 new vulnerabilities
FirmAgent [18]	Linux IoT	LLM-guided	140 new vulns, 17 CVEs
FirmReBugger [77]	Monolithic	Benchmark	Fuzzer comparison

summarises the key fuzzing systems.

The outcome column of Table 6 should not be read as a ranking: crash and CVE counts were obtained under different peripheral models, harness assumptions, triage procedures, and deduplication policies. Linux-hosted fuzzers inherit sanitisers and core-dump tooling from the host ecosystem, whereas monolithic MCU targets often lack even memory-protection faults, so what counts as a “crash” is itself defined by the execution model—liveness and sanitiser checks in Fuzzware and MultiFuzz versus hardware fault handlers in SHiFT. Throughput baselines likewise differ by orders of magnitude between full-system emulation and native semi-hosted execution. The only directly comparable numbers in this corpus come from the shared P2IM/Fuzzware benchmark lineage, on which MultiFuzz [16] reports strictly higher coverage than Fuzzware and Ember-IO on 14 of 23 real-world targets—an illustration of what standardised evaluation makes possible, and of how little of the field currently supports it (Gap 1).

Section 7 surveys how AI and LLMs are being integrated across these pipeline stages to automate analysis tasks that previously required expert manual effort.

7. AI-Driven Firmware Analysis

AI and machine learning automate firmware analysis tasks that previously required expert manual effort: classifying binary blobs, recovering function semantics from stripped code, and triaging large vulnerability candidate sets. Three application areas have matured malware classification and firmware type detection, decompilation quality improvement, and agentic reverse engineering where an LLM-driven system autonomously orchestrates analysis tools. Across all three, the aim is to scale analytical throughput beyond manual inspection, surface non-obvious vulnerabilities through learned pattern recognition, and lower the expertise barrier for analysts working with unfamiliar architectures or obfuscated code. Each area is assessed below, including where the gap between current capability and firmware-specific requirements remains large. Figure 3 shows where AI/LLM tools enter the FRE pipeline.

7.1. ML-Based Malware Detection and Firmware Classification

Machine learning enters firmware analysis at the coarsest granularity: deciding what a binary blob is before any structural analysis is possible. Early supervised classifiers [78,79] cast firmware-type identification and malware detection as classification over features extracted directly from the raw image—byte-entropy profiles, opcode n-gram histograms, string and import tables, syscall or API sequences, and control-flow-graph embeddings. Entropy and n-gram features are cheap and architecture-agnostic, which is why they dominate large-scale triage, but they are also the features most easily defeated: a packed or encrypted region raises entropy uniformly and flattens the opcode distribution the classifier depends on, so the same compression that hampers unpacking (Section 3) simultaneously blinds ML triage.

Three weaknesses limit how far these results transfer to deployed firmware. First, label scarcity and class imbalance: confirmed malicious firmware is rare relative to benign images, so headline accuracies are inflated by the majority class and conceal poor recall on the categories that matter. The systematic evaluation of [80] across seven IoT malware categories—ransomware, rootkits, trojans, botnets, worms, viruses, and keyloggers—finds that model ranking is unstable across categories and feature sets, meaning no single detector generalises. Second, concept drift: a classifier trained on one firmware generation decays as vendors change toolchains, SDKs, and packers, yet no standard protocol exists for measuring this decay over time, a specific instance of the dataset gap of Section 11 (Gap 8). Third, obfuscation: both vendor anti-cloning obfuscation and adversarial packing distort the static features these models consume. AI-augmented deobfuscation [81] pairs LLM reasoning with static analysis to partially recover obfuscated logic before classification, but it inherits the grounding and hallucination problems analysed in Section 7.4.

7.2. LLM-Assisted Decompilation

Decompilation maps binary code back to a higher-level representation (typically pseudo-C), enabling human analysis without assembly expertise. Recent LLM-based approaches have measurably advanced decompilation quality:

• LLM4Decompile [20] fine-tunes large language models on binary–source function pairs and outperforms Ghidra’s decompiler on recompilability metrics, indicating better type and structure recovery.
• DecLLM [19] augments the decompilation pipeline with an LLM-based refinement stage, improving both recompilability and readability of generated pseudo-C.
• SK²Decompile [82] introduces a two-phase approach: a skeleton recovery phase that identifies function structure, followed by a skin refinement phase that fills in variable semantics and naming. The separation reduces hallucination by constraining the LLM’s creative freedom to semantically plausible completions.

Benchmark infrastructure is maturing: Decompile-Bench [83] provides million-scale binary–source function pairs for systematic LLM evaluation. These datasets remain predominantly compiled from well-known open-source C projects, not from actual firmware images.

7.3. Agentic and LLM-Driven Reverse Engineering

Beyond decompilation, recent work positions LLMs as autonomous agents that plan multi-step reverse engineering tasks. FirmAgent [18] combines LLM reasoning with firmware fuzzing: fuzzing first identifies runtime input points, an LLM agent then performs context-aware taint analysis along candidate vulnerability paths, and a second agent refines fuzzing-generated testcases into proof-of-concept inputs, reporting 140 previously unknown vulnerabilities and 17 CVEs across 14 real-world firmware images at 91% precision. Challenges and future directions in agentic RE systems are surveyed in [84], identifying hallucination management, context-window limitations, tool integration, and reproducibility as the primary unsolved problems.

IoTBec [55] pursues the same automation goal from the opposite direction, treating the device as a black box and searching for vulnerabilities that recur across a population rather than reasoning about one image in depth. It learns binary-similarity patterns from known-vulnerable code and matches them against firmware drawn from large vendor populations, so a flawed third-party library version can be flagged across hundreds of unrelated products without device-by-device manual analysis. This attacks the N-day propagation problem directly: a single vulnerable component, such as an outdated TLS stack, a reused web server, or a shared vendor SDK, often ships unchanged across an entire market segment, and manual triage cannot keep pace with that fan-out. The approach inherits the limits of similarity matching, however. It recognises code that stays close to a known-vulnerable seed and can miss the same flaw once a vendor recompiles for a different architecture or refactors the surrounding function, the failure mode the cross-architecture systems in Table 4 aim to reduce.

The evidence status of these systems differs and should be read accordingly. LLM4Decompile [20] (EMNLP 2024) and DecLLM [19] (ACM FSE 2025) are peer-reviewed but evaluated on generic compiled binaries, not firmware images; SK²Decompile [82] is a preprint-stage system whose results await peer review; and FirmAgent [18] and IoTBec [55] are peer-reviewed (NDSS 2026) and are the only two systems in this group evaluated end-to-end on real firmware, though without public artefacts or independent replication (Section 11.1).

7.4. Limitations and Firmware-Specific Challenges

The AI/LLM literature surveyed above is the least mature tier of this review’s corpus (Section 11.1), and its limitations fall into five groups.

7.4.1. Benchmark Grounding

Most evaluations target generic x86 binaries compiled from well-documented open-source codebases; firmware-specific artefacts—MMIO semantics, interrupt-driven control flow, vendor SDK idioms, packed or encrypted images, and cross-architecture code reuse—are absent from benchmarks. Even within generic decompilation, independent empirical evaluation shows that recompilability does not imply functional equivalence: CODEFUSE-DEBENCH [85] finds that decompiled functions which recompile cleanly frequently fail functionality tests, a distinction that recompilability-based leaderboards obscure.

7.4.2. Benchmark Leakage

Because LLMs are trained on public source code, evaluation sets compiled from open-source projects risk contamination: a model may reproduce memorised source rather than analyse the binary presented to it. Contamination-resistant evaluation methodologies exist for source-level code tasks [86] but have no firmware equivalent, so decompilation scores on GitHub-derived function pairs such as Decompile-Bench [83] should be read as upper bounds. Firmware sharpens the problem in both directions: widely reused embedded components (FreeRTOS, lwIP, and vendor HALs) are certainly in training corpora, inflating apparent recovery of library code, while proprietary application logic—the code an analyst actually needs recovered—is not. Architecture mismatch compounds this: training data skews towards x86-64 and AArch64, whereas deployed firmware spans ARMv7-M, MIPS, Xtensa, RISC-V, and proprietary ISAs for which paired binary–source data is scarce.

7.4.3. Hallucination

Hallucination is well characterised for LLMs in general [87], and decompilation exhibits a domain-specific form: plausible but incorrect type assignments, variable semantics, and control-flow reconstructions that a human reviewer cannot distinguish from correct output without ground truth. SK²Decompile’s phase separation [82] reduces but does not eliminate this failure mode. No surveyed work reports a hallucination rate measured on firmware binaries.

7.4.4. Exploit-Validation Reliability

The two systems that close the loop from LLM reasoning to concrete security findings report strong self-evaluated numbers—91% PoC precision for FirmAgent [18], 100% precision and 93.4% recall for IoTBec [55]—but artefact availability is partial or absent (Section 11.1) and no independent replication exists. Execution-based validation of every LLM-produced finding, rather than reviewer- or model-graded assessment, should be the minimum evidentiary standard for this line of work.

7.4.5. Cost and Reproducibility

Per-function inference against frontier models is prohibitive at the scale of firmware images with thousands of functions; model-version drift makes results unstable across time; and agentic pipelines lack persistent memory across analysis sessions. The survey in [84] identifies hallucination management, context-window limits, tool integration, and reproducibility as the field’s primary unsolved problems. These issues ground Gap 7 (Section 11).

8. Applications: Smart Infrastructure Case Studies

Smart infrastructure encompasses the embedded computing systems that underpin critical services: consumer IoT devices, automotive electronic control units (ECUs), industrial control systems (ICS) and programmable logic controllers (PLCs), medical devices, and smart-grid components. Each domain combines strict safety and reliability requirements with firmware that is rarely designed with adversarial analysis in mind, creating high-consequence attack surfaces. Applying FRE to these domains identifies exploitable vulnerabilities before adversaries do, verifies patch coverage across deployed fleets, and provides evidence-based guidance for secure-by-design improvements. The subsections below cover proven achievements and the coverage gaps that persist.

8.1. Consumer IoT at Scale

Consumer IoT is the most thoroughly studied firmware class because its Linux userland, extractable filesystems, and web interfaces make large-scale collection and static analysis tractable. Costin et al. [2] performed the first study at scale, scraping 32,000 firmware images from 42 vendors, unpacking them with signature- and entropy-based carving, and running static checks for hard-coded credentials, private keys, and known-vulnerable library versions. The methodological step that separates this from per-device auditing is cross-image correlation: the same self-signed TLS certificates, SSH host keys, and password hashes recur across images from unrelated vendors, so a single extracted secret compromises an entire population of devices rather than one product. This shared-artefact effect is the empirical basis for the recurring-vulnerability mining direction of Section 12. More recent large-scale measurement [3] shows the pattern has not improved: roughly 70% of sampled devices ship software with publicly disclosed CVEs, and the same third-party components carry the same flaws across vendors and product lines because firmware is assembled from shared vendor SDKs and reference designs that are seldom re-audited downstream.

8.2. Automotive ECU Firmware

Automotive ECU firmware combines a hostile extraction environment with safety-critical consequences. The functional interfaces are standardised—CAN and LIN buses, the UDS diagnostic protocol (ISO 14229 [88]) layered over them, and increasingly automotive Ethernet—but the security of those interfaces depends on firmware internals that are deliberately hard to obtain. UDS security access (service 0x27) gates flashing and privileged diagnostics behind a seed–key challenge–response whose key algorithm is embedded in the ECU firmware; recovering that algorithm by reverse engineering directly enables unauthorised reflashing through the request-download/transfer services (0x34–0x36). Extraction is the bottleneck: production ECUs use read-protected microcontrollers, encrypted flash containers, and disabled debug ports, which is why automotive RE pipelines rely on the fault-injection and side-channel techniques of Section 3 to obtain the initial image [5,28]. Because CAN itself carries no message authentication, a single compromised ECU can spoof arbitrary bus traffic, so AUTOSAR Secure Onboard Communication and signed OTA frameworks such as Uptane become the last line of defence, and validating their guarantees is precisely a firmware-RE task [89]. Tier-1 supplier component reuse then propagates any recovered weakness across vehicle platforms, mirroring the shared-artefact effect seen in consumer IoT.

8.3. Industrial Control Systems and PLC Firmware

Industrial controllers pose a different problem: the code is small, but its meaning is tied to a physical process the binary never describes. ICSREF [6] addresses the first half by fingerprinting functions in stripped CODESYS-based PLC binaries against a library of known runtime routines, reconstructing the call graph and, to demonstrate the stakes, automatically generating a malicious payload that rewrites control parameters on a real device. ARES [27] addresses the second half, recovering the physical semantics of PLC program variables by correlating them with control-flow invariants derived from process physics, so that an analyst can distinguish a setpoint from a sensor reading without engineering documentation. That semantic recovery is the precondition for the attack class Klick et al. [30] demonstrated on Siemens PLCs, where a firmware modification covertly manipulates the physical process while reporting normal values to operators—the Stuxnet threat model generalised beyond a single target. Survey coverage of the underlying protocol-RE problem, across Modbus, PROFINET, and DNP3 variants, is given in [90].

8.4. Medical Device Firmware

Medical embedded devices—pacemakers, insulin pumps, and implantable cardiac defibrillators—communicate over proprietary RF protocols in the MICS and ISM bands, frequently with weak or absent authentication and unencrypted telemetry. The systematisation of Rushanan et al. [31] organises the resulting attack surface into telemetry interception, command replay and forgery over the RF update channel, battery-depletion denial of service, and direct safety manipulation and shows that most of these reduce to firmware-level trust assumptions that reverse engineering can test. The class is distinctive because the properties that raise the safety stakes also obstruct analysis: FDA premarket controls treat firmware modification as a regulated change, enclosures are potted and omit debug headers, and the RF protocols are undocumented. The result is a domain where the consequences of compromise are highest and the published RE coverage is thinnest—a mismatch this review flags as Gap 10 (Section 11).

8.5. Smart Grid and Critical Energy Infrastructure

Smart-grid firmware runs in remote terminal units, intelligent electronic devices (IEDs), smart meters, and substation gateways, where it drives protection relays, metering, and SCADA communication over IEC 61850 [91]. The protocols are themselves part of the attack surface: GOOSE, the layer-2 event-signalling protocol used for protection tripping, carries no authentication in its base specification, so firmware that trusts GOOSE frames will act on forged ones, while MMS reporting can be manipulated to mask the effect. Reverse engineering protection-relay firmware is how researchers establish whether a given IED validates these messages at all. The systemic risk is not confined to the substation: Soltan et al. [92] show that a botnet of high-wattage consumer IoT devices—each running vulnerable firmware—can synchronously switch load to manipulate aggregate demand and destabilise the bulk power grid, so a firmware weakness in a domestic appliance becomes a grid-stability problem. The broader ICS cybersecurity landscape, including firmware-level attack paths, is mapped in [7]; detailed RE methodology for IEC 61850 IEDs and protection relays remains underpublished (Gap 10, Section 11).

These device classes call for different firmware-acquisition routes, and each route exposes a different slice of the trust surface. Protection IEDs and bay controllers ship as vendor-locked embedded systems whose firmware arrives as signed update packages or sits in on-board flash reachable over JTAG once the enclosure is opened; RTUs and substation gateways run richer real-time operating systems and expose engineering-access services an analyst can interrogate; advanced-metering-infrastructure meters pair a sealed metrology core with a communications module read over an optical ANSI C12.18 port or an RF neighbourhood-area link. Disassembling the recovered image is what reveals which protocol checks the device performs in practice. The IEC 61850 stack presents three separate targets: GOOSE for fast protection tripping, Sampled Values for digitised current and voltage, and MMS for reporting and control. None authenticates its sender in the base profile, and operators frequently leave the optional IEC 62351 [93] profile that would add message authentication and TLS disabled to hold down latency and preserve interoperability, so the firmware becomes the sole place the trust decision is enforced. Legacy RTUs speak DNP3 and Modbus, which carry control writes in clear text unless DNP3 Secure Authentication is compiled in and switched on; metering stacks speak DLMS/COSEM or ANSI C12.22, where key handling and firmware signing follow per-vendor choices that only firmware analysis can confirm.

The two attacks on the Ukrainian grid show these mechanisms in operation. In December 2015, after stealing operator credentials, the intruders issued breaker-open commands through the distribution management system and then overwrote the firmware of the serial-to-Ethernet converters at the substations, bricking the devices and forcing operators to restore service by hand for hours [94]. The following year the Industroyer malware automated the electrical attack: it carried interchangeable payloads for IEC 61850 MMS, IEC 60870-5-101 [95] and -104 [96], and OPC DA; enumerated the protection devices; and drove breaker operations without an operator, while a separate module abused a denial-of-service flaw in a specific protection-relay firmware to keep the relay from responding [97]. Both campaigns turned on the assumptions named above: unauthenticated control protocols and modifiable device firmware. They also mark the coverage gap this review flags, since what the community learned about these relays’ firmware came from post-incident response rather than from the systematic reverse engineering that could have surfaced the weaknesses beforehand.

The system-level consequences of firmware compromise in this domain extend well beyond the compromised device. A manipulated protection relay or RTU becomes a platform for malicious control commands and false data injection into state estimation, which can cascade into protection mistrips, line overloads, and forced load shedding; because substation communication equipment is itself grid-powered, failures propagate across the power–communication interdependence in both directions. Recent power-system research models this coupling quantitatively. Kong et al. [98] built a resilience-evaluation framework that computes the probability that a cyber attack succeeds against each circuit breaker, using a Markov node-transition model of the attack graph, and then feeds that probability into an optimal DC load-reduction model to quantify the resulting loss of load and score system resilience. The device-level event they treat probabilistically—a successful intrusion into breaker-controlling equipment—is precisely a firmware trust failure.

Du et al. [99] treat the firmware-resident device as the entry vector for a coordinated attack. They model an adversary that disrupts power and communication assets at once—the capability that compromised relay or RTU firmware confers—and derive a distributionally robust resilience-enhancement strategy that hardens the grid against the worst-case attack while the attacker’s resources remain uncertain, characterising that uncertainty with a Wasserstein ambiguity set and allocating control centres over the coupled network. Their formulation makes the power–communication interdependence explicit, and it rests on an assumption firmware reverse engineering can test: that specific field devices execute their firmware faithfully. FRE supplies the missing device-level evidence—whether deployed IED and RTU firmware authenticates GOOSE and MMS traffic, validates setpoints, and resists unauthorised reflashing—that these grid-resilience and hardening models take as an input. Yet no surveyed FRE study feeds its findings into such a model, and no resilience study grounds its trust assumptions in measured firmware behaviour. We revisit that gap between device-level analysis and system-level modelling as Gap 10.

Table 7. Firmware RE in smart infrastructure: domain, attack surface, primary technique, and representative work.

Domain	Attack Surface	Primary Technique	Key Work
Consumer IoT	Web, UPnP, Telnet	Emulation, taint analysis	[2,3]
Automotive ECU	CAN/UDS, OBD-II, OTA	Protocol RE, extraction	[5,28]
ICS/PLC	Fieldbus, ladder logic	Semantic recovery, symex	[6,27]
Medical devices	RF update channel	Static analysis, protocol RE	[31]
Smart grid	IEC 61850, SCADA GW	Protocol analysis, firmware patch	[7]
UEFI/Platform	EFI interfaces, DXE, Secure Boot	Interface fuzzing	[25,26]

maps infrastructure domains to RE techniques and representative work.

9. Digital Twins and Firmware Security

A digital twin (DT) is a real-time, synchronised virtual model of a physical system or asset [100,101]. Originally developed for manufacturing quality assurance, DTs are now actively used in cyber-physical systems (CPSs) and IoT security as a mechanism for continuous monitoring, attack simulation, and pre-deployment testing without risk to operational infrastructure. In the context of firmware security, a DT extends re-hosting beyond single-device analysis to replicate the full operational environment—including network topology, inter-device communication, and physical process dynamics. A DT provides a safe, controllable virtual environment where firmware vulnerabilities can be exercised, attack scenarios played out, and runtime deviations used to infer potential compromise in the physical counterpart, enabling security testing, threat modelling, and anomaly detection at infrastructure scale.

9.1. Digital Twin Concepts for Embedded Security

The core premise is that a high-fidelity virtual replica enables security analysis—including vulnerability testing, attack scenario simulation, and anomaly detection—that would be unsafe, impractical, or prohibitively expensive to conduct on live operational assets. The DT maintains synchronisation with the physical twin through sensor data, telemetry streams, and update channels, allowing the virtual model to reflect the current state of the physical device [102,103].

From a security perspective, DTs serve two distinct roles. First, proactive security assessment: the virtual replica hosts penetration testing, fuzzing, and symbolic analysis without risk of disrupting the operational system. This is directly analogous to the re-hosting techniques of Section 5, applied at the infrastructure level rather than the chip level. Second, reactive anomaly detection: divergence between the DT’s predicted state and the physical device’s observed state signals potential compromise or malfunction.

9.2. Firmware-in-the-Loop Testing via Digital Twins

Firmware-in-the-loop (FIL) testing executes firmware against a simulated physical process rather than hardware, enabling high-throughput security testing with realistic environmental inputs. This extends the emulation techniques of Section 5 by coupling firmware execution to a physics-based process simulator. The advantages are measurable: hardware faults can be injected at will, execution can be rewound and replayed, and coverage feedback from the firmware can guide simulation of adversarial process states.

Eckhart and Ekelhart [104] propose a specification-based approach in which expected device behaviour is formally specified in the DT; deviations detected in firmware execution traces constitute security incidents. Applied to ICS firmware, this enables detection of covert manipulation of control logic that does not appear in network traffic [102].

A concrete firmware-in-the-loop pipeline for a PLC target illustrates the integration this section argues for. The analyst extracts the control firmware from a CODESYS-based PLC and applies the static techniques of Section 4: ICSREF recovers the control functions and library-call structure from the binary [6], and control-invariant analysis maps binary variables to physical quantities such as pressure setpoints and valve states [27]. The re-hosted firmware is then coupled to a simulated process—for example, a pressurised-tank control loop whose simulated sensor values feed the firmware’s inputs and whose actuator states respond to its outputs—while a fuzzer drives the fieldbus and engineering-protocol interfaces. The digital twin’s security signal is divergence: the specification-based twin encodes the expected relationship between sensor readings and commanded actuator states [104], and any firmware execution that violates it—a setpoint silently altered, a safety interlock skipped—is flagged as a security incident even when the manipulation never appears in network traffic [102].

9.3. Threat Modelling and Attack Simulation

DTs enable systematic threat modelling by providing a stable, repeatable environment for adversarial simulation. Attackers can be modelled as agents that interact with the DT through all available firmware interfaces (network, UART, RF, and update channel), and the DT records the resulting state changes, coverage paths, and anomaly signals. This approach has been applied to smart-home devices and ICS gateways [104], where the DT serves as a structured alternative to uncoordinated penetration testing.

9.4. Challenges and Integration with FRE

The principal challenge for DT-based firmware security is the fidelity gap: the accuracy of security assessments is limited by how faithfully the DT models the physical process and the firmware’s hardware interactions. This is the same fundamental scalability–fidelity tension identified in re-hosting (Gap 3, Section 11). A firmware image running against an inaccurate process model may pass all security tests in the DT while harbouring vulnerabilities that only manifest in the physical device.

A second gap is integration: current FRE pipelines and DT platforms are developed independently, with no standard interface for feeding firmware analysis results (identified peripherals, discovered attack surfaces, and extracted interfaces) into DT models. Bridging this gap would allow FRE-derived knowledge to continuously improve DT fidelity and reduce the effort required to construct accurate virtual environments for new device types.

10. Secure Boot, TEE, and OTA Update Security

Device trustworthiness depends on three interlocking mechanisms: secure boot establishes a cryptographic chain from an immutable hardware root of trust to the running firmware; trusted execution environments (TEEs) isolate sensitive operations from the general firmware stack; and over-the-air (OTA) update systems deliver authenticated firmware patches across the device lifecycle. These mechanisms share a common security dependency: each relies on cryptographic material and runtime invariants that are undermined if the firmware itself can be compromised or modified without detection. Analysing these mechanisms through firmware RE verifies whether the cryptographic trust chain holds in practice, identifying bypass vulnerabilities, implementation flaws, and attack paths that allow an adversary to execute unauthorised code, extract keys, or persist malicious firmware modifications despite trust-chain protections.

10.1. Secure Boot and Bootloader Analysis

Secure boot establishes a cryptographic chain of trust from an immutable root (typically a hardware security element or fused key) to the operating system. Violations include rollback attacks (downgrading to a known-vulnerable signed version), signature bypass via fault injection—demonstrated against production ARM SoCs by Timmers and Spruyt [105] and extended to full privilege escalation on embedded Linux by Timmers and Mune [106]—and DMA attacks before IOMMU initialisation.

BootStomp [26] applies symbolic execution and taint analysis to Android bootloader firmware, detecting authentication bypass and privilege escalation vulnerabilities. It discovered four previously unknown vulnerabilities in production bootloaders by combining forward symbolic execution with backward dataflow analysis. FUZZUER [25] demonstrates systematic coverage-guided fuzzing of UEFI EDK-2 interface functions and drivers, automatically generating harnesses for pre-OS interface code that is outside the reach of OS-level security tools, and reporting 20 new vulnerabilities. The UEFI threat landscape, including BootKit implants and DXE module vulnerabilities, is surveyed in [107] and guidance is provided in [108].

10.2. Trusted Execution Environments

TrustZone-assisted TEEs isolate security-sensitive code (key storage, biometric processing, and DRM) from the Normal World OS. The SoK by Cerdeira et al. [109] systematically catalogues TEE vulnerability classes: confused-deputy attacks through the SMC interface, information leakage through shared memory, and insecure inter-world communication. A broader survey of TEE (in)security [110] covers TrustZone, Intel SGX, AMD SEV, and RISC-V PMP-based isolation.

Attacks on devices that lack hardware memory protection for the Secure World demonstrate the gap between the ARM TrustZone specification and its implementation in IoT-grade SoCs [111,112]. EL3XIR [113] takes a systematic fuzzing approach to COTS secure monitors (EL3 firmware on ARM platforms), discovering vulnerabilities in the most privileged firmware layer across several commercial TEE implementations.

10.3. Hardware Trojan Detection

Hardware trojans are malicious modifications to the silicon or SoC design layer that may activate under specific conditions to exfiltrate data or alter device behaviour. ML-based detection using circuit-level features and side-channel measurements is surveyed [114,115]. Runtime side-channel analysis combined with ML provides non-destructive detection on deployed devices [116]. Cost-efficient deep-learning detection for practical deployment has been proposed [117], and explainability methods improve the interpretability of detection models [118].

10.4. OTA Update Security

OTA update mechanisms are both a critical management channel (enabling remote patch delivery) and a primary attack surface. Core security requirements—authenticity, integrity, freshness (anti-rollback), and confidentiality—are frequently violated in production devices. Surveys document the full range of OTA attack classes: man-in-the-middle interception, rollback to signed but vulnerable images, and image forgery via weak signature schemes [119,120,121].

Wu et al. [122] performed a systematic empirical study of OTA update delivery in consumer IoT devices, finding widespread absence of server-side signature verification, lack of anti-rollback enforcement, and insecure default update channels. Automotive OTA security, including the Uptane framework and multi-ECU update coordination, is covered in [89].

From a reverse engineering perspective, the update pipeline itself represents an analysis target: update agents contain trust-verification code, differential patching logic, and recovery partition management. Reverse engineering these components enables validation of claimed security properties, identification of implementation flaws in signing workflows, and discovery of rollback-resistance bypasses. This end-to-end integration of firmware RE with update security analysis is identified as Gap 9 in Section 11.

10.5. Firmware Rootkit and Implant Detection

A compromised firmware image may contain persistent implants that survive reboots, OS reinstallation, and factory resets. Detecting such implants requires integrity verification against a known-good baseline—a process that itself depends on firmware RE to establish what a legitimate firmware binary should contain.

Cui et al. [123] demonstrate that adversary-injected firmware modifications in networked embedded devices (IP phones, printers) can silently persist, exfiltrate data, and pivot the network, establishing the concrete threat model for firmware-level implant attacks on smart infrastructure. Butterworth et al. [124] identify flaws in BIOS measurement mechanisms that allow firmware-level rootkits to evade TPM-based attestation and propose timing-based detection to restore root-of-trust integrity. Both works underscore that firmware integrity validation requires more than cryptographic chain-of-trust checks: binary-level analysis of firmware content is necessary to detect semantic implants that carry valid signatures obtained by compromising the signing infrastructure or inserting modifications before signing occurs.

11. Open Challenges

The following ten structural gaps represent the field’s principal unresolved challenges. Each gap is derived from, and quantified against, the corpus of 78 primary studies characterised in Section 1.3 and the maturity assessment of Section 11.1.

11.1. Maturity of the Evidence Base

Before enumerating structural gaps, it is necessary to weigh the evidence base itself: the surveyed systems differ sharply in reproducibility and evaluation strength, and a review that lists them side by side without qualification would give a weak prototype the same apparent weight as an artefact-evaluated system.

Table 8. Maturity assessment of representative primary systems. Corpus scale: S < 10, M 10–1000, L > 1000 targets. RD = real-device validation; BR = benchmark reuse from prior work.

System	Pipeline Stage	Artefacts	Corpus	RD	BR
Costin et al. [2]	Acquisition + static	Partial	L	No	No
FIRMADYNE [12]	Re-hosting	Full	L	No	No a
FirmAE [11]	Re-hosting	Full	L	No	Yes
Greenhouse [62]	Re-hosting	Full	L	No	Yes
Pandawan [29]	Re-hosting	Full	L	No	Yes
HALucinator [13]	Re-hosting	Full	M	Partial	No a
P2IM [14]	Re-hosting	Full	M	Yes	No a
Fuzzware [15]	Re-hosting + fuzzing	Full	M	No	Yes
DICE [65]	Re-hosting	Full	M	No	Yes
Ember-IO [67]	Re-hosting + fuzzing	Full	M	No	Yes
MultiFuzz [16]	Fuzzing	Full	M	No	Yes
SHiFT [72]	Fuzzing	Full	M	Yes	Partial
FIRM-AFL [17]	Fuzzing	Full	M	No	Yes
Karonte [48]	Static (multi-binary)	Full	M	No	No
HEAPSTER [49]	Static (heap)	Full	M	No	No
Firmalice [23]	Static (symbolic)	Partial	S	Yes	No
FUZZUER [25]	Fuzzing (UEFI)	Full	M	n/a	No
FirmAgent [18]	AI-assisted fuzzing	None	M	No	No
IoTBec [55]	AI-assisted black-box	Partial	M	Yes	No
LLM4Decompile [20]	AI decompilation	Full	M	n/a	Yes

^a These systems released corpora or peripheral benchmarks that later work adopted; they are benchmark creators rather than reusers.

therefore assesses representative primary systems along four dimensions: artefact availability (public code and data: full, partial/promised, or none found), evaluation corpus scale (small < 10 targets, medium 10–1000, large > 1000), real-device validation (whether results are confirmed against physical hardware rather than emulation alone), and benchmark reuse (whether evaluation uses a benchmark shared with prior work, enabling direct comparison).

Three patterns emerge. First, the MCU re-hosting and fuzzing community has converged on shared benchmarks (the P2IM unit tests and firmware set, later extended by Fuzzware), giving that subfield the strongest comparability; Linux-scale re-hosting relies on corpus reuse (FIRMADYNE-derived image sets) but not on shared success metrics. Second, real-device validation is rare everywhere: most systems validate within the emulator that produced their results, a circularity that Section 11 returns to as Gap 1 and Gap 6. Third, the AI-assisted systems are the least mature tier of the corpus: artefact availability is partial or absent, corpora are small and ad hoc, and no shared firmware-specific benchmark yet exists. The gap analysis below weights these tiers accordingly—claims supported only by early-stage prototypes are identified as such. Threat-model clarity follows the same gradient: symbolic and multi-binary analyses aimed at concrete attack classes (authentication bypass in Firmalice [23], cross-binary taint in Karonte [48], bootloader compromise in BootStomp [26]) state explicit attacker capabilities, whereas most emulation and fuzzing papers leave the attacker implicit, reporting crashes without a reachability argument.

11.2. Gap 1: Absence of Unified Evaluation Benchmarks

Existing tools are evaluated on heterogeneous firmware corpora with incompatible metrics: re-hosting success rate, basic-block coverage, crash count, CVE count, precision/recall on narrow bug classes, or recompilability score for decompilation. Direct comparison across the pipeline stages—from unpacking through exploit validation—is therefore impossible. Even within the re-hosting sub-field, Pandawan [29] shows that different definitions of “boot success” lead to incomparable claimed improvement rates. The problem is quantifiable within this corpus: the 16 re-hosting systems of Table 5 report at least nine distinct primary success metrics, the 14 fuzzers of Table 6 report outcomes ranging from raw throughput to CVE counts, and only nine of the 20 systems assessed in Table 8 reuse any benchmark from prior work.

Research opportunity: A reproducible benchmark and scorecard for FRE pipelines spanning unpack success, component identification, re-hosting fidelity, input-surface recovery, vulnerability yield, and PoC validation, with firmware classes drawn from across the taxonomy of Section 2. Some pieces already exist and are reused (the P2IM unit tests, FIRMADYNE-derived image sets), but none spans the whole pipeline with ground-truth labels, so the work here is curation and protocol design rather than a new algorithm—a high-effort, low-novelty contribution elaborated as a research direction in Section 12.

11.3. Gap 2: Fragmented Peripheral Modelling

HALucinator [13], P2IM [14], Pretender [63], Fuzzware [15], DICE [65], and Ember-IO [67] each address isolated aspects of hardware peripheral emulation—MMIO, DMA, HAL abstraction, stateful models, and interrupt handling—without integration into a single adaptive framework. Analysis of a new target device typically requires selecting and combining multiple systems manually, with no principled methodology for deciding which peripheral model is appropriate for a given firmware. Considering five hardware-interaction dimensions—MMIO, DMA, interrupts, stateful peripherals, and HAL abstraction—no surveyed system integrates more than two: P2IM couples MMIO categorisation with interrupt injection, DICE and GDMA address DMA alone, Pretender learns stateful models, and HALucinator substitutes the HAL layer entirely.

Research opportunity: A unified adaptive peripheral model that automatically escalates emulation fidelity based on observed execution blockers: a “progressive fidelity” re-hosting architecture that starts with coarse MMIO models and refines only the specific hardware interactions blocking coverage. Every component model already exists in isolation; what is missing is the orchestration layer that decides when to escalate, so this is an integration effort plus one new component—the escalation controller—not a new peripheral-modelling primitive (developed further in Section 12).

11.4. Gap 3: Scalability–Fidelity Trade-Off in Re-Hosting

Scalable systems (FIRMADYNE, FirmAE) sacrifice execution realism for peripheral-dependent code paths; high-fidelity systems (HALucinator, Pretender) require per-target manual effort. This tension appears to be fundamental but has not been formally characterised. Success on Linux-based IoT firmware does not transfer to MCU, RTOS, bootloader, PLC, or UEFI contexts [10]. The trade-off is visible directly in Table 8: no surveyed system combines large-scale evaluation (>1000 images) with real-device validation. The five large-corpus systems [2,11,12,29,62] are all Linux-oriented emulation pipelines without hardware confirmation, while every system validated against physical devices evaluates on orders of magnitude fewer targets.

Research opportunity: A tiered re-hosting architecture with automatic mode switching across filesystem emulation, process emulation, HAL abstraction, full-system emulation, and hardware-in-the-loop fallback, with a formal fidelity metric that quantifies the gap between each tier. Systems at both extremes already exist, but the trade-off between them has never been formally measured, so the work is partly new engineering (the mode-switching architecture) and partly conceptual: the fidelity metric itself must first be defined.

11.5. Gap 4: Over-Representation of Linux-Based IoT Firmware

The majority of published work targets Linux-based IoT firmware because filesystem extraction, web interface access, and QEMU-based emulation make these targets tractable. MCU bare-metal, RTOS, UEFI, PLC, automotive, and medical firmware remain comparatively understudied despite their critical role in smart infrastructure and the higher severity of their potential compromise [10]. Within this corpus, every evaluation exceeding 1000 firmware images targets Linux-based systems; the largest monolithic-firmware corpus is HEAPSTER’s 819 images [49], and typical MCU evaluations use tens of targets. Domain-specific primary studies are scarcer still: three for PLC/ICS, two for automotive ECUs, one grid-adjacent attack study, and none for medical-device firmware—medical coverage in the literature rests on a single systematisation of knowledge [31].

Research opportunity: A comparative review or analysis framework organised by firmware class and operational context (smart infrastructure, automotive, medical, industrial), explicitly mapping technique capabilities and gaps across all six classes. The analysis techniques exist; what is missing is both their organisation by firmware class and fresh primary studies on the under-studied classes (MCU bare-metal, RTOS, PLC, automotive, and medical), so closing this gap needs synthesis work and new empirical studies, not a new tool.

11.6. Gap 5: Immature Cross-Layer Vulnerability Reasoning

Karonte [48] and FirmCross [47] demonstrate that multi-binary and cross-service analysis matters, but tools still predominantly reason over a single binary or single interface class. Tracing vulnerabilities across the full firmware stack—boot chain to kernel to userland to web service to OTA update agent—and identifying vulnerabilities that require cross-layer data flows to trigger, remains an open problem. Software supply-chain integration (shared third-party libraries propagating across vendor ecosystems) is similarly immature. Only two of the 78 primary studies in this corpus—Karonte and FirmCross—reason jointly over multiple binaries, and no surveyed system traces a data flow across bootloader, kernel, and userland within a single analysis.

Research opportunity: A cross-layer dependency graph linking code reuse, reachable interfaces, privileged transitions, and update channels, enabling whole-stack vulnerability tracing for complete firmware images. The two halves—binary similarity and multi-binary reachability—are each proven separately, so the open work is composing them into a single whole-stack analysis; the research risk lies in the composition and its scaling, not in inventing either technique.

11.7. Gap 6: Insufficient Exploit Validation

Most tools report crashes, taint flows, or potentially vulnerable paths. Few provide validated exploit chains. The distinction between “crash found,” “security-relevant bug,” and “exploitable vulnerability with demonstrated attack primitive” is rarely made explicit, limiting the actionability of results for defenders and the comparability of claimed CVE discovery rates across tools. All 14 fuzzing systems in Table 6 report crashes, bug counts, or CVEs, yet none automatically produces a validated exploit chain; FirmAgent [18] is the corpus’s only attempt at automated PoC generation, reporting 91% precision across 14 firmware images.

Research opportunity: A proof-producing firmware analysis workflow that couples detection with constraint solving, environment reconstruction, and exploitability ranking. LLM-assisted PoC generation with symbolic or dynamic validation [18] is a promising direction for reducing the manual effort currently required between crash discovery and PoC construction. Detection is mature but exploit validation is almost absent—FirmAgent is the corpus’s only attempt—so this is a substantial new system that chains existing solvers and emulators into automated proof production, rather than a refinement of current detectors.

11.8. Gap 7: Weak Grounding of AI/LLM Tools in Firmware Reality

LLM-based decompilation and agentic RE [18,19,20,82] are evaluated on generic binaries rather than firmware-specific artefacts: MMIO semantics, interrupt-driven control flow, packed images, vendor SDK idioms, and cross-architecture code reuse. Hallucination rates, reproducibility, and per-function inference costs are rarely measured in firmware contexts. Benchmark infrastructure such as Decompile-Bench [83] improves evaluation rigour for generic decompilation but does not address firmware specificity [84]. Of the AI-assisted works surveyed in Section 7, only FirmAgent [18] and IoTBec [55] evaluate end-to-end on real firmware; the LLM decompilation line [19,20,82] is assessed on recompilability of generic C binaries, and no surveyed work reports hallucination rates on firmware-specific artefacts.

Research opportunity: A firmware-native LLM benchmark covering peripheral semantic recovery, protocol extraction, interrupt handler identification, vulnerability triage, patch comprehension, and PoC synthesis. Hybrid verification pipelines in which LLM hypotheses are accepted only when confirmed by symbolic execution, type consistency, or dynamic execution represent a route to trustworthy AI-assisted FRE. This is really two tasks: curating a firmware-native benchmark that does not yet exist, and building the verifier-coupled pipeline that admits an LLM hypothesis only once confirmed—dataset creation plus a new architecture, not a larger model.

11.9. Gap 8: Scarcity of Ground-Truth Datasets

The field repeatedly reuses ad hoc collections of firmware samples. Open, multi-architecture datasets with confirmed vulnerability ground truth, version history, and architecture labels are rare. Without reproducible datasets, cross-paper comparison is difficult and claims of generality are hard to validate. Time-aware studies of vulnerability propagation through firmware release histories, OTA patch coverage, and recurring third-party library vulnerabilities are almost impossible without long-term version corpora. This corpus contains exactly two shared benchmark lineages: the P2IM unit-test suite, extended by Fuzzware and MultiFuzz [14,15,16], and FIRMADYNE-derived Linux image corpora [11,12]. Neither carries confirmed vulnerability ground-truth labels, and 11 of the 20 systems in Table 8 evaluate wholly or partly on ad hoc corpora used by no other work.

Research opportunity: A longitudinal firmware corpus with version history, unpacked components, architecture labels, interface metadata, confirmed vulnerability labels, and a curated subset aligned to smart-infrastructure device classes. No such corpus exists today, so the work is sustained data collection and labelling rather than method design; because Gaps 1 and 7 both depend on labelled firmware, this dataset is the foundation the other two build on.

11.10. Gap 9: Disconnection Between Update Security and RE Pipelines

OTA update security [119,120,122] and core FRE pipelines are largely independent bodies of work. End-to-end analysis connecting firmware extraction, update package RE, secure-boot validation, anti-rollback verification, and post-update attack surface assessment does not yet exist in the literature. The result is that RE practitioners lack tools to reason about whether a given device’s update mechanism can be exploited to deliver malicious firmware. Of the five OTA-focused works in this corpus [89,119,120,121,122], four are surveys; the single empirical study [122] measures update-channel security in isolation from any reverse engineering pipeline.

Research opportunity: A framework for reverse engineering firmware update trust chains: package format, signing workflow, anti-rollback logic, differential patch semantics, recovery-partition behaviour, and cloud–device trust linkage. OTA security and core FRE are today separate literatures with no connecting method, so this direction is largely exploratory: the first step is charting how real update chains are built across vendors, and only then can analysis that verifies their claimed properties be developed.

11.11. Gap 10: Sparse Smart-Infrastructure Case Studies

Power systems, smart meters, RTUs, medical embedded devices, transport control systems, and industrial gateways are under-represented relative to consumer IoT firmware in the published literature. The target SI special issue explicitly calls for infrastructure-aware hardware security research. Few studies connect firmware RE findings to safety, resilience, and operational continuity metrics in these domains. The imbalance mirrors Gap 4’s numbers: six domain-focused primary studies against dozens targeting consumer IoT, and none connecting firmware analysis results to safety, resilience, or operational-continuity metrics.

Research opportunity: Dedicated domain-specific studies mapping FRE methods to infrastructure threat models, safety constraints, and deployment limitations, and an open dataset of confirmed firmware vulnerabilities from smart-infrastructure device classes. These domains are under-studied rather than solved, so the work is new empirical case studies and a fresh open dataset—original fieldwork and curation, not a survey—together with a mapping from FRE findings to safety, resilience, and operational-continuity metrics that the literature does not yet provide.

11.12. Summary: Organising Conflicts

The ten gaps above crystallise into five organising tensions that define the field’s frontier:

• Scale vs. fidelity in re-hosting and emulation.
• Automation vs. realism in peripheral modelling and agentic RE.
• Firmware-class generality vs. domain specialisation in tooling and benchmarks.
• Bug finding vs. exploit validation in vulnerability discovery pipelines.
• LLM capability vs. trustworthiness in AI-assisted analysis.

These tensions are not independent: a system that resolves the automation–realism tension for peripheral modelling (Gap 2) would also reduce the scalability–fidelity gap (Gap 3) and partially address the firmware-class coverage imbalance (Gap 4).

12. Future Research Directions

Six research directions follow directly from the gaps identified above. Each direction is positioned relative to the existing literature, with an explicit claim that distinguishes it from prior work.

12.1. Unified Adaptive Re-Hosting Framework

Current re-hosting systems address MMIO (Fuzzware), DMA (DICE), HAL abstraction (HALucinator), stateful peripheral models (Pretender), and partial HIL (Avatar²) independently. A unified adaptive re-hosting framework would merge these contributions into a single system with a controller that escalates peripheral modelling fidelity automatically when execution stalls. The system would begin with fast, coarse MMIO approximations; detect execution blockers caused by missing or incorrect peripheral responses; and promote to learned stateful models, DMA emulation, or HIL forwarding only for the specific peripherals causing failures. The central claim would be: a self-refining re-hosting framework that generalises across MCU, RTOS, and Linux firmware classes without per-device manual configuration.

12.2. Cross-Technique Firmware RE Benchmark

The most immediately citable research gap is the absence of a common evaluation protocol. A cross-technique firmware RE benchmark would define a curated, publicly available firmware corpus with ground-truth labels for unpack success, component identification, re-hosting fidelity, input-surface coverage, vulnerability yield, and PoC validation. Unlike ad hoc corpora, this benchmark would include representative samples from all six firmware classes of Section 2, spanning multiple architectures, vendor origins, and known-vulnerability labels. The claim is the first cross-technique benchmark enabling direct comparison of FRE tools across the full analysis pipeline.

12.3. Cross-Layer Recurring Vulnerability Mining

BCSD systems (Gemini, IoTBec) detect reused code within or across firmware images. A cross-layer lineage-aware framework would extend this by combining binary similarity with interface reachability analysis to detect vulnerabilities that are (a) shared across firmware families through common third-party libraries and (b) reachable from attacker-controlled inputs in each host firmware. The analysis would traverse the full firmware stack—bootloader to userland to web service—and report which reachable attack surfaces expose the vulnerable code. The claim is the first framework to combine recursive binary similarity, multi-binary reachability, and interface-level attack-path scoring for whole-ecosystem vulnerability mining.

12.4. Trustworthy LLM-Assisted Firmware Analysis

Rather than proposing another end-to-end LLM pipeline, this direction targets a specific deficiency: the absence of verifiable AI-assisted RE. A hybrid system would accept LLM hypotheses (function purpose, variable semantics, vulnerability candidate) only when confirmed by a secondary verifier—symbolic execution, type/CFG consistency checking, or dynamic execution on the emulated firmware. The claim is evidence-grounded agentic firmware RE that produces verified findings with a measured false-positive rate, addressing the hallucination and reproducibility gaps of current agentic systems [84].

12.5. Firmware Update Ecosystem Reverse Engineering

Current RE pipelines treat firmware as a static binary. A firmware update ecosystem RE framework would treat the full update lifecycle as the analysis target: package format and container structure, signing workflow and key management, anti-rollback counter mechanism, differential patch semantics, recovery partition behaviour, and cloud–device trust linkage. Combining this with static and dynamic analysis of the update agent running on the device would enable end-to-end verification of claimed security properties and identification of implementation flaws. The claim is the first framework that systematically reverse-engineers firmware update trust chains and automatically identifies exploitable weaknesses in update delivery and verification pipelines [119,122].

12.6. Smart-Infrastructure-Positioned Firmware Analysis

For the specific needs of smart infrastructure operators, the most valuable contribution may be conceptual rather than algorithmic: an analysis framework explicitly organised by infrastructure domain and operational context. This would compare FRE techniques by (a) applicability to each firmware class in the taxonomy, (b) depth of analysis achievable without source code or hardware, (c) fidelity relative to a rated infrastructure threat model, and (d) practical deployment barriers (cost, required hardware access, and regulatory constraints). For medical devices, ICS gateways, and smart-grid RTUs, the framework would additionally specify which findings meet the threshold for vendor disclosure under relevant regulatory frameworks (IEC 62443 [125], FDA cybersecurity guidance, and UNECE WP.29 for automotive).

13. Conclusions

This review has surveyed firmware reverse engineering from 2014 to 2026, covering the full analysis pipeline from physical acquisition through exploit-validated vulnerability discovery. A corpus of 118 works—78 of them primary research studies—spanning Linux-based IoT firmware, MCU bare-metal systems, RTOS, UEFI/BIOS, PLC/ICS, and automotive ECUs has been surveyed across seven main analysis phases: static analysis (including protocol RE and patch diffing), dynamic emulation, fuzzing, AI-assisted analysis, platform security (secure boot, TEE, and OTA), digital twin integration, and smart-infrastructure domain case studies.

Large-scale Linux firmware emulation (Pandawan) now approaches systematic service reachability rather than mere boot completion. MCU fuzzing (Fuzzware, SHiFT) has moved peripheral modelling from a manual bottleneck to a partially automated workflow. Binary code similarity detection (Gemini, IoTBec) enables cross-ecosystem recurring vulnerability mining at scale. LLM decompilation (LLM4Decompile, SK²Decompile) measurably improves decompiler output quality. Agentic RE systems (FirmAgent) begin to close the gap between automated analysis and the multi-step reasoning previously requiring human expertise.

Yet the central challenge remains. The field lacks unified, trustworthy, and comparable end-to-end workflows that operate across heterogeneous firmware classes and produce validated security outcomes. Results from different subsystems cannot be compared, LLM-based tools are evaluated on settings that do not reflect firmware reality, and the entire body of work underserves the firmware classes most critical to smart infrastructure: PLC, automotive ECU, medical device, and smart-grid firmware. The ten structural gaps identified in Section 11 and the six research directions of Section 12 converge on this conclusion: the most impactful next step for the community is not another specialised analysis tool, but the infrastructure to measure, compare, and ground firmware security research in the operational realities of the systems it aims to protect.