Automated Binary Firmware Analysis with AI: A Practical Guide

Connected products often ship with firmware you did not build and source code you cannot access. Automated binary analysis lets you inspect the firmware artifact itself, identify components, match known vulnerabilities, and find security weaknesses without rebuilding the product from source. AI can support that work by helping you interpret complex findings, but reliable firmware security still depends on evidence from the binary rather than an LLM’s best guess.

What Is Automated Binary Firmware Analysis?

Automated binary firmware analysis is the process of extracting, inspecting, and assessing compiled firmware without requiring its original source code. It can identify files, libraries, executable code, software components, security settings, and known vulnerabilities inside a firmware image. Automated binary analysis is especially useful for connected devices because supplier packages, legacy firmware, and third-party software often arrive only as compiled binaries.

A useful system first reconstructs the firmware, identifies what is actually present, and connects findings to technical evidence. AI can then assist with tasks such as interpreting decompiled code, grouping findings, or explaining why an issue may matter. The evidence should come before the generated explanation.

Static vs. Dynamic vs. AI-Assisted Binary Code Analysis - What Differs

Binary code analysis can use static, dynamic, and AI-assisted techniques, and each answers a different question. Static analysis examines firmware without executing it, while dynamic analysis observes behavior when code runs in a controlled environment. AI-assisted analysis can help interpret patterns or decompiled code, but it should not replace the evidence produced by the underlying analysis.

You rarely need to choose only one method. Static analysis gives repeatable coverage, while dynamic testing can validate behavior that depends on runtime state. Static Code Analysis vs. Binary Scanning explains why inspecting the final firmware artifact adds visibility that source analysis alone cannot provide.

The Automated Binary Firmware Analysis Pipeline, Step by Step

A reliable pipeline separates evidence collection from interpretation. Each stage should preserve enough context for your PSIRT or engineering team to understand where a component or vulnerability came from. That traceability makes automation useful for security decisions rather than just faster scanning.

Firmware Acquisition and Extraction

The first step is obtaining the exact firmware version you need to assess from a release package, supplier delivery, update server, device image, or archive. ONEKEY uses its open-source unblob extraction technology to parse firmware and supports more than 100 archive, compression, and filesystem formats. Extraction exposes nested filesystems, executables, configuration files, and other content for later analysis.

Filesystem and Component Parsing

Once the image is extracted, the system can classify files and inspect executables, strings, symbols, linked libraries, cryptographic material, and other artifacts. ONEKEY uses several component-detection methods, including rules, package-manager metadata, lock files, QNX packages, Go binary metadata, RTOS analysis, and optional fuzzy matching. The platform also exposes the evidence used to identify a component.

This stage is where Binary software composition analysis becomes useful. Instead of assuming a supplier declaration is complete, you examine software found inside the firmware itself. Version and dependency information then give vulnerability matching a stronger base.

SBOM Generation from the Binary

An SBOM turns detected software into a structured inventory for vulnerability, supplier, and compliance workflows. A binary-derived SBOM is valuable when source scanners cannot run or when you need to verify what reached the final firmware. ONEKEY can also merge imported SBOM data with components detected from the binary.

An SBOM management tool helps keep those records connected to product versions instead of treating each scan as a standalone report. Binary software composition analysis can also expose gaps between supplier data and evidence found in the shipped artifact. That matters when several firmware versions remain supported.

Automated CVE Matching

The next stage maps identified components and versions to known vulnerability data. ONEKEY matches components against NVD using CPE identifiers and against OSV using Package URLs derived from package metadata and other sources. The result is a set of potential CVE relationships for your team to assess against the product.

A CVE match is not proof of exploitability. A feature may be disabled, absent from the build, unreachable, or mitigated by product configuration. Good automated binary analysis keeps component evidence available so triage can separate a possible match from a product-relevant risk.

AI-Assisted Triage and False-Positive Reduction

