How to Use Binwalk: Extract Files Hidden in Files (2026)

What Is Binwalk?

Binwalk is an open source tool that scans a binary file for the signatures of other file formats, reports the offset of each one, and optionally extracts them. Craig Heffner released it in 2010 to make router firmware analysis less tedious, and it is now maintained under the ReFirmLabs organisation on GitHub.

The idea underneath it is simple enough to explain in one paragraph. Almost every file format starts with a fixed byte sequence called a magic number: a ZIP archive begins with PK\x03\x04, a PNG with \x89PNG, a gzip stream with \x1f\x8b. Binwalk walks the whole file byte by byte, matches what it sees against a library of several hundred such signatures, and prints a hit list. The file command does the same trick, but only at offset zero. Binwalk does it everywhere.

That difference is the entire point. file challenge.png tells you it is a PNG and stops, because the first eight bytes say PNG and file has no reason to keep looking. Binwalk keeps looking, and finds the archive somebody appended at byte 7858.

Two jobs dominate its use. In firmware analysis it splits a monolithic .bin flash dump into bootloader, kernel and root filesystem so you can mount the filesystem and read the code. In CTF forensics it answers "is there something else in this file", which is the question most forensics and steganography challenges are built around.

Binwalk v2 or Binwalk v3: Which One to Install

This is the part that confuses people in 2026, and no tutorial older than late 2024 mentions it. There are two binwalks.

Binwalk 2.x is the original Python implementation. It is what a decade of tutorials, walkthroughs and Stack Overflow answers describe. Kali packages it as binwalk at version 2.4.3.

Binwalk 3.x is a complete rewrite in Rust, released as v3.1.0 on 31 October 2024. It is faster, produces fewer false positives, and ships more built-in extractors. Kali packages it separately as binwalk3, and version 3.1.0-0kali3 migrated into kali-rolling on 16 October 2025.

Install whichever you need, or both, since the binaries have different names and do not collide:

sudo apt update
sudo apt install binwalk      # Python, v2.4.3, command: binwalk
sudo apt install binwalk3     # Rust, v3.1.0, command: binwalk3

On other distributions, or if you want current upstream, v3 installs through Cargo:

cargo install binwalk

Neither version extracts much on its own. Both shell out to external utilities to unpack what they find, and the v3 dependency script for Ubuntu pulls in a long list of them: 7zip, sleuthkit, cabextract, unyaffs, srecord, device-tree-compiler, lz4, lzop, unrar, zstd, plus a Debian build of sasquatch for the vendor-mangled SquashFS variants that consumer routers are full of. If an extraction reports a filesystem and then produces nothing, a missing helper is the first thing to check, not a corrupt image.

My recommendation, and it is not the popular one: start with v2. Every guide, every CTF writeup and every firmware teardown you will read for the next year assumes v2 flags, and v2 still has features v3 dropped. The v3 command line is fourteen options wide, and hexdump diffing (-W), opcode scanning (-A) and manual carving (--dd) are not among them. Reach for binwalk3 when you are working through a large firmware image and want the speed.

Your First Scan: Reading the Signature Table

Run binwalk with no flags at all. This is a read-only signature scan and it is always the correct first move:

binwalk challenge.png

Here is genuine output from binwalk 2.3.3 against a PNG with a ZIP archive appended to it, the classic CTF construction:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 64 x 64, 8-bit/color RGB, non-interlaced
41            0x29            Zlib compressed data, default compression
7858          0x1EB2          Zip archive data, at least v1.0 to extract, compressed size: 22, uncompressed size: 22, name: flag.txt
8024          0x1F58          End of Zip archive, footer length: 22

Three columns, and the first two are the same number in decimal and hex. Read the table from the top:

• Offset 0, PNG image. The file is what it claims to be. Expected.
• Offset 41, Zlib compressed data. This is noise. A PNG stores its pixels in a zlib-compressed IDAT chunk, so every valid PNG produces this line. Learning which hits are structural and which are interesting is most of the skill.
• Offset 7858, Zip archive data. This is the find. Binwalk has even parsed the archive's central directory and read the filename out of it: flag.txt.
• Offset 8024, End of Zip archive. The archive's footer, which confirms the whole thing is present and not truncated.

When a scan returns fifty lines and you only care about one format, filter with -y to include and -x to exclude:

binwalk -y zip challenge.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
7858          0x1EB2          Zip archive data, at least v1.0 to extract, compressed size: 22, uncompressed size: 22, name: flag.txt
8024          0x1F58          End of Zip archive, footer length: 22

