9pfsPkg: 9P Client File System for UEFI (Styx)

In the beginning, Bell Labs created “Unix“. Later, then did a follow-up, called “Plan 9“. Later still, Bell Labs (then Lucent) took Plan 9, added some Java-like features and renamed it to “Inferno” (after Dante’s book), then fairly quickly sold it off to Vita Nova.
The Plan 9 file system, “9P“, called “Styx” in Inferno, as in the River from the book, has been implemented in many places. Today, both Plan9 and Inferno OSes continue, and 9P/Styx is implemented in a variety of other OSes, most recently a UEFI version of 9P client.

“9pfsPkg is a Plan 9 file system protocol (9P) client for UEFI. It provides EFI_SIMPLE_FILE_SYSTEM_PROTOCOL interface for network transparent file system operation.”


More info:

Microsoft UEFI requirements for Windows: updated

No idea WHAT has changed, but this Microsoft OEM UEFI guidance document has recently changed:


I wish that this was a Wiki with a History link on it, or in some other way the Microsoft writers would provide some indication of WHAT has changed in the latest release. Important technical documents should include revision history, like a decent technical document. Because the document is HTTP-centric should not let technical writers from providing this.

Archive.org’s Changes feature hangs for this URL, for me:


Besides locally caching and diff’ing the two versions of the HTML document, if there is any other online option to track changes in online HTML documents like this, please leave a Comment on this blog post. Thanks.

Relative Research on UEFI and BIOS

Authors: K R M Parameswar, S Devendra, Dr. P Swarnalatha

New computers use UEFI rather than the standard BIOS. Both UEFI and BIOS are low-level that begins while booting the PC before booting the OS. UEFI provides higher graphics and mouse cursors. Also, UEFI termed as popular solution as it has ability to use bigger hard disks and provides more secure features, faster boot times etc. UEFI provides mouse pointer option which is not available in BIOS. UEFI termed as best replacement for the standard BIOS on PCs. There’s no real way to change from BIOS to UEFI on a current laptop. We’d like to search for new equipment that underpins and incorporates UEFI, as most new PCs do. In design part, UEFI again beats the LEGACY mode. This was obvious because UEFI was built years after DOS and thus had a better technological advancement in that field. Most UEFI usage give BIOS impersonating as such we will get a kick out of the chance to present and boot old working systems that expect BIOS rather than UEFI, along these way they’re backward great “This new specification shows many limitations of BIOS and also limits the disk partition size and therefore the amount of time BIOS takes to complete the tasks”.


Improved fwupd in the works: includes platform firmware security report

Exciting new feature in the works, related to: “fwupdmgr security –force”


NCC Group: Zephyr and MCUboot Security Assessment

Re: https://firmwaresecurity.com/2020/02/20/mcuboot-and-related-code/

there is more research behind the above twitter comment:


Research Report – Zephyr and MCUboot Security Assessment


More info:


Box: Intelligent Faraday Cage: acquires/patches/deploys firmware images

Secure and User-Friendly Over-the-Air Firmware Distribution in a Portable Faraday Cage
Martin Striegel, Florian Jakobsmeier, Yacov Matveev, Johann Heyszl, Georg Sigl

Setting up a large-scale wireless sensor network is challenging, as firmware must be distributed and trust between sensor nodes and a backend needs to be established. To perform this task efficiently, we propose an approach named Box, which utilizes an intelligent Faraday cage (FC). The FC acquires firmware images and secret keys from a backend, patches the firmware with the keys and deploys those customized images over the air to sensor nodes placed in the FC. Electromagnetic shielding protects this exchange against passive attackers. […]


CppCon 2018: Morris Hafner: UEFI Applications With Modern C++

The UEFI Forum’s Tianocore implementation is written in C, with a bit of assembly language. The U-Boot EFI implementation is in C. Most operating systems are written in C (although I hear that the current Windows kernel has been (or is being) rewritten from C to C++). There are a few C++/UEFI projects on Github, including a few C++-friendly versions of the UEFI Forum’s C-centric core header files. And I just noticed there was a talk at CppCon18 on this topic, video and slides below.




PS: To someone with a bit of spare time, who has an interest in UEFI and C++: please port Nmap to UEFI. Thanks!


Intel ATR Training: Security of BIOS/UEFI System Firmware from Attacker and Defender Perspectives

Re: https://firmwaresecurity.com/2017/05/25/intel-atr-releases-uefi-firmware-training-materials/ and https://firmwaresecurity.com/2019/11/22/intel-atr-training-no-longer-publicly-available/

A few years ago, Intel had a group called Advanced Threat Research (ATR), and they created some great training material for Intel BIOS/UEFI security. This training material was used in expensive multi-day pre-conference training by led by Intel and others.

A few Intel reorgs later, and with many of the people moved on (mostly to Eclypsium), and for reasons I am not sure, the training material was taken down, for reason(s) I am not aware of. There’s a comment in the above blog post where someone had a copy of the content, but that Google Drive URL is now 404.

Anyway, I notice there’s at least two current source of this training, if you have not studied this stuff before it is worth reading.

Don’t presume these files will be there in the future, cache a copy locally.



KRDP: Kernel Rootkit Detection and Prevention

Non-Volatile Kernel Root kit Detection and Prevention in Cloud Computing
R.Geetha Ramani, S Suresh Kumar

