Firmware Extraction and Analysis With binwalk
Firmware is where the secrets live: hardcoded keys, debug backdoors, the actual logic an attacker will study. Before any of that is reachable you have to crack the image open, and binwalk is the tool that does it. Here is the workflow I run on almost every embedded image, and the parts that trip people up the first time they try it.
Why Firmware Is the Whole Ballgame
A connected product ships its entire trust model inside one binary. Update keys, API tokens, TLS private keys, the bootloader, the kernel, and the root filesystem are all in there. If any of it is recoverable, the device’s security rests on the weakest secret in the image. The first job of an assessment is to open that image and see what was left inside.
Step 1: Get the Image
You cannot analyze what you cannot read. There are three reliable ways to obtain firmware, and the right one depends on how locked down the vendor is:
Step 2: Identify What Is Inside
Start with a signature scan. binwalk walks the image and flags known magic bytes, which tells you what you are dealing with before you carve anything:
# scan the image for known signatures
binwalk firmware.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, OS: Linux,
CPU: ARM, image name: "Linux Kernel"
64 0x40 LZMA compressed data, properties: 0x5D
1572864 0x180000 Squashfs filesystem, little endian, version 4.0,
compression: xz, size: 4823100 bytes
Three sections, and the one that matters most is at the end: a SquashFS filesystem. That is the root filesystem, and it is where the interesting files live.
Step 3: Extract the Filesystem
Now carve it out. The combination below extracts known types, recurses into anything nested, and carves the rest so nothing is left behind:
# extract, recurse, and carve everything
binwalk -e -M --dd='.*' firmware.bin
Scan Time: 2026-06-01 11:04:22 Target File: /home/lab/firmware.bin DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 64 0x40 LZMA compressed data, properties: 0x5D 1572864 0x180000 Squashfs filesystem, version 4.0 $ ls _firmware.bin.extracted 40.7z 180000.squashfs squashfs-root
Step 4: Check Entropy Before You Trust the Carve
If extraction comes back empty, the image may be encrypted. An entropy scan tells you fast: uniformly high entropy across the whole image means encryption or whole-image compression, not a filesystem you can carve:
# plot byte entropy across the image
binwalk -E firmware.bin
DECIMAL HEXADECIMAL ENTROPY -------------------------------------------------------------------------------- 0 0x0 Rising entropy edge (0.998363) 1572864 0x180000 Falling entropy edge (0.812501)
A clean rise and fall like this is normal compressed data. A flat line near 1.0 with no structure is the signature of an encrypted image, which is a finding in itself and changes how you proceed.
Step 5: Go Through the Filesystem
With the root filesystem extracted, the assessment becomes a careful read of what shipped. The files that pay off first are credentials, keys, and startup scripts:
ls squashfs-root cat squashfs-root/etc/passwd
bin dev etc lib mnt proc sbin tmp usr var www root:$1$Hk2j$Qd9.0pPq1xZ3bN7c8Lf4m1:0:0:root:/root:/bin/sh
A hardcoded root hash baked into every unit is one of the most common findings in this step. From here the work moves to the web interface in /www, the startup scripts in /etc, and any private keys left in the tree.
Where This Fits
Firmware extraction is the foundation of a product security assessment. Once the filesystem is open, the real questions begin: what secrets are recoverable, what services start at boot, and whether the update mechanism can be abused. That deeper analysis is the kind of work we do at Berkner Tech.