In practice you will see false positives, and the trick is to expect them rather than chase them. Random compressed data occasionally contains four bytes that look like a TIFF header. A hit with a plausible offset, a sensible reported size and a matching footer is real. A lone hit with a nonsense size is a coincidence.

Extracting Files With -e, and the Root Trap

Once the table shows something worth having, -e pulls it out:

binwalk -e challenge.png

If you are logged in as root, which describes a lot of Kali users, that command fails and prints a wall of Python traceback. The relevant line is this:

Extractor Exception: Binwalk extraction uses many third party utilities,
which may not be secure. If you wish to have extraction utilities executed
as the current user, use '--run-as=root' (binwalk itself must be run as root).

This is not a bug and it is worth understanding rather than working around blindly. Extraction means binwalk hands attacker-controlled bytes to a pile of third-party unpackers, and those unpackers have a long history of path traversal bugs. Refusing to do that as root is a deliberate safety rail added in version 2.3.3. The honest fix is to work as a normal user. If you insist on root, you have to say so out loud:

binwalk --run-as=root -e challenge.png

The extraction lands in a directory named after the input file, with each carved piece named for its hex offset:

_challenge.png.extracted:
-rw-r--r-- 1 user user   188 1EB2.zip
-rw-r--r-- 1 user user 12352 29
-rw-r--r-- 1 user user  8005 29.zlib
-rw-r--r-- 1 user user    22 flag.txt

That listing tells a small story. 1EB2.zip is the appended archive, carved out at hex offset 0x1EB2, and flag.txt is what came out when binwalk went ahead and unzipped it for you. The pair 29 and 29.zlib are the PNG's own pixel data: the compressed stream and its decompressed contents. Binwalk extracted the boring true positive alongside the interesting one, which is normal.

Binwalk 3 uses the same -e flag but writes into a directory called extractions by default rather than _filename.extracted. Both versions accept -C to choose your own output directory:

binwalk -e -C ./output challenge.png

One more v2 flag earns a place in your muscle memory. -z carves the raw byte ranges out and skips running any external unpacker at all:

binwalk -e -z suspicious.bin

You get files instead of parsed contents, which is slower to work with and dramatically safer on a sample you do not trust.

Recursive Extraction for Firmware

Firmware images nest. Extract a router image and you get a compressed kernel and a SquashFS blob. Extract those and you get the actual kernel and a full directory tree. Doing that by hand is three or four rounds of the same command, so binwalk automates it with -M, named after Matryoshka dolls:

binwalk -Me firmware.bin

That single command scans, extracts, then rescans everything it just extracted, down to a default depth of eight levels. The output is long. Send it to a file and read it afterwards.

Depth control matters more than it sounds like it should. On a large image, recursion digs into decompressed data, produces thousands of junk hits, and turns into a disk-filling exercise. Cap it:

binwalk -Me -d 2 firmware.bin

The prize at the end is usually a directory named something like squashfs-root, holding a complete embedded Linux filesystem. That is where the interesting work starts: /etc/passwd with hardcoded hashes in it, private keys under /etc, startup scripts in /etc/init.d that reveal which services listen, and CGI binaries in /www, the usual home of command injection in consumer devices.

When binwalk reports a filesystem but the extraction directory is empty, the cause is almost always a missing unpacker. Vendors patch SquashFS with non-standard compression, stock unsquashfs refuses it, and sasquatch exists specifically to handle those variants. Install it before you conclude the image is encrypted.

Entropy Analysis: Spotting Encryption Without a Signature

Sometimes a scan comes back with nothing. No filesystem, no kernel, no signatures worth the name. The useful question then is whether the data is encrypted, compressed, or simply a format binwalk does not know. Entropy answers it.

Entropy is a measure of randomness in data, on a scale from 0 to 1. Plain text and uncompressed code sit low, around 0.3 to 0.6, because they repeat themselves. Compressed and encrypted data sit near 1.0, because both processes destroy repetition by design.

binwalk -E firmware.bin

Version 2 prints the points where entropy jumps, and generates a plot unless you pass -N to suppress it. On the PNG from earlier:

DECIMAL       HEXADECIMAL     ENTROPY
--------------------------------------------------------------------------------
4096          0x1000          Rising entropy edge (0.956868)

One rising edge at 0x1000 and no falling edge, which reads as "low-entropy header, then compressed data all the way to the end". For a PNG that is precisely correct.

Reading a real firmware entropy plot comes down to shape recognition, and three shapes cover almost everything:

