# Firmware Security and Analysis
Firmware is the low-level software embedded directly into hardware devices that controls how the device initializes, communicates, and operates. Unlike an operating system or application, firmware typically runs before any general-purpose OS loads and provides the foundational instruction set that the hardware uses to function. It lives in non-volatile flash memory, meaning it persists across power cycles and is not erased when a device is factory reset.
The devices running firmware cover an enormous range of modern infrastructure: home and enterprise routers, industrial programmable logic controllers (PLCs), IoT sensors, medical devices, network switches, HVAC controllers, satellite modems, and smart meters. The common thread is that these are purpose-built devices running a fixed software stack on constrained hardware, often without the update mechanisms or security monitoring that general-purpose servers and workstations receive.
Firmware security analysis is the discipline of examining firmware images to identify vulnerabilities, verify integrity, and confirm that a device is running only the software it is supposed to run. The inverse, firmware attack, involves exploiting weaknesses in firmware to achieve persistent, low-level compromise of a device. From an attacker's perspective, firmware-level control is the highest form of persistence: it survives OS reinstallation, most factory resets, and is invisible to endpoint detection and response (EDR) tools that operate at the OS layer.
Within CDA's Planetary Defense Model, firmware security sits firmly in VSD (Vulnerability and Surface Defense), the ocean layer. The Continuous Surface Reduction (CSR) methodology asks: "Every surface you expose is a surface we eliminate." A fleet of devices running unanalyzed, unverified firmware is a surface whose full scope is unknown. You cannot reduce what you cannot measure.
Before analysis can begin, the firmware image must be obtained. There are four primary acquisition paths, each suited to different situations.
Vendor update packages. The least invasive method. Many manufacturers publish firmware updates on their support portals. These packages are ZIP archives, TAR files, or proprietary formats containing the actual firmware binary. Unpacking them often requires nothing more than standard archive tools or a purpose-built extractor. The limitation is that vendor packages may be compressed, encrypted, or signed, requiring additional steps before the raw binary is accessible.
UART debugging interface. UART (Universal Asynchronous Receiver-Transmitter) is a serial communication interface built into most embedded devices for diagnostic and debugging purposes. Manufacturers use it during development and often leave it accessible on the PCB in production hardware, protected only by the physical case. An analyst who opens the device and connects a UART adapter (3.3V or 5V logic, depending on the device) to the exposed TX/RX/GND pins can gain access to a root shell or bootloader console. From there, the running filesystem can be dumped directly. This technique requires physical access and basic hardware skills but produces the cleanest possible firmware image: the exact software running on the device, not a vendor-packaged version.
JTAG (Joint Test Action Group). JTAG is an IEEE 1149.1 standard hardware debugging interface that provides direct access to the processor's internal state and memory, including the ability to halt execution, read registers, and dump memory contents. Originally designed for PCB testing and semiconductor debugging, JTAG is widely used by firmware analysts because it allows extraction of firmware even from devices that have disabled other interfaces. JTAG headers are often depopulated on production boards (the pads are present but no header pins are soldered), requiring soldering skill to access. The payoff is complete memory visibility, including RAM contents during live operation.
SPI flash chip reading. Many embedded devices store firmware in a dedicated SPI (Serial Peripheral Interface) flash chip. An analyst can physically remove the flash chip from the PCB (hot air rework station) or clip onto it in-circuit using a SOIC clip, then connect it to a flash programmer (Bus Pirate, FlashROM-compatible hardware, or a dedicated device programmer). The programmer reads the raw flash contents directly, bypassing all device software and encryption that operates at a higher layer. This method is used when other interfaces are locked down and the flash chip is accessible.
With a raw firmware binary in hand, analysis follows a structured workflow.
Identification and extraction. The first step is identifying what the binary contains. Firmware images are rarely a single flat binary; they typically contain a bootloader, a kernel, a compressed filesystem, and sometimes multiple filesystem partitions packed together. Binwalk is the standard open-source tool for this phase. Binwalk scans the binary for known file signatures (filesystem headers, compression markers, certificate structures, encryption indicators) using a signature database similar to how a file identification utility works, but tuned for firmware. A binwalk scan of a router firmware image might reveal: a U-Boot bootloader header at offset 0x000000, a Linux kernel image at offset 0x040000, and a SquashFS filesystem at offset 0x200000. Binwalk can then extract each component automatically.
Filesystem analysis. Once the filesystem is extracted, the analyst has access to the device's directory tree: configuration files, init scripts, web server files, shared libraries, and application binaries. This phase often yields immediate, high-value findings with no reverse engineering required. Common discoveries include: hardcoded credentials in configuration files or init scripts, private keys and certificates bundled in the firmware, debug interfaces left enabled (Telnet, SSH with default credentials, undocumented web API endpoints), and outdated library versions with known CVEs.
Binary reverse engineering. For vulnerabilities that require deeper analysis, individual binaries are loaded into a disassembler and decompiler. Ghidra, released by the NSA as open-source software in 2019, provides a full reverse engineering environment with support for a wide range of processor architectures common in embedded systems (MIPS, ARM, PowerPC, x86). Ghidra's decompiler converts assembly code to pseudo-C, making it feasible to read program logic without deep assembly expertise. IDA Pro is the commercial alternative, widely regarded as the industry standard for professional firmware analysis, with mature support for embedded architectures, a debugger, and an extensive plugin ecosystem (including Hex-Rays for decompilation).
Vulnerability identification. The analyst examines the binary code of specific programs for vulnerability classes common in embedded software: stack buffer overflows (firmware often lacks modern exploit mitigations like stack canaries, ASLR, or NX), command injection vulnerabilities in web interface parameter handling (a CGI binary that passes user-controlled input directly to a shell command), hardcoded credentials (strings like "admin/admin" or "root/root" embedded in authentication logic), and path traversal vulnerabilities in file serving components.
Static analysis identifies potential vulnerabilities; dynamic analysis confirms exploitability. Firmware can often be emulated outside the original hardware using QEMU, a general-purpose machine emulator with support for ARM and MIPS architectures. The FIRMADYNE project and the Firmware Analysis and Comparison Tool (FACT) provide frameworks for automated firmware emulation and analysis, allowing analysts to run firmware web interfaces in an emulated environment and interact with them as an attacker would, without requiring the physical device.
Emulation has limitations: peripherals, custom hardware, and proprietary kernel modules may not emulate correctly, causing the firmware to fail to boot or behave differently than on real hardware. For production-grade validation of critical vulnerabilities, testing on real hardware remains the gold standard.
The security significance of firmware vulnerabilities is asymmetric. A vulnerability in a web application can be patched by pushing an update to a server. A vulnerability in the firmware of a router deployed in 4 million homes requires those devices to check for an update, download it, and apply it, a process that historically achieves update rates of 10 to 30 percent even for critical vulnerabilities. The rest remain permanently vulnerable.
The persistence problem is more severe. An attacker who plants a backdoor in device firmware survives reboots, factory resets (which typically reflash only the user configuration layer, not the firmware), and OS reinstallation (irrelevant for devices that have no general-purpose OS). Enterprise EDR tools, which operate at the OS process level, have no visibility into firmware-layer code. A firmware-resident implant is effectively invisible to the security stack that most organizations rely on for detection.
The Mirai botnet (2016) demonstrated the scale of this problem. Mirai scanned the internet for IoT devices with default credentials (found through firmware analysis), logged in via Telnet, and enrolled them in a DDoS botnet that peaked at over 1 Tbps of attack traffic. The vulnerabilities Mirai exploited were not complex. They were default credentials discovered by analyzing vendor firmware images, trivially accessible to anyone with binwalk and 20 minutes.
Supply chain risk amplifies the problem. The 2020 SolarWinds compromise demonstrated that attackers willing to invest in targeting the software build process can deliver malicious code to thousands of organizations simultaneously through trusted update channels. Firmware supply chain compromise is the same vector applied at a lower layer. A nation-state actor who compromises a firmware vendor's signing key or build pipeline can deliver malicious firmware through official update mechanisms, with no indication of tampering visible to the device operator. The Unified Extensible Firmware Interface (UEFI) implants attributed to the Equation Group and documented by Kaspersky Lab in 2015 demonstrated that this attack class exists and has been used in targeted operations.
The regulatory environment is beginning to reflect these risks. The FDA's 2023 cybersecurity guidance for medical devices explicitly requires firmware security documentation and update capability as conditions for device clearance. The EU's Cyber Resilience Act, which takes effect across member states starting in 2027, imposes security requirements on all products with digital components, including firmware, and mandates software bill of materials (SBOM) documentation.
Binwalk (open source, https://github.com/ReFirmLabs/binwalk): Firmware extraction and analysis. Signature scanning, entropy analysis (high entropy sections indicate encryption or compression), and recursive extraction. Binwalk's entropy visualization identifies encrypted regions, which signal the need for additional analysis to determine whether keys are stored in the firmware or derived from external sources.
Ghidra (open source, NSA): Disassembly and decompilation for all architectures common in embedded systems. Supports collaborative analysis (multiple analysts working the same project), scripting via Python or Java, and a plugin ecosystem including tools for firmware-specific tasks such as RTOS identification and symbol recovery.
IDA Pro (commercial, Hex-Rays): The commercial standard for professional reverse engineering. Mature debugger, interactive graph view, and Hex-Rays decompiler. Industry-standard tooling for high-stakes firmware analysis.
QEMU (open source): Machine emulator supporting ARM, MIPS, x86, PowerPC. Foundation for firmware emulation workflows.
FIRMADYNE: Research framework for automated emulation and dynamic analysis of Linux-based firmware.
Firmware Analysis and Comparison Tool (FACT): Automated firmware analysis platform with plugin architecture, vulnerability scanning, and binary comparison across firmware versions.
Hardcoded credentials: Authentication logic that accepts a fixed username and password compiled into the binary, often a development backdoor left in production. These are discoverable via static string search.
Stack buffer overflows: C code without bounds checking writing user-controlled data to stack buffers. Embedded firmware frequently lacks modern stack protections. A vulnerable web server CGI handler processing a URL parameter of arbitrary length is a classic pattern.
Command injection: Web interface parameters passed to shell commands without sanitization. A ping utility that constructs a command string as "ping " + user_input without validation allows an attacker to append ";" and an arbitrary command.
Cryptographic weaknesses: Static private keys bundled in firmware (meaning all devices share the same private key), self-signed certificates with no validation, and weak random number generation from predictable entropy sources.
SquashFS and JFFS2 are the most common compressed read-only and read-write filesystems found in Linux-based firmware. CramFS, YAFFS, and UBIFS appear in specific device categories. Binwalk handles extraction for all common types; unusual or proprietary filesystems require additional tooling or custom scripts.
Firmware security aligns directly with CDA's CSR (Continuous Surface Reduction) methodology within VSD. The challenge CSR addresses is that most organizations do not know the full scope of their attack surface, including the firmware running on every device connected to their network. You cannot reduce a surface you have not inventoried.
CDA's approach to OT and IoT engagements begins with a firmware surface mapping: enumerate every device, identify the firmware version running on each, cross-reference against known CVE databases and vendor security advisories, and flag devices running firmware with no update path (end-of-life hardware). This inventory becomes the baseline against which CSR tracks reduction progress.
For organizations with industrial control system (ICS) or operational technology (OT) environments, firmware security is not optional, it is foundational. PLC firmware, embedded HMI software, and field device firmware are frequently never analyzed, never updated, and never monitored. The attack surface they represent is significant, and the consequences of compromise in these environments extend beyond data loss to physical process disruption.
CDA engagements that include firmware analysis deliver findings that cannot be obtained through any other method: vulnerabilities that have no CVE entry because they have never been publicly analyzed, backdoors present in devices deployed for years, and supply chain risk indicators that inform procurement decisions. These findings live in VSD and feed directly into the Shield's VSD domain score.
Costin, Andrei, et al. "A Large-Scale Analysis of the Security of Embedded Firmwares." USENIX Security Symposium, 2014. https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/costin
NSA/CISA. "Stop Ransomware: BlackMatter Ransomware." CISA Alert AA21-291A, 2021. https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-291a
Kaspersky Lab. "Equation Group: Questions and Answers." Kaspersky GReAT, 2015. https://securelist.com/equation-the-death-star-of-malware-galaxy/68750/
FDA. "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions." FDA Guidance, 2023. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
NIST. "Guidelines for Managing the Security of Mobile Devices in the Enterprise." NIST SP 800-124, 2013. https://csrc.nist.gov/publications/detail/sp/800-124/rev-1/final
CDA, LLC. Planetary Defense Model Master Reference. CDA Canon, 2026.