Firmware
The software baked into a device's flash. Extract it and you can audit the whole device offline, which is why it is the prize of most hardware hacks.
Firmware is the software stored in a device's non-volatile flash that runs on bare metal, on a small RTOS, or on an embedded Linux. It is the bridge between the hardware and everything the product does, and on the bench it is almost always the first thing you go after.
What it is
Firmware ranges from a single monolithic binary on a microcontroller (an ESP32 app, an STM32 image) to a full Linux system on a router or camera SoC. A Linux firmware image is usually a concatenation of regions: a bootloader such as U-Boot, a compressed kernel, one or more root filesystems (commonly squashfs), and a small NVRAM or config area, sometimes wrapped with a header, a partition/MTD map, and a signature. The image on flash is the ground truth of what the device actually runs, independent of any documentation or vendor claim.
Why it matters
Almost every hardware finding starts here. Credentials, API keys, TLS certificates, update URLs, backdoor accounts, and exploitable bugs all live inside the firmware image. Once you have the image you can audit the device offline, at your own pace, with no rate limits and no crash recovery to fight. It is also the persistence layer: an attacker who can write flash can plant an implant that survives reboots and factory resets.
How you get it
There are three common paths, in rough order of preference:
- Pull a vendor update file from the support site or the device's OTA endpoint and carve it.
- Read the SPI flash chip directly with a
ch341aprogrammer and asoic8-clip(or after desoldering) usingflashrom. - Dump it over a debug interface:
esptoolover UART on ESP32, or a U-Boot console / JTAG on a Linux SoC.
How to inspect it
binwalk is the workhorse for mapping and carving an unknown image.
binwalk firmware.bin # map the structure: bootloader, kernel, filesystems
binwalk -E firmware.bin # entropy plot: flat-high = encrypted/compressed
binwalk -e firmware.bin # carve out the filesystem and other parts
ls _firmware.bin.extracted/squashfs-root/ # browse the extracted rootfs
A flat, uniformly high entropy plot across the whole image is the classic sign of encryption or whole-image compression; distinct blocks with headers mean it will carve cleanly. Once the rootfs is extracted, grep it for secrets and load the interesting binaries into Ghidra or radare2.
Pitfalls
- Encrypted or signed firmware will not carve. Check the entropy first, and remember the image on the flash chip may differ from the OTA file (which is often extra-encrypted for transport only).
binwalk -ecan silently miss or mis-carve a region. Confirm offsets against the partition table before trusting the extraction.- Vendor update files sometimes ship a delta or a compressed wrapper around the real image; you may need to unwrap one layer before
binwalksees the filesystem. - Never write a modified image back to a real target you do not own. A bad flash bricks the device.