RE Toolkit (4/5): IoT firmware analysis with binwalk v3, unblob, EMBA, FACT and Qiling

Routers, IP cameras and factory IoT devices all run firmware: a single binary holding a bootloader, a kernel and a miniature Linux file system. Vulnerabilities often live right there: hardcoded passwords, decade-old BusyBox builds, C web services that never validate input. Part 4 of the RE Toolkit series introduces five open-source repos that take you from a downloaded .bin to a concrete list of weaknesses.

GitHub: https://github.com/ReFirmLabs/binwalk · about 14.6k stars · Rust · MIT

Five repos, step by step

binwalk v3: rewritten in Rust

binwalk is the classic tool here; v3 is a full Rust rewrite for speed and accuracy over the old Python version. The easiest way to get all extractor dependencies is the Docker image described in the wiki, or install via cargo.

binwalk firmware.bin        # list what is embedded inside
binwalk -eM firmware.bin    # extract, recursively scan extracted files
binwalk -E firmware.bin     # entropy graph

Reading the entropy graph: flat regions close to 1 are usually compressed or encrypted data. If the whole file is high-entropy and binwalk recognises no compression format, the firmware is probably encrypted and you need the key (often found in an older firmware or the bootloader).

unblob: when binwalk's extraction is messy

unblob determines both the start and end of each chunk according to the format spec, so it produces fewer false positives, and data matching no format is carved out separately with entropy for manual review. It runs as a normal user and writes JSON reports.

pip install unblob
unblob --show-external-dependencies     # check required extractors
unblob -e ./out --report report.json firmware.bin

EMBA: from firmware file to report

EMBA automates the whole chain: extraction, architecture detection, component and version identification, CVE matching, hardcoded credentials and risky configs, static binary analysis and optional emulation for dynamic testing. The output is an HTML report plus an SBOM. EMBA is part of the OWASP Firmware Security Testing Methodology.

git clone https://github.com/e-m-b-a/emba.git && cd emba
sudo ./installer.sh -d
sudo ./emba -l ./log -f ./firmware.bin -p ./scan-profiles/default-scan.emba

A full scan can take hours; run it in a dedicated VM. The sister repo EMBArk adds a web UI to manage many scans.

FACT and Qiling: at scale, or when you need to run it

• FACT_core suits teams tracking hundreds of firmware images: upload once, extraction and plugin analysis run automatically, then compare two versions to see which files a patch changed.
• Qiling emulates an ARM/MIPS binary on an x86 laptop without the real device, letting you hook syscalls, set breakpoints and watch memory. Useful for poking a router's web service without rebuilding the whole system.

Safety notes

• Extracted file systems may contain symlinks pointing outside (for example to /etc). Extract inside a VM or container and avoid sudo when not required.
• Only analyse firmware for devices you own or are authorised to test; report vulnerabilities through responsible disclosure.
• Version-based CVE matching can produce false positives when vendors backport fixes; verify before reporting.

How to apply it

• Embedded dev: Run unblob and EMBA on your own firmware before release; what you see is what competitors and attackers see.
• Tech Lead: Use EMBA's SBOM to track third-party components and meet the growing SBOM requirements for connected devices.
• PM: When buying IoT devices for the business, ask vendors for this kind of report, or run EMBA on their public firmware to compare how "clean" each vendor is.