• Flat and high across the entire file. The image is encrypted, or compressed as a single unit. Nothing to carve until you have the key.
• Blocky, alternating high and low. Normal firmware. The low regions are headers, padding and uncompressed code, the high regions are compressed sections, and the transitions are your extraction boundaries.
• Mostly low with one high plateau. One compressed payload sitting in an otherwise plain file. That plateau is what you came for.

Entropy is a triage tool, not proof. It tells you data is compressed or encrypted and cannot tell you which, because a good compressor and a good cipher produce statistically similar output.

Binwalk in CTF Forensics: A Repeatable Workflow

In a CTF forensics or steganography challenge, binwalk is the second command you type. Here is the sequence that solves the majority of "here is a file, find the flag" problems, in the order that costs you the least time:

1. Run file first. One second, and it tells you whether the extension is honest. A .jpg that file calls a ZIP archive has already given you the answer.
2. Run binwalk with no flags. Read the table. Compare what it found against what the format legitimately contains. Anything past the expected end of the file is the challenge.
3. Run strings -n 8 file | less. Flags get stored in plain text far more often than anyone admits, and this catches them before you spend twenty minutes on carving.
4. Extract with binwalk -e. If it produces a password-protected archive, that is the intended path, and cracking it belongs to a different tool.
5. Only then reach for the specialists. zsteg for LSB data in PNG and BMP, steghide for JPEG and WAV with a passphrase, exiftool for metadata fields.

Step 5 is where people start, and starting there wastes time. Appended data is far more common in beginner and intermediate challenges than true least-significant-bit steganography, because it takes the author ten seconds with cat to create. Our guide to steganography techniques covers what to do when binwalk comes back clean and the flag really is hidden in the pixels, and reading file metadata with ExifTool covers the tag fields binwalk never looks at.

One habit worth building: when -e gives you nothing but the signature table clearly shows an archive, carve it manually with dd using the offset binwalk printed. Byte 7858 from the earlier scan becomes:

dd if=challenge.png of=carved.zip bs=1 skip=7858

It is crude and it always works, which is why it belongs in your head next to the fancier options.

When Binwalk Is the Wrong Tool

Knowing where a tool stops is worth as much as knowing how to drive it, and binwalk has four clear limits.

It does not find data hidden inside pixels. Least-significant-bit steganography changes existing bytes rather than adding new ones, so there is no signature to match and no offset to report. Binwalk will scan an LSB-encoded image and correctly tell you nothing is appended. Use zsteg or stegsolve instead.

It does not read metadata. EXIF tags, XMP packets, ID3 frames and PDF document properties are structured fields inside the format, not embedded files. ExifTool owns that job.

It is not a disk forensics tool. For a full disk image with a partition table and deleted files to recover, foremost, scalpel and The Sleuth Kit understand filesystem structures that binwalk treats as an undifferentiated byte stream.

It cannot help with encryption. If entropy is flat at 1.0 across the whole image, there is no structure left to recognise. That becomes a key-recovery problem, and usually a hardware one.

Legal and Ethical Considerations

Two risks sit specifically in this tool, and both deserve a moment before you point it at an unknown file.

The first is that extraction executes code you did not write on data you do not control. CVE-2022-4510 is the case in point: binwalk versions 2.1.2b through 2.3.3 contained a path traversal flaw in the PFS extractor plugin, and a crafted filesystem image could write files anywhere the process could reach. Drop a malicious module into .config/binwalk/plugins and the next binwalk run executes it. It was fixed in 2.3.4, but the general lesson survives the patch. Run -e on untrusted samples inside a VM or a container, keep the tool updated, and use -z when you only need the bytes.

The second is legal rather than technical. Firmware is copyrighted software, and reverse engineering it sits in a patchwork of jurisdiction-specific exemptions. In the United States, the Librarian of Congress renewed the DMCA Section 1201 exemption for good-faith security research on lawfully acquired devices in the ninth triennial rulemaking, effective 28 October 2024. Exemptions carry conditions, and they are not the same thing as blanket permission.

Analysis you can do without hesitation:

• Firmware for devices you own, downloaded from the manufacturer's public support site
• Files supplied by a client under a signed engagement whose scope names them
• CTF challenges and deliberately vulnerable training images
• Open source firmware projects such as OpenWrt

Finding a hardcoded credential in a shipping product is the beginning of a disclosure process, not the end of a research project. Report it to the vendor, give them a reasonable window, and publish afterwards.

Frequently Asked Questions