/FIRMWARE · 2026-07-31
Unpacking firmware without becoming the dump
The finding is which extracted binary actually speaks on the wire, and what it still trusts.
A vendor “firmware.bin” is usually a container: bootloader, kernel, one or more filesystems, maybe a signature trailer. Analysts who dump the whole tree into a zip and call it reverse engineering have produced a copy.
Work from a copy. Hash the original. Do not flash anything back to a device unless the engagement says so.
What the tools are
binwalk
Signature scan plus entropy. Tells you “gzip at 0x80000, squashfs at 0x200000.” False positives are normal. Treat the map as leads.
unblob
Recursive extractors with fewer “carve everything” accidents than classic binwalk -e. Prefer it when the image is a matryoshka of vendor formats. Still not magic on unknown crypto blobs.
unsquashfs, ubireader, jefferson, yaffshiv
Filesystem-specific. Once you know it is squashfs / UBI / JFFS2 / YAFFS, use the tool that speaks that, not another round of carving.
sasquatch, jefferson forks
Vendor squashfs that stock unsquashfs hates. Use when the extractor errors and the entropy still looks like a filesystem. This is plumbing.
Combination we actually run
cp firmware.bin firmware.bin.orig
sha256sum firmware.bin.orig
unblob firmware.bin -o out/
# then inventory, do not Ghidra yet
find out -type f | head
# typical: squashfs-root/usr/sbin/httpd
# squashfs-root/etc/shadow
# squashfs-root/bin/busybox
Inventory first:
- Init: which binary is PID 1, which services start.
- Remote surfaces: dropbear, httpd, vendor d-bus, custom UDP.
- Secrets in configs: default passwords, Wi-Fi PSKs, cloud URLs, update keys sitting in world-readable files.
- Update path: signed or just a tarball over HTTP.
Only then pick one binary that is in scope — usually the parser that faces the network or the updater — and load it in Ghidra. The rest of the tree is context.
What we report from an unpack
Default credentials in the image. An update channel with no signature. An outdated dropbear. A web UI that still has the vendor debug endpoint. These are findings because they are in the bits you shipped.
We do not turn an unpacked httpd into a public exploit write-up. Layout notes and a risk register go to the customer. If they want a patch-diff later, that is a different SOW.
When unpacking fails
Encrypted outer envelope. Then the question is key storage (OTP, header, companion file), not “try more extractors.” If we cannot unwrap it under the authorization, we say so. Pretending binwalk will decrypt AES is how you fake a report.