The Ultimate Guide to Firmware Security Testing: Methods, Tools, and Test Cases

Firmware is the new battleground for cybersecurity. Modern platforms, from personal computers to IoT devices, rely heavily on firmware for initialization and operation. Compromising firmware can allow attackers to bypass OS-level protections and gain persistent, undetectable control over systems.

To address these threats, NIST published SP 800-193. OWASP released the Firmware Security Testing Methodology (FSTM). MITRE developed the ATT&CK Framework for Firmware. Together, they offer a comprehensive roadmap for protecting, detecting, and recovering firmware, while highlighting key risks such as persistent threats, unauthorized firmware updates, rollback vulnerabilities, physical interface exploitation (e.g., SPI, JTAG), and inadequate recovery mechanisms that can leave systems exposed to stealthy and long-term attacks.

In this blog, we'll explore how security researchers can practically test platform firmware resiliency using these trusted standards.

Why Firmware Security Testing Matters

Firmware attacks can permanently disable systems, inject stealth malware, or exfiltrate sensitive data. Unlike typical software, firmware often operates with high privileges and lacks robust security monitoring. Testing firmware resiliency ensures that:

• Unauthorized updates are blocked.
• Firmware corruption is detected early.
• The platform can recover automatically or securely after an attack.
• System integrity is maintained against low-level persistent threats.

Real-world examples like the LoJax UEFI rootkit demonstrate that firmware compromise is a critical national security and enterprise risk. LoJax is the first publicly known UEFI rootkit found in the wild. The APT28 threat group deploys it. It infects a system’s SPI flash memory. It embeds malicious code directly into the motherboard firmware. LoJax allows persistent control over devices even after OS reinstallation. It maintains control even after hard drive replacement.

Core Principles of Firmware Security

Three core pillars form the basis for firmware security:

1. Protection: Only authenticated, authorized updates must be allowed (NIST SP 800-193).
2. Detection: Unauthorized changes must be identified before execution (NIST SP 800-193).
3. Recovery: Systems must restore firmware and critical data to a trusted state after an incident (NIST SP 800-193).

Other Aspects of Firmware Security

• Persistence Mechanisms: Techniques attackers use to implant firmware malware (MITRE ATT&CK).
• Physical Interface Attacks: Exploiting JTAG, SPI, UART (OWASP FSTM).
• Rollback and Downgrade Risks: Prevent loading older, vulnerable firmware (OWASP FSTM)

Test Cases for Deep Firmware Testing

#	Category	Test Case	Expected Result	Method to Execute
1	Protection	Attempt firmware update with invalid signature.	Update must be rejected.	Alter update file and submit via official tool.
2	Protection	Perform legitimate signed firmware update.	Update must succeed.	Use vendor's official firmware update utility.
3	Protection	Try to modify firmware via SPI programming attack.	Modification must be detected and/or blocked.	Use SPI flash programmer (e.g., CH341A).
4	Protection	Attempt to inject a fake UEFI Option ROM.	System must validate and block malicious ROM.	Create fake ROM using UEFITool.
5	Detection	Overwrite recovery partition with tampered firmware.	Device must detect corruption and trigger recovery mode.	Modify recovery image with a programmer.
6	Detection	Tamper with firmware settings (Secure Boot keys).	Change must be detected and logged.	Use Chipsec or Linux efivars to edit variables.
7	Recovery	Simulate full SPI chip erasure.	Platform must trigger re-flash or recovery bootloader.	Erase SPI flash using a programmer.
8	Recovery	Attempt unauthorized firmware rollback (downgrade attack).	Rollback must be prevented unless authorized.	Manually flash older firmware version.
9	Advanced	Evil Maid attack simulation: Physical bootloader compromise.	System must detect anomalies during boot phase and halt or alert.	Modify bootloader via physical access.
10	Advanced	Analyze SPI Flash memory protections (WP# pin test).	Write Protection mechanisms must prevent overwrite.	Use logic analyzer to verify WP# behavior.
11	Advanced	Attempt Direct Memory Access (DMA) attack during boot.	Boot Guard / Memory protections must block unauthorized access.	Use PCILeech with a DMA-capable device.
12	Advanced	Analyze BIOS password bypass vulnerabilities.	Unauthorized access must be blocked even with reset attempts.	Test CMOS reset and password clear procedures.

Tools and Techniques for Low-Level Firmware Testing

• Bus Pirates / Shikra: SPI/I2C bus sniffing and injection
• Dediprog SF100 / CH341A Programmer: Dump and flash SPI flash chips
• PCILeech: DMA attacks and memory tampering
• Binwalk & Firmware Mod Kit: Firmware unpacking and modification
• UEFITool & UEFIExtract: UEFI image exploration and modification
• Ghidra / IDA Pro: Firmware reverse engineering and vulnerability research
• Flashrom: Reading, writing, verifying firmware flash memory

Common Pitfalls to Avoid

• Assuming the SPI Flash chip is hardware-locked by default.
• Ignoring Option ROMs and PXE boot vulnerabilities.
• Overlooking rollback attacks where old vulnerable firmware is restored.
• Missing runtime protections — firmware that starts secure but gets tampered after boot.
• Failing to validate Recovery firmware image integrity.
• Neglecting side-channel or fault injection vulnerabilities.

Conclusion

Testing platform firmware resiliency is no longer optional. It’s a core requirement for securing modern systems against sophisticated adversaries. Security researchers can elevate their firmware testing methodologies by following NIST SP 800-193 guidelines. They can also incorporate OWASP's FSTM practices and MITRE's Firmware ATT&CK Matrix. This approach helps in uncovering vulnerabilities others miss.