AI is most useful after the pipeline has produced verifiable technical evidence. An LLM can summarize findings, explain decompiled logic, group similar issues, or present context faster. It should not invent component presence, reachability, or exploitability when analysis has not established those facts.

False-positive reduction therefore needs more than an AI confidence score. ONEKEY’s Automated Impact Assessment uses a rule-based system and firmware evidence such as versions, architecture, files, strings, function imports, binary usage, and symbols to assess whether a vulnerability is relevant to a build. Findings can be marked as not affected with supporting evidence, while VEX and assessment records help preserve the result for later review.

Binary Software Composition Analysis: Where AI Adds Value and Where It Doesn't

Binary software composition analysis answers a factual question: what software is inside this firmware artifact? Parsers, package metadata, signatures, symbols, strings, and reverse-engineering methods provide the evidence for that inventory. AI can improve classification or interpretation, but it should not replace verifiable component identification with a generated answer.

LLMs generate probable outputs, not ground truth about a firmware image. Automated binary analysis should remain reproducible enough that another analyst can inspect the artifact and understand why a result appeared. AI adds value when it reduces interpretation effort without weakening that chain of evidence.

Binary Firmware Analysis for Firmware & Embedded Products

Firmware is not just another enterprise software workload. You may need to assess an ECU, medical device, industrial gateway, router, or IoT controller with no endpoint agent and no accessible source repository. Binary code analysis gives you a way to inspect the product on its own terms.

Why Source-less Binary Analysis Is Unavoidable for Third-Party Firmware

Third-party firmware often arrives as a signed image or update package rather than a source tree. Source-code tools cannot inspect code they do not have, and vendor SBOMs may be incomplete or produced at a different stage of the build. The final binary becomes the most direct evidence of what software actually reached the product.

Binary Static Analysis: The Final Frontier shows how deeper binary analysis can trace user-controlled input through decompiled code and identify issues such as command injection. ONEKEY can decompile selected ELF executables and inspect data flow for potential zero-day issues such as command injection, format-string problems, and stack buffer overflows. This extends Binary code analysis beyond component inventory into weaknesses that may not yet have a public CVE.

Regulatory Drivers (CRA, IEC 62443, RED/EN 18031)

Regulation increases the need for repeatable firmware evidence, but each framework has different requirements. From December 11, 2027, the EU Cyber Resilience Act requires manufacturers to identify and document vulnerabilities and components, including through a machine-readable SBOM covering at least top-level dependencies, and to perform effective and regular security tests and reviews. Binary analysis can support those activities when source information is incomplete.

IEC 62443-4-1 covers secure product-development lifecycle processes such as verification, validation, defect management, patch management, and end-of-life. Under the Radio Equipment Directive, EN 18031-1, -2, and -3 are harmonized cybersecurity standards supporting specific RED Article 3(3) requirements, subject to limitations in the EU decision. These frameworks do not make binary scanning a universal compliance shortcut, but firmware evidence can support the processes you need to demonstrate.

How ONEKEY Automates This for Connected Products

ONEKEY starts with binary firmware and builds security context from the artifact itself. The platform extracts firmware, inventories files and components, creates or enriches SBOM data, matches known CVEs, and can analyze selected executable code for previously unknown weaknesses. You can use those results across PSIRT, vulnerability management, supplier review, and compliance work without requiring the original source repository.

ONEKEY also preserves evidence around component detection, helping analysts verify findings instead of accepting a black-box result. Its Zero-Day Detection capability uses static code analysis to identify issues such as command injection and other risky code paths in binaries and supported scripts. AI-assisted interpretation can complement, rather than replace, the structured analysis that establishes what firmware contains and why a finding matters.

Automated binary analysis can then be repeated across new firmware releases. Keeping component and vulnerability information tied to versions gives you a consistent evidence base as products change. This is useful for long-lived devices where source access, supplier cooperation, and build environments may change over time.