Every router, IP camera, industrial controller, and medical device runs firmware. This software sits between hardware and application logic, typically running with the highest privileges on the device. When firmware has vulnerabilities, there is no security layer beneath it to contain the damage.
Despite this, firmware remains one of the least scrutinized components in most organizations. The devices ship, they work, and nobody looks at what is actually running on them until something goes wrong.
Why Firmware Analysis Matters
Firmware vulnerabilities are different from application-level bugs in several important ways.
Patching is hard. Updating firmware on deployed devices requires careful coordination. Many devices lack automatic update mechanisms. Some require physical access. Industrial devices may require scheduled downtime. This means firmware vulnerabilities persist far longer than application bugs.
Privileges are maximal. Firmware typically runs as root or with equivalent privileges. There is no privilege separation, no sandboxing, and often no address space layout randomization (ASLR). A buffer overflow in firmware frequently leads directly to complete device compromise.
Visibility is minimal. Most organizations do not know what software versions their IoT and embedded devices are running. There are no dependency manifests, no SBOMs, and no automated vulnerability scanning. The devices are black boxes.
Firmware Extraction Techniques
The first step in firmware analysis is getting the firmware image. There are several approaches.
Download from vendor. Many manufacturers publish firmware updates on their websites. This is the easiest path and should be your first attempt. Check the vendor support page, FTP servers, and CDN URLs embedded in the device update mechanism.
Capture during update. If the device checks for updates over the network, you can capture the firmware image with a proxy or network tap during the update process. Many devices download updates over unencrypted HTTP, making interception trivial.
Extract from flash memory. When firmware is not available through other means, you can read it directly from the device flash memory. This requires hardware tools (JTAG probes, SPI flash readers) and physical access to the device circuit board. Tools like flashrom can read common flash chips.
UART console access. Many devices expose a UART serial console on the circuit board. Connecting to this console often provides a root shell, from which you can dump the filesystem and running processes.
Analysis Methodology
Filesystem Extraction
Most firmware images contain a compressed filesystem. binwalk is the standard tool for identifying and extracting embedded filesystems. It recognizes hundreds of formats including SquashFS, JFFS2, CramFS, and UBIFS.
binwalk -e firmware.bin
This produces a directory tree that you can explore like any Linux filesystem. Look for configuration files, shell scripts, web application code, and binary executables.
Identifying Interesting Components
Once you have the filesystem extracted, focus your analysis on:
- /etc/shadow and /etc/passwd -- Hardcoded credentials are shockingly common in firmware. Default root passwords, service account credentials, and API keys sitting in plaintext configuration files.
- Web server configurations -- Most devices have a web management interface. The configuration and CGI binaries behind it are common vulnerability sources.
- Init scripts -- These show what services start at boot and how they are configured. Look for services listening on all interfaces, running with unnecessary privileges, or using insecure protocols.
- Binary executables -- Custom binaries are where the most severe vulnerabilities typically hide. Focus on anything that processes network input.
Binary Analysis
For compiled binaries, use a combination of static and dynamic analysis.
Static analysis with Ghidra. The NSA open-source reverse engineering tool Ghidra handles the ARM, MIPS, and other architectures common in embedded devices. Load the binary, let Ghidra analyze it, and focus on functions that handle network input, parse data formats, or perform authentication.
String analysis. Running strings on firmware binaries reveals hardcoded URLs, API endpoints, cryptographic keys, debug messages, and format strings. It is a crude technique but consistently productive.
Library identification. Use readelf or Ghidra to identify which shared libraries the binaries link against. Cross-reference these with known vulnerability databases. Many devices ship with years-old versions of OpenSSL, busybox, and curl.
Common Vulnerability Patterns
Command injection through web interfaces. Device web UIs often pass user input directly to shell commands. The CGI handler takes a parameter like hostname and passes it to system("ping " + hostname) without sanitization.
Buffer overflows in network services. Custom network daemons written in C without modern security practices are fertile ground for memory corruption bugs. Focus on parsing functions that handle variable-length input.
Hardcoded cryptographic keys. Devices frequently ship with hardcoded TLS certificates, SSH host keys, or symmetric encryption keys. When every device of a model shares the same key, compromising one device compromises all of them.
Insecure update mechanisms. Firmware update processes that do not verify signatures allow attackers to install malicious firmware. Even signed update mechanisms sometimes have implementation flaws like not checking the signature before applying the update.
Toolchain Summary
| Tool | Purpose | |------|---------| | binwalk | Firmware extraction and analysis | | Ghidra | Binary reverse engineering | | firmwalker | Automated firmware filesystem analysis | | EMBA | Automated firmware security analysis | | QEMU | Emulation for dynamic analysis | | Wireshark | Network traffic analysis | | flashrom | Hardware flash memory reading |
How Safeguard.sh Helps
Safeguard.sh extends supply chain visibility to firmware and embedded devices. Our platform can analyze firmware images to identify embedded open-source components, generate SBOMs for devices that lack them, and continuously monitor for vulnerabilities affecting the libraries inside your firmware. When a new CVE drops for busybox, OpenSSL, or any other common firmware component, Safeguard.sh tells you which devices in your inventory are affected.