The field of web has turned into a basic part in everyday life. Security in the web has dependably been a significant issue. Malware is utilized to rupture into the objective framework. There are various kinds of malwares, for example, infection, worms, rootkits, trojan pony, ransomware, etc. Each malware has its own way to deal with influence the objective framework in various ways, in this manner making hurt the framework. The rootkit may be in some arbitrary records, which when opened can change or erase the substance or information in the objective framework. Likewise, by opening the rootkit contaminated record may debase the framework execution. Hence, in this paper, a Kernel Rootkit Detection and Prevention (KRDP) framework is proposed an avert the records. The avoidance system in this paper utilizes a calculation to forestall the opening of the rootkit influenced record as portrayed. By and large, the framework comprises of a free antivirus programming which is restricted to certain functionalities. The proposed model beats the functionalities by utilizing a calculation, in this way identifying the rootkits first and afterward cautioning the client to react to the rootkit tainted record. In this way, keeping the client from opening the rootkit contaminated record. Inevitably, in the wake of expelling the tainted document from the framework will give an improvement in the general framework execution.


supermicro_ipmi_handler: Python library for accessing SuperMicro IPMI

The IPMI is a set of computer interface specifications for an autonomous computer subsystem that provides management and monitoring capabilities independently of the host system’s CPU, firmware (BIOS or UEFI) and operating system. The python-ipmi library provides API for using IPMI protocol within the python environment.[…]


See-also: https://pypi.org/project/python-ipmi/

This isn’t the first SuperMicro IPMI Python project. There are others, for example:

OuterHaven-UEFI_exploitation_and_detection: Windows PowerShell CHIPSEC UEFI exploitation project

A new UEFI exploit project. CHIPSEC-, Windows-, and Powershell-dependent. Includes a verbose PDF.

“A standalone python script leveraging ntdll for UEFI variable enumeration. This uses elements from the “chipsec” toolkit for formatting when extracting NVRAM buffer from the ntdll library function and underlying runtime service.”


crbus_scripts: IPC scripts for access to Intel CRBUS

Re: https://firmwaresecurity.com/2020/05/19/intel-x86-microcode-extracted/



IPC scripts allowing to extract Intel Microcode (msrom) from your own Atom Goldmont platform.

UBC: an UEFI BIOS Configurator based on GRUB2 with setup_var (Windows- and AMI-centric)

Here’s a few UEFI tools I’ve not seen before. But they’re binary-only Windows executables, no source code provided in the Github repro, so be careful if you try to run them. It appears you might need to have an AMI BIOS for some of the tools.


Most laptop manufactures lock down their BIOSes very securely with RSA signing nowadays. This bypasses the dillema of finding a bypass to flash a modified BIOS and instead modifies the NVRAM registers instead.[…]
This tool is based on Windows 7/10 and python 2.7, and works for AMI UEFI BIOS
1. Open Windows console
2. Call AMISetup_IFR.bat <motherboard-bios-file>
3. Call python main.py
4. Copy all files in ‘_Setup’ directory to GRUB2 config directory, overwrite the file if already exists
5. Reboot your computer from GRUB2 disk in UEFI mode

Gate: macOS app that uses Apple T2 Security Enclave


Gate is sample macOS app that contains a CryptoTokenKit (CTK) extension and demonstrates some new ways to work with tokens in macOS:
1. Insert and remove X.509 certificates into the keychain API without a physical smartcard insertion event. Applications can insert certificates into the keychain that are used for cryptographic operations with an embedded CryptoTokenKit extension.
2. Associate a certificate with a ECC private key created in the Secure Enclave on T2-enabled Macs.
3. Authenticate with built-in authentication (Login Window, Screen Saver, System Preferences locks, sudo, ssh, web) using an identity in the Secure Enclave.


Intel x86 microcode extracted


Using Ptychographic X-ray laminography to detect hardware backdoors

Detecting backdoors in hardware is hard. I just noticed this paper from last year:

X-Ray Tech Lays Chip Secrets Bare: Researchers in Switzerland and the U.S. have a non-destructive technique that can reverse engineer an entire chip without damaging it[…]





Ptychographic X-ray laminography can scan an entire chip or zoom in on a particular spot to reveal its circuits.

BaseSAFE: Baseband SAnitized Fuzzing through Emulation

By: Dominik Maier, Lukas Seidel, Shinjo Park

Rogue base stations are an effective attack vector. Cellular basebands represent a critical part of the smartphone’s security: they parse large amounts of data even before authentication. They can, therefore, grant an attacker a very stealthy way to gather information about calls placed and even to escalate to the main operating system, over-the-air. In this paper, we discuss a novel cellular fuzzing framework that aims to help security researchers find critical bugs in cellular basebands and similar embedded systems. BaseSAFE allows partial rehosting of cellular basebands for fast instrumented fuzzing off-device, even for closed-source firmware blobs. BaseSAFE’s sanitizing drop-in allocator, enables spotting heap-based buffer-overflows quickly. Using our proof-of-concept harness, we fuzzed various parsers of the Nucleus RTOS-based MediaTek cellular baseband that are accessible from rogue base stations. The emulator instrumentation is highly optimized, reaching hundreds of executions per second on each core for our complex test case, around 15k test-cases per second in total. Furthermore, we discuss attack vectors for baseband modems. To the best of our knowledge, this is the first use of emulation-based fuzzing for security testing of commercial cellular basebands. Most of the tooling and approaches of BaseSAFE are also applicable for other low-level kernels and firmware. Using BaseSAFE, we were able to find memory corruptions including heap out-of-bounds writes using our proof-of-concept fuzzing harness in the MediaTek cellular baseband. BaseSAFE, the harness, and a large collection of LTE signaling message test cases will be released open-source upon publication of this paper.


Maybe we need to wait until WiSec2020 to see code?