Table of contents
17
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: AI firmware reverse engineering works best after the firmware has been unpacked, because an agent is good at reading a tree of files and bad at the physical and cryptographic steps before it. I read the tool documentation, three research papers and the US legal text on 10 November 2026, and tested a triage script on a synthetic firmware tree. This guide covers devices you own or have written permission to test.
- Unpacking in AI firmware reverse engineering is solved by tools, not by AI. unblob (MIT licence, 78+ formats, release 26.6.4 from June 2026), binwalk v3 (MIT, rewritten in Rust), EMBA (GPL-3.0, v2.0.5 from 3 November 2026) and FACT (GPL-3.0, v4.4.1) extract and scan firmware, and the agent starts from their output.
- Three 2025 and 2026 research systems report real yield but not clean precision. FirmAgent (NDSS 2026) reported 182 vulnerabilities at 91% precision on 14 firmware images, FORGE (April 2026) reported 1,274 vulnerabilities in 591 of 3,457 binaries at 72.3% precision, and FirmHive (November 2025) reported 1,802 at 71%, which means about a quarter to nearly a third of alerts were wrong.
- The legal basis for AI firmware reverse engineering is narrow and conditional. US rules exempt circumventing protections on a lawfully acquired device, or an authorised system, solely for good-faith security research in a harm-avoiding environment, and the rule says it is not a safe harbour from other laws such as the Computer Fraud and Abuse Act.
- The agent’s real job in AI firmware reverse engineering is triage. A script can list architectures, flag private keys and empty-password accounts and note which services start at boot, then the agent reads what the script flags and you verify each claim.
- XHack handles the AI firmware reverse engineering reasoning around the extractors. Its agent orchestrates real tools for static and dynamic analysis of binaries, from $20 a month with a 7-day trial.
If you searched for AI firmware reverse engineering, you want to know whether an agent can take a router or camera image and tell you what is wrong with it. It can help a lot with the middle of that job, and it cannot do the start or the end for you.
This AI firmware reverse engineering guide explains the pipeline, the tools, the evidence and the limits, and gives a script that turns an unpacked firmware tree into a short summary an agent can use. I did not run the research systems or a paid agent on real firmware, so every performance figure is from a paper I name.
AI firmware reverse engineering means using a language model to read, summarise and cross-reference the contents of a device’s firmware after tools have extracted it. The model does not pull the image off the chip and does not defeat encryption. Tools and people do that, and the model reads the result.
An AI firmware reverse engineering job has five stages, and the agent only belongs in the middle.
| Stage | What happens | Who does it best |
|---|---|---|
| Acquire | Get the image from the vendor, an update file or the device itself | You, with the right to do so |
| Unpack | Split the image into a filesystem and files | Tools such as unblob and binwalk |
| Triage | List architectures, services, keys, accounts and component versions | A script, then an agent reading its output |
| Analyse | Read configs and decompiled binaries, follow data flow | An agent with Ghidra or IDA, checked by you |
| Verify | Reproduce a suspected flaw on a lab device or emulator | You |
AI firmware reverse engineering touches copyright and computer-misuse law, so start with devices you own or are explicitly authorised to test. This is not legal advice, and the details depend on your country.
In the US, the Copyright Office’s section 1201 rule has a good-faith security research exemption. Its text in 37 CFR 201.40(b)(18) covers circumventing a technological protection on a lawfully acquired device, or on a system with the owner’s authorisation, solely for good-faith security research. It defines that research as testing, investigating or correcting a security flaw in an environment designed to avoid harm, with the results used mainly to promote security and not to enable copyright infringement.
The same paragraph adds a warning that matters more than the exemption: eligibility is not a safe harbour from other laws, including the Computer Fraud and Abuse Act. So owning the device does not authorise you to attack its cloud service, and a bug bounty scope that lists a device may not cover its backend. Outside the US, check your own law. Our AI bug bounty policy guide covers what programs say about AI-assisted work.
Four open-source tools cover the extraction side of AI firmware reverse engineering, and none of them needs an LLM. I read each project’s GitHub page on 10 November 2026.
| Tool | Job | Licence | Latest release read |
|---|---|---|---|
| unblob | Extracts 78+ archive, compression and filesystem formats recursively, carves unknown chunks | MIT | 26.6.4, 4 June 2026 |
| binwalk | Identifies and extracts embedded files; v3 is a Rust rewrite | MIT | v3.1.0, 31 October 2024 |
| EMBA | Firmware security analyzer and SBOM tool: extraction, static analysis, emulation | GPL-3.0 | v2.0.5, 3 November 2026 |
| FACT | Firmware Analysis and Comparison Tool for unpacking and comparing images | GPL-3.0 | v4.4.1, 14 September 2026 |
Pick by job. Use unblob or binwalk to unpack, EMBA for a broad automated scan and software bill of materials, and FACT to compare versions. For reading the binaries that come out, our Ghidra MCP guide and the IDA Pro AI guide cover the agent setups.
The most useful thing you can give an AI firmware reverse engineering agent is a short, factual summary of the unpacked tree, so it reads a few dozen lines and not a million. This script uses only the Python standard library, reads files and prints JSON, and never runs anything from the firmware.
"""Summarise an EXTRACTED firmware tree (output of unblob or binwalk) as compact JSON.
Use it only on firmware from a device you own or are authorised to test.
Usage: python3 fw_triage.py extracted_dir > triage.json
Standard library only. It reads files and prints facts, it never runs anything.
"""
import json, os, re, struct, sys
from collections import Counter
EM = {3: "x86", 8: "MIPS", 20: "PowerPC", 40: "ARM", 62: "x86-64", 183: "AArch64", 243: "RISC-V"}
SERVICES = ("telnetd", "dropbear", "sshd", "httpd", "uhttpd", "lighttpd", "upnpd", "tftpd", "ftpd", "smbd", "snmpd")
VERSION_RX = {
"busybox": re.compile(rb"BusyBox v(\d+\.\d+(?:\.\d+)?)"),
"openssl": re.compile(rb"OpenSSL (\d+\.\d+\.\d+[a-z]?)"),
"dropbear": re.compile(rb"Dropbear sshd v?(\d{4}\.\d+)"),
"uclibc": re.compile(rb"uClibc(?:-ng)? (\d+\.\d+\.\d+)"),
}
def elf_info(path):
with open(path, "rb") as f:
head = f.read(20)
if len(head) < 20 or head[:4] != b"\x7fELF":
return None
endian = "<" if head[5] == 1 else ">"
machine = struct.unpack(endian + "H", head[18:20])[0]
return f"{EM.get(machine, 'machine-' + str(machine))} {'64' if head[4] == 2 else '32'}-bit {'LE' if head[5] == 1 else 'BE'}"
def main(root):
arch, files, size = Counter(), 0, 0
keys, empty_pw, services, versions, init_hits = [], [], Counter(), {}, []
for dp, _, names in os.walk(root):
for n in names:
p = os.path.join(dp, n)
if os.path.islink(p) or not os.path.isfile(p):
continue
files += 1
size += os.path.getsize(p)
rel = os.path.relpath(p, root)
a = elf_info(p)
if a:
arch[a] += 1
if os.path.getsize(p) > 4_000_000:
continue
data = open(p, "rb").read()
if b"PRIVATE KEY-----" in data:
keys.append(rel)
for name, rx in VERSION_RX.items():
m = rx.search(data)
if m and name not in versions:
versions[name] = {"version": m.group(1).decode(), "found_in": rel}
if rel.endswith(("etc/passwd", "etc/shadow")):
for line in data.decode("utf8", "ignore").splitlines():
parts = line.split(":")
if len(parts) > 1 and parts[1] == "" and parts[0]:
empty_pw.append({"file": rel, "user": parts[0]})
if "/etc/init" in "/" + rel or "/rc.d/" in rel or rel.endswith(("rcS", "inittab")):
text = data.decode("utf8", "ignore")
for s in SERVICES:
if s in text:
services[s] += 1
init_hits.append({"file": rel, "service": s})
return {
"files": files, "total_mb": round(size / 1e6, 2),
"elf_architectures": dict(arch),
"private_key_files": keys[:20],
"accounts_with_empty_password": empty_pw[:20],
"services_mentioned_in_init": dict(services),
"init_script_hits": init_hits[:30],
"component_versions": versions,
}
if __name__ == "__main__":
if len(sys.argv) != 2 or not os.path.isdir(sys.argv[1]):
sys.exit("usage: fw_triage.py <extracted_dir>")
print(json.dumps(main(sys.argv[1]), indent=2))I tested it on a small synthetic tree I built, not on real firmware: two ARM and one MIPS binary, a BusyBox string, an OpenSSL string, a fake private-key file, an account with an empty password and an init script that starts a telnet and an HTTP service. It reported all of those correctly, including the architectures (ARM 32-bit little-endian and MIPS 32-bit big-endian), BusyBox 1.24.2 and OpenSSL 1.0.2k, and it exited with a usage error on a missing folder.
The script reports facts and no verdicts. An old BusyBox or a service in an init script is a lead, because the real question is whether the service is reachable and exposed on the device, which only you can confirm in a lab.
Published AI firmware reverse engineering research shows agents finding many candidate flaws in firmware, with precision between 71 and 91 percent depending on the design. Precision here means the share of reported findings that were real, so even the best figure leaves some false alarms, and these are research systems, not products you can buy.
| System | Date | What it did | Reported result |
|---|---|---|---|
| FirmAgent (NDSS 2026) | 2026 | Used fuzzing to find input points, then LLM agents for taint analysis and proof-of-concept cases | 182 vulnerabilities in 14 firmware at 91% precision, 140 previously unknown, 17 with CVE numbers |
| FORGE | April 2026 | Feedback-driven loop of reasoning, tool use and observation across parallel agents | 1,274 vulnerabilities in 591 of 3,457 binaries at 72.3% precision |
| FirmHive | November 2025 | A tree of context-isolated agents sharing a knowledge store | 1,802 vulnerabilities, about 1.5 times more than state-of-the-art tools, at 71% precision |
Read these carefully. FirmAgent’s 91 percent comes from 14 images and a design that uses fuzzing to ground the agent, which is why its precision is highest. FORGE and FirmHive report volume across hundreds or thousands of binaries, where roughly 28 to 29 percent of findings were not confirmed.
The lesson for your own AI firmware reverse engineering work is the same as in our best LLM for reverse engineering guide: an agent’s output is a list of hypotheses, and the grounding (fuzzing, emulation, your own reproduction) decides how many survive.
An agent stalls wherever the next step needs a physical device, a secret key or a running system. These limits are not research gaps you can wait out.
So yeah, here is where we talk about our own product. I am biased, it is my company, and I think XHack is the strongest all-in-one option for the reasoning side of firmware work, with a clear boundary around what it replaces.
In AI firmware reverse engineering, unpacking stays with unblob, binwalk, EMBA and FACT, and they are excellent. XHack’s agent works on what comes after: it orchestrates real tools for static and dynamic analysis of binaries, protocol reversing and behaviour mapping, according to its unrestricted AI agent page. That is the AI firmware reverse engineering triage and analysis work in the middle of the pipeline above, without you wiring a connector and writing glue.
XHack combines three things most providers sell separately: an autonomous AI agent, a continuous security platform and human testers.
Individual plans are $20, $49 and $150 a month, with a 7-day free trial, one per person, and the Elite plan lists malware analysis tools. See the pricing page and the agent for bug bounty guide. Run it on firmware from a device you own and judge it by what it finds, because brutal honesty is kind of our thing.
Yes, in part. AI can read and summarise firmware once tools have unpacked it, but it does not extract the image or defeat encryption. AI firmware reverse engineering is therefore a middle-of-the-pipeline job: tools unpack, a script or the agent triages, the agent reads configs and decompiled binaries, and you verify findings on a lab device.
unblob and binwalk extract embedded files and filesystems, EMBA runs a broad automated scan with software bill of materials output, and FACT compares firmware versions. unblob supports 78+ formats, binwalk v3 was rewritten in Rust, and all four are open source, so the agent starts from their output.
AI firmware reverse engineering research shows high yield and imperfect precision. FirmAgent reported 91% precision on 14 firmware images with fuzzing help, while FORGE reported 72.3% across 3,457 binaries and FirmHive 71%. Treat an agent’s findings as hypotheses and reproduce each one, because roughly a quarter to nearly a third of reported findings in the larger studies were not real.
It depends on the device, your authorisation and your country, and this is not legal advice. In the US, 37 CFR 201.40(b)(18) exempts circumventing protections on a lawfully acquired device for good-faith security research under conditions, and it says plainly that it is no safe harbour from laws such as the Computer Fraud and Abuse Act. Own the device or get written permission, and stay off its cloud backend unless that is in scope.
An agent cannot dump a chip, defeat encryption or confirm that a flaw works on real hardware. It stalls on encrypted images, custom formats and emulation limits, and it can hallucinate a function that is not in the binary, so verify every claim in the code and in a lab.
For binaries in AI firmware reverse engineering, yes, because the agent reads decompiler output and not machine code. Our Ghidra MCP guide and IDA Pro AI guide cover connecting an agent to each, and the AI reverse engineering guide covers the wider picture.
AI firmware reverse engineering is triage and reading, not extraction and proof. Unpack with the open-source tools, summarise the tree with a script, let the agent read what the script flags, and reproduce every finding on a device you own.
Tools and papers in AI firmware reverse engineering move quickly, so re-check versions and the legal text before you start, and keep to devices you are allowed to test.
Categories
Related articles
