Deep Dive into Firmware Reverse Engineering

Firmware comes in many forms: monolithic blobs of ARM/MIPS/x86 code that run on bare metal, embedded Linux distributions packaged as squashfs/jffs2 filesystems, real-time operating systems like FreeRTOS or VxWorks, and increasingly modular bootloaders like U-Boot or coreboot. Each demands different tooling.

The reverse-engineering workflow is consistent regardless of target:

1. Acquire the firmware (vendor download, on-chip read, sniffed update).
2. Identify structure (magic bytes, entropy, headers).
3. Unpack filesystems and binaries.
4. Analyze statically (Ghidra, IDA, Binary Ninja, Radare2) and dynamically (emulation, hardware debugging).
5. Locate vulnerabilities or backdoors.
6. Exploit or report.

Tools of the trade: binwalk for carving, firmware-mod-kit and unblob for unpacking, Ghidra (NSA, free) and IDA Pro for disassembly, QEMU + firmadyne/FirmAE for emulation, and OpenOCD + JTAGulator + Saleae logic analyzer for hardware-level access.

The easiest acquisition method is downloading from the vendor support page. When unavailable, hardware-level techniques apply:

• SPI flash chip dumping — desolder or in-circuit clip an 8-pin SOIC flash chip; read it with a CH341A programmer and flashrom.
• eMMC dumping — bridge BOOT0 to ground to force a read mode, or use a chip-off + UFS reader.
• JTAG / SWD — discover pads with JTAGulator, connect a J-Link or Black Magic Probe, halt the CPU, dump RAM and flash.
• UART consoles — frequently expose a U-Boot prompt; printenv, md.b 0x80000000 0x100, or boot from TFTP for a root shell.
• Update interception — sniff HTTPS update channels (TLS-MITM with a planted CA), or capture USB/serial firmware updates.

Be aware of legal constraints: the DMCA Section 1201 exemption for "good-faith security research" covers most US activity, but international and contractual constraints vary.

binwalk -Me firmware.bin
unblob firmware.bin -o extracted/

Once unpacked, an embedded-Linux filesystem reveals BusyBox, vendor binaries in /usr/sbin, configuration in /etc, and web UI files in /www. Quick wins:

• grep -R "password" etc/ — hard-coded creds.
• find . -name "*.cgi" — CGI scripts often vulnerable to command injection.
• strings -n 8 sbin/httpd | grep -i "key\|secret\|token" — embedded API keys.
• file etc/passwd and cat etc/shadow — pre-set root passwords.

For monolithic binaries, load into Ghidra with the correct CPU architecture, base address, and endianness. Identify ROM/RAM regions, find the vector table for ARM Cortex-M, locate strings, and rename functions methodically. Cutter (Radare2-based GUI) and Binary Ninja are excellent alternatives.

Critical first targets in a vendor binary:

• system(), popen(), execve() calls with user-controlled input → command injection.
• strcpy, sprintf, gets → stack overflows.
• Hardcoded comparisons against a magic string → backdoor authentication.
• Crypto routines with hardcoded keys.

FirmAE and firmadyne automate emulating embedded Linux firmware in QEMU with NVRAM stubs and network bridging. Once booted, the device's web UI is reachable on http://localhost, and you can fuzz it with afl++, ffuf, or Burp.

For bare-metal firmware, Unicorn Engine and QEMU's user-mode emulation can run individual functions in isolation. Avatar2 and PANDA bridge real hardware and emulators for hybrid analysis.

Hardware debugging with OpenOCD + GDB on a live JTAG-attached device offers the highest fidelity:

openocd -f interface/jlink.cfg -f target/stm32f4x.cfg
arm-none-eabi-gdb firmware.elf
(gdb) target remote :3333
(gdb) load

Setting hardware breakpoints on authentication routines, dumping RAM at runtime, and stepping through cryptographic operations reveal keys and logic flaws invisible in static analysis.

Modern firmware fuzzing tools include:

• AFL++ with QEMU mode for embedded Linux binaries.
• HALucinator for hardware-abstraction-layer fuzzing without real hardware.
• Fuzzware automates MMIO modeling for ARM Cortex-M firmware.
• boofuzz for protocol fuzzing of network-exposed services.

Coverage-guided fuzzing of CGI binaries and HTTP daemons regularly produces 0-days in SOHO routers within hours.

Common findings:

• Hardcoded telnet/SSH credentials (NETGEAR, D-Link, Cisco repeat offenders).
• Authentication bypass via magic User-Agent strings (D-Link DIR-series — "xmlset_roodkcableoj28840ybtide").
• Predictable session tokens generated from time(NULL).
• Crypto keys reused across the entire product line, extractable from one device and usable to decrypt or sign for all.
• Debug interfaces left enabled in shipping firmware.

The pattern repeats so often that the EFF, Cybernews, and academic researchers maintain databases of vendor-specific defaults.

The Mirai botnet (2016) spread via 60+ hardcoded default credentials in IoT firmware, hijacking ~600,000 devices and powering record-breaking DDoS attacks. CVE-2022-26134 (Confluence OGNL injection) was actually a firmware-equivalent — server software shipped with a vulnerable expression evaluator exposed by default.

The 2023 Cisco IOS XE CVE-2023-20198 zero-day enabled unauthenticated admin account creation on tens of thousands of routers; reverse engineering of the web service rapidly produced reliable exploit code.

Volt Typhoon's persistent access to US edge devices in 2023–2024 leveraged unpatched router and firewall firmware (Fortinet, Sangfor, Cisco), with implants surviving reboots by modifying squashfs filesystems.

Pegasus / Predator spyware delivered to mobile devices via baseband firmware exploits — the most expensive firmware exploitation work on Earth, often costing $1M+ per zero-click chain.

For vendors and integrators:

1. Eliminate hardcoded credentials and keys. Generate per-device unique secrets at provisioning; use a hardware root of trust (TPM, secure element) to protect them.
2. Sign firmware images and enforce signature verification in the bootloader. Use Secure Boot (chain of trust from immutable ROM).
3. Encrypt firmware at rest with a key sealed to hardware. Even when an attacker dumps the SPI flash, they should see ciphertext.
4. Disable debug interfaces (JTAG, SWD, UART) in production via eFuses or boot-time configuration.
5. Implement update authenticity and rollback protection so attackers cannot downgrade to vulnerable versions.
6. Run security testing as a release gate — static (Coverity, CodeQL), dynamic (FirmAE-based fuzzing), and third-party penetration testing.
7. SBOM and CVE monitoring — track every open-source component (uClibc, BusyBox, OpenSSL, libcurl) and ship updates within SLA.
8. Provide a coordinated disclosure channel and act on it. Researchers will find the bugs — the question is whether they reach you before an adversary.

For defenders:

• Inventory firmware versions across the fleet; treat unmanaged IoT as hostile.
• Network-segment IoT and embedded devices; deny outbound connections by default.
• Monitor for indicators of firmware tampering (boot-time integrity, unexpected SSH/telnet listeners).