P2IM: Scalable and Hardware-independent Firmware Testing via Automatic Peripheral Interface Modeling

By: Bo Feng, Alejandro Mera, and Long Lu, Northeastern University

Dynamic testing or fuzzing of embedded firmware is severely limited by hardware-dependence and poor scalability, partly contributing to the widespread vulnerable IoT devices. We propose a software framework that continuously executes a given firmware binary while channeling inputs from an off-the-shelf fuzzer, enabling hardware-independent and scalable firmware testing. Our framework, using a novel technique called P2IM, abstracts diverse peripherals and handles firmware I/O on the fly based on automatically generated models. P2IM is oblivious to peripheral designs and generic to firmware implementations, and therefore, applicable to a wide range of embedded devices. We evaluated our framework using 70 sample firmware and 10 firmware from real devices, including a drone, a robot, and a PLC. It successfully executed 79% of the sample firmware without any manual assistance. We also performed a limited fuzzing test on the real firmware, which unveiled 7 unique unknown bugs.



Sentinal Labs: Moving From Common-Sense Knowledge About UEFI To Actually Dumping UEFI Firmware


The first in a series of posts for researchers on how to emulate, debug and fuzz UEFI modules, we begin with a refresher on how to dump SPI flash memory.[…]

Moving From Common-Sense Knowledge About UEFI To Actually Dumping UEFI Firmware

Anvil Ventures: Defeating Secure Boot with Symlink Attacks

By Michael Milvich

Anvil is releasing a white paper today describing a technique that we have found useful to bypass secure boot on a number of embedded Linux devices where the file systems have been split into a signed/protected partition for executables, and a non protection partition to store persistent data.[…]


18 security advisories from Intel

Intel® Thunderbolt™ Controller Advisory

Intel® SSD DCT Advisory

Intel® Distribution of OpenVINO™ Toolkit Advisory

Intel® RealSense™ D400 Series UWP Advisory

Intel® Mailbox Interface Driver Advisory

Intel® NUC Firmware Advisory

Intel® Computing Improvement Program Advisory

Intel® Server Board M10JNP2SB Advisory

Intel® Server Boards, Server Systems and Compute Modules Advisory

Intel® Wireless for Open Source Advisory

Intel® RAID Web Console 3 for Windows* Advisory

Intel® RSTe Software RAID Driver Advisory

Intel® LED Manager for NUC Advisory

Intel® PAC with Arria® 10 GX FPGA Advisory

Intel® Graphics Drivers Advisory

Intel® Server Board Families Advisory

IIntel® PROSet/Wireless WiFi Software Advisory

Intel® Wireless Bluetooth® Advisory


ZMK Firmware: modern, open source keyboard firmware

ZMK is a new keyboard firmware software project. It is based on Zeyphyr RTOS. I guess the main keyboard firmware alternatives are QMK and TMK. [1].


As for security issues, new mechanical keyboards — with either QMK or TMK and I presume also with ZMK — are programmable, with layers and macros, with many opportunites to be a “BadUSB” device. Including WiFi support, not just USB. Let’s hope that peripheral firmware and operating systems learn to treat these powerful peripheral devices with appropriate caution.

[1] https://github.com/qmk/qmk_firmware

