binwalk - Wiki - Espilon Learn

binwalk is a firmware triage tool. It scans a binary for known magic-byte signatures (filesystems, compression, bootloaders, certificates, kernels) and carves the matching regions out, so you can go from a raw flash dump to a browsable root filesystem.

What it is

binwalk is a signature scanner plus an extractor. It walks a file byte by byte, matches each offset against a large library of magic signatures (the same idea as file(1), but exhaustive and offset-aware), and prints a map of what lives where. With -e it hands each recognised region to the right unpacker (unsquashfs, jefferson, sasquatch, 7z, dd) and drops the results in an extraction directory. Modern binwalk (v3, the Rust rewrite) keeps the same command surface.

Why it matters

Extracting the firmware is the first move in most hardware assessments. Once you have a flash image, whether pulled over UART with esptool, clipped off a SOIC-8 with flashrom, or downloaded from a vendor update, binwalk finds where the bootloader, kernel and SquashFS rootfs begin inside one monolithic blob and unpacks them. That exposes init scripts, web CGI binaries, TLS private keys, /etc/shadow, and hardcoded credentials, all for offline analysis with no live device needed.

How to use it

binwalk firmware.bin           # signature scan: map the image layout
binwalk -e firmware.bin        # extract known parts into extractions/
binwalk -Me firmware.bin       # recurse into every carved file (can be slow)
binwalk -E firmware.bin        # entropy plot to spot compression or encryption
binwalk --dd='.*' firmware.bin # carve every match with dd, even unknown types

A normal workflow is: scan first to understand the layout, then extract. Extraction lands in a directory such as _firmware.bin.extracted/ (or extractions/ on v3). The prize is usually a squashfs-root/ tree:

binwalk -e firmware.bin
cd _firmware.bin.extracted/squashfs-root
grep -rIn "password\|admin\|PRIVATE KEY\|http://" etc/ www/
find . -name '*.pem' -o -name '*.key'

Reading entropy

The -E entropy plot is a fast structural read. High, flat entropy near 8.0 bits/byte means the data is compressed or encrypted. A region at 0 to 3 is padding or empty flash, roughly 5 to 6.5 is executable code or text, and a solid plateau at 7.9 to 8.0 across the whole image (with no signatures found) is the classic fingerprint of an encrypted update, which tells you to go find the key rather than keep carving.

Pitfalls

binwalk can only carve what it recognises. An encrypted or custom-packed image shows no filesystem signature; the entropy plot is then your only clue.
False positives are common. A random four-byte match that "looks like" a JFFS2 header will produce garbage extractions; sanity-check offsets against the entropy map before trusting them.
Extractors are external. If -e skips SquashFS, install sasquatch (vendors often use non-standard LZMA SquashFS that mainline unsquashfs cannot read).
-Me recursion can explode on a large image; scope it, or extract one layer at a time.

What it pairs with

binwalk is the bridge between getting the bytes and understanding them. Upstream it takes whatever the extraction gear produced (flashrom over a ch341a clip, or esptool over UART). Downstream, you load the carved binaries into ghidra or radare2 to reverse the code, and grep the rootfs for the secrets that hardcoded-secrets teaches you to spot.