A compromised IoT device or router needs firmware analysis to identify implanted backdoors
Investigating UEFI/BIOS rootkits that persist across OS reinstallations
Analyzing firmware updates for supply chain compromise or malicious modifications
Extracting and examining embedded Linux filesystems from IoT device firmware images
Verifying firmware integrity after a suspected hardware or firmware-level compromise
Do not use for standard operating system malware; use PE/ELF analysis tools for OS-level malware on conventional systems.
Detection Gaps & Validation
The #1 miss is analyzing vendor firmware instead of the device's actual flash. A clean image from the vendor site won't show the implant. Dump the live chip via UART/JTAG or SPI programmer (flashrom), and compare its hash against the vendor baseline — a mismatch is the starting point, not the conclusion.
binwalk -e silently fails on encrypted/proprietary regions. A flat high-entropy band in binwalk -E (entropy ~0.99 with no recognized signatures) means encryption or a custom packer, not random padding. Look for the bootloader's decrypt routine, or dump the decrypted filesystem from RAM on a running device.
Modifications hide outside the main rootfs. Backdoors live in the bootloader env (fw_printenv), NVRAM/config partitions, the second (backup) bank of dual-bank flash, and trojanized shared libraries (.so) that hook legitimate binaries — not just /etc/init.d/rcS.
UEFI implants need the right lens. Carve modules with UEFITool/UEFIExtract, diff DXE drivers against a clean dump, and run chipsec for SPI lock / BIOS write-protect / Secure Boot state. LoJax/MoonBounce/CosmicStrand modify specific modules (e.g., CORE_DXE) rather than adding obvious files.
Emulation gaps cause false negatives: firmadyne/FAT often can't bring up NVRAM-dependent services, so a backdoor that only listens after full boot looks absent. Confirm findings statically (Ghidra on the suspect ARM/MIPS binary) rather than trusting an emulated run.
Benign-lookalike FPs: vendor debug/telnet daemons, hardcoded support credentials, and BusyBox nc are common in legitimate firmware — confirm intent via the binary's actual call-out target before flagging.
Prerequisites
binwalk installed for firmware image analysis and extraction ()
pip install binwalk
Ghidra with ARM/MIPS architecture support for embedded binary reverse engineering
UEFI Tool (UEFITool) for UEFI firmware parsing and analysis
Firmware Analysis Toolkit (FAT) or EMBA for automated firmware analysis
QEMU for emulating extracted firmware filesystems
Cross-compilation toolchains for ARM, MIPS, and other embedded architectures
Workflow
Step 1: Extract and Identify Firmware Components
Analyze the firmware image structure and extract filesystems:
# Identify embedded filesystems and compressed data
binwalk firmware.bin
# Extract all identified components
binwalk -e firmware.bin
# Recursive extraction with signature scanning
binwalk -eM firmware.bin
# Output typically includes:# - Bootloader (U-Boot, GRUB, custom)# - Kernel image (Linux, RTOS)# - Root filesystem (SquashFS, JFFS2, CramFS, ext4)# - Configuration data# - Digital signatures or checksums# Entropy analysis to find encrypted or compressed regions
binwalk -E firmware.bin
# Identify specific filesystem types
file _firmware.bin.extracted/*
# For SquashFS filesystems
unsquashfs _firmware.bin.extracted/squashfs-root.img
ls squashfs-root/
Step 2: Analyze the Extracted Filesystem
Search for malicious modifications in the firmware filesystem:
# Directory structure analysis
find squashfs-root/ -type f | head -50
# Search for suspicious files
find squashfs-root/ -name "*.sh" -execls -la {} \;
find squashfs-root/ -perm -4000 -type f # SUID binaries
find squashfs-root/ -name "*.so" -newer squashfs-root/bin/busybox # Modified libraries# Check startup scripts for backdoorscat squashfs-root/etc/init.d/rcS
cat squashfs-root/etc/inittab
ls -la squashfs-root/etc/rc.d/
# Search for hardcoded credentials
grep -rn "password\|passwd\|secret\|key\|token" squashfs-root/etc/ 2>/dev/null
grep -rn "root:" squashfs-root/etc/shadow 2>/dev/null
# Check for unauthorized SSH keys
find squashfs-root/ -name "authorized_keys" -execcat {} \;
# Network configuration backdoorscat squashfs-root/etc/hosts
grep -rn "iptables\|nc\|netcat\|ncat" squashfs-root/etc/ squashfs-root/usr/bin/
# Check for reverse shells in cron
find squashfs-root/ -name "crontab" -o -name "cron*" | xargs cat 2>/dev/null
# Identify all ELF binaries for analysis
find squashfs-root/ -type f -exec file {} \; | grep ELF
Step 3: Reverse Engineer Suspicious Binaries
Analyze extracted binaries that may be backdoors:
# Identify architecture and format
file squashfs-root/usr/bin/suspicious_binary
# Extract strings for IOC discovery
strings squashfs-root/usr/bin/suspicious_binary | grep -iE "http|ip|port|shell|connect|exec"# Cross-reference against known firmware binaries# Compare SHA-256 hashes with known-good firmwaresha256sum squashfs-root/usr/bin/* > current_hashes.txt
# diff against baseline: diff baseline_hashes.txt current_hashes.txt# Import into Ghidra for disassembly (select correct architecture)# ARM: ARM/AARCH64 (Little Endian for most IoT devices)# MIPS: MIPS/MIPS64 (Big or Little Endian depending on device)# x86: For UEFI modules# Analyze with radare2 for quick triage
r2 -A squashfs-root/usr/bin/suspicious_binary
# Commands: afl (function list), pdf @main (disassemble main), iz (strings)
Step 4: UEFI/BIOS Firmware Analysis
Analyze system firmware for bootkits and implants:
# Extract UEFI firmware volumes with UEFITool# GUI: UEFITool -> File -> Open -> Select firmware.rom# CLI: UEFIExtract firmware.rom# Analyze UEFI firmware with chipsec (requires hardware access)
python chipsec_main.py -m common.bios_wp # BIOS write protection
python chipsec_main.py -m common.spi_lock # SPI flash lock
python chipsec_main.py -m common.secureboot # Secure Boot status
python chipsec_main.py -m common.uefi.s3bootscript # S3 resume script# Dump UEFI firmware from live system
python chipsec_util.py spi dump firmware_dump.rom
# Compare with known-good firmwaresha256sum firmware_dump.rom
# Compare against vendor-provided firmware hash# Scan for known UEFI malware signatures
yara -r uefi_malware_rules.yar firmware_dump.rom
Known UEFI Malware Families:
━━━━━━━━━━━━━━━━━━━━━━━━━━
LoJax: First in-the-wild UEFI rootkit (APT28/Fancy Bear)
Modifies SPI flash to drop persistence agent
MosaicRegressor: Modular UEFI framework dropping multiple payloads
CosmicStrand: UEFI firmware rootkit modifying kernel during boot
BlackLotus: UEFI bootkit bypassing Secure Boot on Windows 11
ESPecter: ESP (EFI System Partition) bootkit modifying boot manager
MoonBounce: SPI flash implant modifying CORE_DXE module
FinSpy UEFI: Surveillance software with UEFI persistence
Step 5: Emulate Firmware for Dynamic Analysis
Run extracted firmware in an emulated environment:
# Emulate ARM-based IoT firmware with QEMU# Mount the extracted filesystemsudo mount -o loop squashfs-root.img /mnt/firmware
# Chroot into the firmware with QEMU user-mode emulationsudocp /usr/bin/qemu-arm-static /mnt/firmware/usr/bin/
sudochroot /mnt/firmware /bin/sh
# Or use firmadyne for automated firmware emulation# https://github.com/firmadyne/firmadyne
python3 fat.py firmware.bin
# Network service analysis within emulated firmware# Scan for open ports and services
nmap -sV localhost -p 1-65535
# Monitor network traffic from emulated firmware
tcpdump -i tap0 -w firmware_traffic.pcap
Software permanently stored in device hardware (flash memory, EEPROM) controlling low-level device operations and boot process
UEFI (Unified Extensible Firmware Interface)
Modern system firmware replacing legacy BIOS; provides boot services, runtime services, and a modular driver architecture
SPI Flash
Serial Peripheral Interface flash memory chip storing UEFI/BIOS firmware; can be read and modified for persistence
Secure Boot
UEFI feature verifying digital signatures of boot components to prevent unauthorized code execution during startup
SquashFS
Read-only compressed filesystem commonly used in embedded Linux firmware for space-efficient storage
Bootkit
Malware infecting the boot process (MBR, VBR, UEFI) to load before the operating system and evade OS-level security
Firmware Emulation
Running extracted firmware in a virtual environment (QEMU, firmadyne) to analyze behavior without physical hardware
Tools & Systems
binwalk: Firmware analysis tool for scanning, extracting, and analyzing embedded file systems and compressed data in firmware images
UEFITool: Open-source UEFI firmware image parser and extractor for analyzing UEFI volumes, modules, and drivers
chipsec: Intel's open-source framework for platform security assessment including SPI flash, Secure Boot, and UEFI analysis
firmadyne: Automated firmware analysis and emulation platform for Linux-based embedded devices
Ghidra: NSA's reverse engineering tool with ARM, MIPS, and other embedded architecture support for firmware binary analysis
Common Scenarios
Scenario: Investigating a Compromised Router with Persistent Backdoor
Context: A network router continues to exhibit suspicious behavior (unexpected DNS resolutions, traffic to unknown IPs) even after factory resets. Firmware-level compromise is suspected.
Approach:
Dump the firmware from the router using JTAG/UART debug interface or vendor management tools
Extract the filesystem with binwalk and identify the Linux distribution and kernel version
Compare file hashes against known-good firmware image from the vendor
Search startup scripts (rcS, inittab, crontab) for backdoor entries
Analyze any modified or new binaries with Ghidra (ARM/MIPS architecture)
Check for hardcoded credentials, unauthorized SSH keys, and reverse shell scripts
Emulate the firmware to observe network behavior and identify C2 communication
Pitfalls:
Not dumping firmware from the actual device (downloading from vendor site gives clean version, not the compromised one)
Ignoring modified shared libraries (.so files) that may hook system functions
Missing firmware modifications stored outside the main filesystem (bootloader, configuration partitions)
Not checking both the primary and backup firmware partitions (some devices have dual-bank flash)
Output Format
FIRMWARE MALWARE ANALYSIS REPORT
===================================
Device: NetGear R7000 Router
Firmware Version: V1.0.11.116 (modified)
Architecture: ARM (Little Endian)
Filesystem: SquashFS (Linux 3.4.103)
Dump Method: UART debug console
INTEGRITY CHECK
Vendor Firmware Hash: aaa111bbb222... (clean V1.0.11.116)
Analyzed Firmware Hash: ccc333ddd444... (MISMATCH)
Modified Files: 14 files differ from vendor baseline
BACKDOOR FINDINGS
[!] /usr/bin/httpd_backdoor (new binary, not in vendor firmware)
Architecture: ARM 32-bit
Function: Reverse shell to 185.220.101[.]42:4444
Persistence: Added to /etc/init.d/rcS
[!] /etc/shadow modified
Root password changed to known hash
New user 'admin2' added with UID 0
[!] /etc/crontab modified
Added: */5 * * * * /usr/bin/httpd_backdoor
[!] /root/.ssh/authorized_keys (new file)
Contains attacker's SSH public key
EXTRACTED IOCs
C2 IP: 185.220.101[.]42
C2 Port: 4444
SSH Key: ssh-rsa AAAA... attacker@control
Backdoor Hash: eee555fff666...
REMEDIATION
1. Flash clean vendor firmware via TFTP recovery mode
2. Change all device credentials
3. Update to latest firmware version
4. Enable firmware integrity checking if available
5. Monitor for re-compromise indicators
