/analyzing-firmware-images

name: analyzing-firmware-images
description: Extract, analyze, and assess firmware images from embedded devices, IoT hardware, routers, and similar targets — filesystem extraction, hardcoded credential discovery, binary analysis across architectures, web interface review, network service enumeration, emulation, and cryptographic assessment. Use when analyzing a firmware update file, reviewing IoT device security, hunting for hardcoded secrets in device firmware, or assessing the attack surface of an embedded system.
verified: 2026-07-27

Analyzing Firmware Images

Firmware is a frozen Linux (or RTOS) image, and its security froze with it. Hardcoded credentials, command injection in CGI scripts, unsigned update packages, and debug interfaces left enabled are not edge cases -- they are the baseline. The work is extraction, orientation, and then asking the same questions you would ask of any system, with the knowledge that nobody has patched this one since it shipped.

When to Use

• Extracting and analyzing a firmware update file (.bin, .img, .chk, .trx)
• Reviewing IoT device security posture from a firmware image
• Looking for hardcoded credentials, keys, or secrets in device firmware
• Assessing the attack surface of an embedded device or router
• Evaluating update mechanisms and signature verification
• Analyzing a bare-metal or RTOS image from a microcontroller

When NOT to Use

• **Standard x86/x64 binary reverse engineering** -- use `analyzing-binaries`
• **Malware sample analysis** -- use `analyzing-malware`
• **Source code is available** -- use `auditing-code-for-vulnerabilities`

Firmware Acquisition

Before analysis comes acquisition. The method determines what you get.

| Method | What you get | Notes | | --- | --- | --- | | Vendor download | Update package, often compressed or encrypted | Check support portals, FTP servers, and FCC filings | | OTA sniffing | Update payload in transit | mitmproxy or tcpdump on the device's update channel; many devices use plain HTTP | | UART/serial console | Shell access, bootloader interaction | Three wires (TX, RX, GND); identify with a multimeter or logic analyzer | | JTAG/SWD | Full memory read, debug access | Requires pin identification; JTAGulator, OpenOCD | | Chip-off | Raw flash contents (NAND/NOR) | Desolder the flash chip; read with a programmer (CH341A, FlashcatUSB); last resort | | Bootloader extraction | Dump via U-Boot `md` or `sf read` commands | If the bootloader shell is accessible over UART |

For OTA interception, configure the device to proxy through mitmproxy. Many devices ignore proxy settings -- ARP spoofing or a transparent bridge may be required. If the update is over HTTPS, check whether the device validates certificates at all; a surprising number do not.

Initial Analysis

Start with format identification and entropy analysis before extracting.

file firmware.bin
binwalk firmware.bin              # identify embedded filesystems and compression
binwalk -E firmware.bin           # entropy analysis -- high entropy = compressed or encrypted
hexdump -C firmware.bin | head -64   # header bytes reveal container format
strings -n 10 firmware.bin | head -100  # quick orientation

**What the entropy plot tells you:**

• **Flat high entropy (close to 1.0) across the entire image** -- encrypted

or compressed as a unit. You need the decryption key or decompression method before you can proceed.

• **Regions of high entropy separated by low-entropy headers** -- compressed

filesystem partitions with metadata between them. Normal; extract the partitions.

• **Low entropy throughout** -- uncompressed filesystem or raw flash. Direct

extraction should work.

Common container formats:

| Header magic | Format | | --- | --- | | `hsqs` / `sqsh` | SquashFS | | `UBI#` | UBI/UBIFS | | `0x1985` | JFFS2 | | `0x28cd3d45` | cramfs | | `HDR0` | TRX (Broadcom routers) | | `\x27\x05\x19\x56` | uImage (U-Boot) |

Extraction

Use the right tool for the filesystem. Generic extraction misses metadata and permissions.

# General recursive extraction -- good starting point
binwalk -Me firmware.bin

# SquashFS -- the most common embedded filesystem
unsquashfs -d rootfs squashfs-root.img
# Non-standard SquashFS (vendor-modified): use sasquatch
sasquatch -d rootfs squashfs-root.img

# JFFS2
jefferson firmware.jffs2 -d rootfs

# UBI/UBIFS
ubireader_extract_images firmware.ubi
ubireader_extract_files firmware.ubi

# cramfs
cramfsck -x rootfs cramfs.img

# Raw NAND dumps may need OOB data stripped first
nandextract firmware.nand

If binwalk finds nothing and entropy is high, the image is likely encrypted. Look for a bootloader or earlier firmware version that contains the decryption routine. Some vendors ship the decryption key in the bootloader or in a companion partition.

Filesystem Analysis

Once extracted, treat the rootfs as a Linux system you are auditing for the first time.

Credentials and Secrets

# Password files
cat rootfs/etc/passwd
cat rootfs/etc/shadow
# Hardcoded credentials -- these are endemic
rg -rn 'password|passwd|admin|root|default' rootfs/etc/ --include='*.conf'
rg -rn 'BEGIN (RSA|EC|OPENSSH|DSA) PRIVATE KEY' rootfs/
rg -rn 'api[_-]?key|secret[_-]?key|token' -i rootfs/

# Certificates and keys
find rootfs -name '*.pem' -o -name '*.key' -o -name '*.crt' -o -name '*.p12'
# WiFi and VPN credentials
find rootfs -name 'wpa_supplicant*' -o -name '*.ovpn' -o -name 'ipsec.*'

Default credentials in `/etc/shadow` are the single most common firmware finding. Check whether root has a password hash and whether it is crackable -- it usually is. See `cracking-passwords` for hash handling.

Configuration and Services

# Startup scripts reveal what runs and how
ls rootfs/etc/init.d/ rootfs/etc/rc.d/
cat rootfs/etc/inittab
# Systemd units if present
find rootfs -name '*.service' -path '*/systemd/*'

# Installed packages and versions
cat rootfs/etc/opkg/status 2>/dev/n