PS: I’m hoping to see one of (ZMK, TMK, or QMK) support RISC-V. At this point in it’s evolution, RISC-V would be useful in more maker projects (like mechanical keyboards and #badgelife projects), in addition to FPGA-centric focus, while it evolves to eventually power a real PC. I hope the RISC-V ecosystem puts more effort into competing with Arduino and other ARM dev boards. While I believe ZephyrOS supports RISC-V, the ZMK project doesn’t.


Intel engineering data breach: including firmware internals

Apparently the dump includes info on: Intel ME, Intel FSP, and “Lots of other things”…



Microsoft offers UEFI Secure Boot DBX guidance

Microsoft has a new Knowledgebase Article on UEFI SecureBoot DBX certs:

On July 29, 2020, Microsoft published security advisory 200011 that describes a new vulnerability that’s related to Secure Boot. Devices that trust the Microsoft third-party Unified Extensible Firmware Interface (UEFI) Certificate Authority (CA) in their Secure Boot configuration may be susceptible to an attacker who has administrative privileges or physical access to the device. This article provides guidance to apply the latest Secure Boot DBX revocation list to invalidate the vulnerable modules. Microsoft plans to push an update to Windows Update to address this vulnerability after further testing in 2021.[…]



There really should be more technical information provided about the revoked/otherwise bad certs in the DBX files.

uefi-code-defn: a third UEFI plugin for Visual Studio Code

Re: https://firmwaresecurity.com/2019/11/23/edk2-vscode-visual-studio-code-plugin-for-edkii-files/ and https://firmwaresecurity.com/2019/10/01/musupport-a-vs-code-extension-to-support-project-mu/:

there is a third UEFI plugin for Visual Studio Code, from Abhishek Sharma of Microsoft:

This is a VS code extension which helps points to definition of keywords in the UEFI code like PCDs, GUIDs, etc.


BootHole: GRUB UEFI Secure Boot vulnerability.

In case you’ve not been reading the news, a vulnerability has been found in GRUB:


fujitsu-redfish-samples: Fujitsu iRMC Redfish Scripting Samples

New Python Redfish samples beyond the ones in Fujitsu’s project. Half a dozen scripts, including one that does a BIOS update.

Sample Python scripts to manage Fujitsu integrated Remote Management Controller (iRMC) via Redfish in Fujitsu Server PRIMERGY.




There are a few blog posts on Fujitsu Redfish here:

A Modular End-to-End Framework for Secure Firmware Updates on Embedded Systems

By: Solon Falas, Charalambos Konstantinou, Maria K. Michael

[…]In this paper, we present a framework for secure firmware updates on embedded systems. The approach is based on hardware primitives and cryptographic modules, and it can be deployed in environments where communication channels might be insecure. The implementation of the framework is flexible as it can be adapted in regards to the IoT device’s available hardware resources and constraints. Our security analysis shows that our framework is resilient to a variety of attack vectors. The experimental setup demonstrates the feasibility of the approach. By implementing a variety of test cases on FPGA, we demonstrate the adaptability and performance of the framework. Experiments indicate that the update procedure for a 1183kB firmware image could be achieved, in a secure manner, under 1.73 seconds.


Intel/ARM/Microsoft/Apple platform security checklists: overlaps and gaps?

So, there are a handful of tools for checking for hardware/firmware security issues. Each tool has a separate list of security checks, half of which are publicly-viewable. With gaps from some hardware and OS vendors. I’m wondering how much overlap there is between these security lists, that might be useful to port and find additional security issues.

* Intel has CHIPSEC, for testing the hardware and firmware for security issues. It works on Intel x86 and Intel x64, not AMD AMD64. It works on Mac, Windows, and Linux, and UEFI. Public can run this on their own device.


* ARM has SBSA-ACS, for testing hardware and firmware security issues.It works on ARM AArch64 ‘enterprise’ devices. Unclear if there is a technical distinction for non-enterprise AArch64 device use. Not AArch32. It works on UEFI. Intended for vendor use on development machines, not consumer devices (“To prevent the leakage of secure information, it is strongly recommended that the ACS test suite is run only on development platforms. If it is run on production systems, the system should be scrubbed after running the test suite.”).


* Apple has eficheck for macOS. It works on Intel x64, and I am guessing that it’ll also work on future ARM processors. The list of security tests it makes is unknnown, the documentation is lacking.

* Microsoft has Defender AV (which has UEFI support) for Windows.  I presume (but do not know) it works on all ISAs that Windows does, so maybe coverage on Intel, AMD, and ARM. The list of security tests it makes is unknnown, the documentation is lacking.

* AMD has nothing. Except for Microsoft Defender (for Windows users only).

* Linux has nothing. Except for Intel CHIPSEC on Intel systems.

I wonder about the delta between these 4 security lists. I wish there was more information from Microsoft and Apple on the specific tests their tools make. Are there any from one list that should also be tested on the other lists, and vice versa? Obviously, some entries are platform-centric, but there are others that might not be.

Any professors out there: please suggest a grad student do some research on the Intel and ARM security lists. Thanks.

FWTS ported to RISC-V

Re: https://firmwaresecurity.com/2016/05/08/uefi-ported-to-risc-v/

Atish of Western Digital is using FWTS to test the RISC-V port of UEFI on Linux.



Colin of Canonical has updated FWTS to have a RISC-V port.

Potential Verified Boot support in Barbara IoT (new OS)

There is a relatively-new operating system called “Barbara IoT”, based out of Madrid Spain, which is new to my daily “Verified Boot” searches.

Their security page mentions “verified boot”. Given the vagueness of their web site, I can’t say if this is Linux/Android/Chrome Verified Boot or something else. Unclear what flavor(s) of platform firmware the OS interacts with.

“Raise the security level of your devices with verified boot, data encryption and no exposed network services”

Have not found the source to the OS yet, I’m guessing closed-source. Their web site is pretty closed: it requires you to submit name/email contact info to view any data on their OS. Their home page link to their Developers page is broken.



View at Medium.com

“Raise the security level of your devices with verified boot,”

IBM: Policy-based governance in a trusted container platform

IBM has a new article discussing how they secure their cloud, discussing security technologies such as TPM, Intel TXT, and Intel BootGuard:


Policy-based governance in a trusted container platform

Project uses Intel Security Libraries for Data Center (Intel SecL-DC), a library that discover, attest, and utilize Intel security features, to enable critical cloud security and confidential computing use-cases.


IETF draft-richardson-secdispatch-idevid-considerations-01: Security and Operational considerations for manufacturer installed keys and anchors

[There was a time when I had bandwidth to read all new IETF RFCs and I-Ds that came out each day. Sigh…]

There is a new IETF Internet Draft from the “anima Working Group” about storing private keys in embedded devices. Sandelman Software Works and Huawei Technologies are authors. There are other documents from this working group as well.

This document provides a nomenclature to describe ways in which manufacturers secure private keys and public trust anchors in devices.