Overview#
A critical infrastructure operator receives a firmware update for a substation RTU from a third-party vendor. Before pushing the update to 47 deployed units across the power grid, the security team wants to know what is actually in the binary. Binwalk scans the image in seconds: a Linux kernel, a SquashFS root filesystem, an OpenSSL library, a BusyBox binary, and one section with suspiciously high Shannon entropy that could be an encrypted payload or simply a compressed resource. The results go into the inventory. The high-entropy section triggers a FKIE FACT deep analysis job. Two days later, the analyst has a full software bill of materials and a CVE report before the update touches a single live device.
Binwalk is the standard open-source tool for firmware analysis and extraction, automating identification of embedded file systems, compressed archives, encryption markers, and executable code within firmware binary images. It is the first step in firmware reverse engineering workflows, establishing what is inside a firmware blob before deeper analysis tools like FKIE FACT are applied. Argus integrates Binwalk to track firmware analysis results at scale, maintaining an inventory of firmware images analysed, detected signatures, and extraction outcomes for supply chain security and IoT/OT vulnerability assessment workflows.
Open Standards#
- SHA-256 (NIST FIPS 180-4): Every firmware record is keyed by its SHA-256 digest, providing a globally unique, collision-resistant identifier for supply chain tracking and de-duplication across firmware inventory entries.
- YARA: Extracted firmware filesystems and compressed payloads are matched against YARA rules to detect known malware implants (VPNFilter, Cyclops Blink, VOLT TYPHOON-related signatures) before a device update is deployed.
- Common Vulnerabilities and Exposures (CVE) / NVD: Identified embedded components are cross-referenced against the National Vulnerability Database; CVE counts and high-severity totals flow from the FKIE FACT deep-analysis stage back into the firmware inventory record.
- Common Vulnerability Scoring System (CVSS v2 and v3): CVSSv2 and CVSSv3 scores are stored alongside CVE findings to allow analysts to prioritise firmware remediation by severity before deployment to operational networks.
- GraphQL: All query and mutation operations (binwalkExtractions, binwalkStats, submitBinwalkExtraction) are exposed exclusively through a GraphQL API, with per-field authentication enforced via permission classes.
- OAuth 2.0 / JWT (RFC 6749 / RFC 7519): Every API operation requires a valid bearer JWT issued by the platform authorisation service; organisation scoping is derived from claims within the token.
- STIX 2.1 Traffic Light Protocol (TLP): Classification labels on firmware records map directly to STIX 2.1 TLP marking-definition identifiers (TLP:WHITE through TLP:RED), controlling which analysts may query or export a given record.
Last Reviewed: 2026-03-18 Last Updated: 2026-04-14
Key Features#
Firmware Submission and Signature Recording#
Submit firmware analysis results via submitBinwalkExtraction, providing the firmware SHA256 hash, file name, file size, list of detected signatures, Shannon entropy measurement, and extraction path. Signatures identify what Binwalk found: cpio archive, gzip compressed data, Linux kernel, ELF binary, JFFS2 filesystem, OpenSSL certificate, LZMA compressed data, and more. Entropy values indicate whether sections of the firmware are encrypted or compressed.
Entropy Analysis for Encryption Detection#
High Shannon entropy across a large firmware region is a strong indicator of encryption. It can mean a firmware vendor is protecting their embedded software, or in adversarial contexts, that malware injected into firmware is concealing its code. Low-entropy sections are candidate areas for string extraction and signature scanning. Entropy values are preserved per record and surfaced in the inventory for analyst review.
Signature Coverage Inventory#
Query the firmware extraction inventory via binwalkExtractions to see analysed firmware files and their signature hits. This supports supply chain security auditing by tracking which firmware images were analysed, what file systems and bootloaders they contain, and which images may warrant deeper review through FKIE FACT.
Integration with YARA and FKIE FACT#
Binwalk extraction paths, identified compressed payloads, and extracted file systems flow into FKIE FACT for deep analysis. FKIE FACT unpacks the extracted file systems, identifies binaries, and runs YARA rules and CVE lookups against embedded components. This two-stage pipeline (Binwalk followed by FKIE FACT) provides comprehensive firmware supply chain coverage without requiring manual handoff between tools.
Use Cases#
- IoT Device Firmware Auditing: Extract and analyse firmware from IoT devices deployed in operational environments to identify unpatched Linux kernels, default credential exposure, or unauthorized remote maintenance tools.
- Supply Chain Verification: Before deploying routing or switching hardware from a vendor, verify that the firmware signature profile matches expected content. Unusual encrypted sections or unknown file systems warrant deeper FKIE FACT analysis.
- Malware Implant Detection: Apply YARA rules to Binwalk-extracted filesystems to detect known firmware backdoor signatures, including VPNFilter, Cyclops Blink, and VOLT TYPHOON-related implants.
- OT Asset Security Assessment: Analyse firmware updates pushed to SCADA RTUs and PLCs to identify embedded components with known CVEs before deployment to operational networks.
Integration#
Available via GraphQL: binwalkExtractions, binwalkStats (queries); submitBinwalkExtraction (mutation). All operations require authentication and organisation scoping.
Works alongside FKIE FACT (deep component analysis), YARA Engine (pattern-based detection on extracted binaries), and the Data Source Catalog domain (tracking asset firmware versions).