Click to access 20SEC3.pdf

By: Hui Peng, Mathias Paye

We present USBFuzz, a portable, flexible, and modular framework for fuzz testing USB drivers. At its core, USBFuzz uses a software-emulated USB device to provide random device data to drivers (when they perform IO operations). As the emulated USB device works at the device level, porting it to other platforms is straight-forward.[…]USBFuzz is available at https://github.com/HexHive/USBFuzz

But, that URL is 404. Maybe in the future?

But, they have an another fuzzer project that sounds interesting:

https://github.com/HexHive/FirmFuzz

 

[Not  firmware-centric, though some firmware (UEFI, for example) use support multiple wireless network protocols).]

Evil Crow RF is a radiofrequency hacking device for pentest and Red Team operations[…]

https://github.com/joelsernamoreno/EvilCrowRF-Beta

See-also: Rolljam:
https://samy.pl/defcon2015/
https://www.wired.com/2015/08/hackers-tiny-device-unlocks-cars-opens-garages/

Anatomy of the RollJam Wireless Car Hack

This repository collects recent papers related to firmware analysis (e.g., IoT and embedded devices, desktop binaries). The list of papers is organized in chronological order.

https://github.com/onehouwong/Firmware-Analysis-Papers

[…This article explains modern and antiquated protections which attempt to prevent attackers who have already achieved root level access from persisting via kernel-mode drivers or firmware implants. […]

https://maxfieldchen.com/posts/2020-05-31-Hardware-Root-Of-Trust-Bios-UEFI.html

https://maxfieldchen.com/raw/firmware-testcases.csv

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.”

https://github.com/yabits/9pfsPkg

More info:
https://9p.io/wiki/plan9/plan_9_wiki/
https://www.kernel.org/doc/Documentation/filesystems/9p.txt
http://www.vitanuova.com/inferno/papers/styx.html

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

https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-requirements-that-apply-to-all-windows-platforms

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:

https://web.archive.org/web/changes/https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-requirements-that-apply-to-all-windows-platforms

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.

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

https://twitter.com/hughsient/status/1263429681182912512

https://twitter.com/hughsient/status/1263429877828669440

https://copr.fedorainfracloud.org/coprs/rhughes/fwupd/

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

there is more research behind the above twitter comment:

 

https://research.nccgroup.com/2020/05/26/research-report-zephyr-and-mcuboot-security-assessment/

See-also:

More info:

Zephyr Project: MCUboot Security Part 1

 

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. […]

https://arxiv.org/abs/2005.12347

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.

https://archive.org/details/github.com-CppCon-CppCon2018_-_2019-04-11_06-45-15

https://archive.org/details/Presentations/the_embedded_device_under_your_desk_uefi_applications_with_modern_cpp/

https://github.com/CppCon/CppCon2018/tree/master/Presentations/the_embedded_device_under_your_desk_uefi_applications_with_modern_cpp

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

 

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.

https://github.com/abazhaniuk/firmware-security-training

https://github.com/enascimento/firmware-security-training

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.

https://arxiv.org/abs/2004.14924

I’m not sure what is up with this driver, if there are now two versions of this UEFI driver source, or if this is a fork. But new network support outside of Tianocore tree is rare enough.

https://github.com/chr15p/bcmgenet_rhel8

See-also:
https://rpi4-uefi.dev/

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.[…]

https://github.com/srinivasnddevops/supermicro_ipmi_handler

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

This isn’t the first SuperMicro IPMI Python project. There are others, for example:
https://github.com/a31amit/supermicro

VisualUefiBios is a utility that lets you run EDK2 UEFI firmware inside QUEMU. This helps geeks provide build environment without messing up with lot of edk2 build commands.

Somewhat similar to QEMU usage inside VisualUEFI, AFAICT.

https://github.com/manojkumarpaladugu/VisualUefiBios

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.”

https://github.com/connormorley/OuterHaven-UEFI_exploitation_and_detection

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

https://github.com/chip-red-pill/crbus_scripts

 

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

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.

https://github.com/qianchendi/UBC

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 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.

https://bitbucket.org/twocanoes/gate-secure-enclave-token-management/src/master/README.md

https://github.com/chip-red-pill/glm-ucode