Disables the Windows Platform Binary Table (WPBT) in your firmware. This program use a non-permenant, non-destructive method to remove the table from system memory, so it should be executed every time the computer is rebooted before Windows bootloader starts.

https://github.com/Jamesits/dropWPBT

 

 

The sample runtime DXE driver (UEFI driver) monitoring access to the UEFI variables by hooking the runtime service table in C and Rust.

https://github.com/tandasat/UefiVarMonitor

 

Polypyus learns to locate functions in raw binaries by extracting known functions from similar binaries. Thus, it is a firmware historian. Polypyus works without disassembling these binaries, which is an advantage for binaries that are complex to disassemble and where common tools miss functions. In addition, the binary-only approach makes it very fast and run within a few seconds. However, this approach requires the binaries to be for the same architecture and have similar compiler options. Polypyus integrates into the workflow of existing tools like Ghidra, IDA, BinDiff, and Diaphora. For example, it can import previously annotated functions and learn from these, and also export found functions to be imported into IDA. Since Polypyus uses rather strict thresholds, it only found correct matches in our experiments. While this leads to fewer results than in existing tools, it is a good entry point for loading these matches into IDA to improve its auto analysis results and then run BinDiff on top.

https://github.com/seemoo-lab/polypyus

Hmm, IDA, Ghidra are supported. I don’t see Radare2. 😦

Alex has written a new LZMA parser library, that works on Linux and Windows.

Dealing with the current COVID-19 crisis, most infosec men have taken it upon themselves obsess over a new pet –sourdough — and learn all about its growth, rise, consistency, humidity, and color. I've chosen to obsess over compression algorithms — LZMA in particular. 1/4 pic.twitter.com/R9wzDKTKl3

— Alex Ionescu (@aionescu) April 15, 2020

The Minimal LZMA (minlzma) project aims to provide a minimalistic, cross-platform, highly commented, standards-compliant C library (minlzlib) for decompressing LZMA2-encapsulated compressed data in LZMA format within an XZ container, as can be generated with Python 3.6, 7-zip, and xzutils

https://github.com/ionescu007/minlzma

Dell has started to ship their UEFI/BIOS updates using PFS Revision 2 container format. I've added support for it at the latest Dell PFS BIOS Extractor v4.0 release. https://t.co/8CSPFyyoBG

— Plato Mavropoulos (@platomaniac) April 21, 2020

“Dell has started to ship their UEFI/BIOS updates using PFS Revision 2 container format. I’ve added support for it at the latest Dell PFS BIOS Extractor v4.0 release.”

https://github.com/platomav/BIOSUtilities

BootKeeper: Validating Software Integrity Properties on Boot Firmware Images

Ronny Chevalier, Stefano Cristalli, Christophe Hauser, Yan Shoshitaishvili, Ruoyu Wang, Christopher Kruegel, Giovanni Vigna, Danilo Bruschi, Andrea Lanzi

Boot firmware, like UEFI-compliant firmware, has been the target of numerous attacks, giving the attacker control over the entire system while being undetected. The measured boot mechanism of a computer platform ensures its integrity by using cryptographic measurements to detect such attacks. This is typically performed by relying on a Trusted Platform Module (TPM). Recent work, however, shows that vendors do not respect the specifications that have been devised to ensure the integrity of the firmware’s loading process. As a result, attackers may bypass such measurement mechanisms and successfully load a modified firmware image while remaining unnoticed. In this paper we introduce BootKeeper, a static analysis approach verifying a set of key security properties on boot firmware images before deployment, to ensure the integrity of the measured boot process. We evaluate BootKeeper against several attacks on common boot firmware implementations and demonstrate its applicability.

https://arxiv.org/abs/1903.12505

Re: https://firmwaresecurity.com/2017/10/30/universal-ifr-extractor/ and https://firmwaresecurity.com/2015/07/07/two-uefi-form-tools-plus-one-uefi-c-module-complexity-tool/ :

There’s another Universal-IFR-Extractor fork …I think. The original one was Windows-centric, I think motivation for some forks was from non-Windows users. Today’s new fork might have some new/interesting features or — I didn’t study the code — it might be a fork of one of the other Linux-friendly forks.

Visual Forms Representation (VFR) is the “source code” to UEFI forms-based app, IVR is the Internal Forms Representation that is included in binaries, and of interest to reverse engineers and modders. An example of how a modder uses it:

https://github.com/roncapat/W230SD-Unlocked-AMI-BIOS

I don’t think the security researcher community has done much research in IFR-based attacks to this binary format that includes multiple complex structures in C that impact control flow.

Original tool: https://github.com/donovan6000/Universal-IFR-Extractor

Forks of tool:
https://github.com/LongSoft/Universal-IFR-Extractor

https://github.com/tomrus88/Universal-IFR-Extractor

https://github.com/therealgudv1n/Universal-IFR-Extractor-Linux (this latest one)

I suspect one of the more recent forkers didn’t first check if there was another Linux-friendly fork already exists. Besides this tool “family”, there’s also a few other IFR tools, one is:

IfrViewer: Viewer for IFR structures

I’m pretty sure I blogged on another one, but I’m not great at adding tags to blog posts, so I can’t find it at the moment. 😦

Windows UEFI bootkit that loads a generic driver manual mapper without using a UEFI runtime driver.

https://github.com/btbd/umap

There is a fork of GRUB that lets BIOS modders access the BIOS using “CFG Lock”.

I didn’t know about “CFG Lock” before today; it appears common knowledge in the modding community. Does CHIPSEC check for this? If not, should it?

https://github.com/datasone/grub-mod-setup_var

There’s another Github project, documentation-only guide for some Insyde BIOS users, which relies on this GRUB fork.

Little guide on how to show all the settings in clevo insyde_h20 uefi.
https://github.com/eebssk1/clevo-insyde-uefi-settings-show-all

With tools like SafeBIOS, @vmware @dell @crowdstrike enable secure foundations for customers’ workforce transformation strategies on the world’s most secure commercial PCs #delltechworld #dataprotection https://t.co/BMSiy9DRhA #Iwork4Dell pic.twitter.com/47LJClvcRy

— Michael Borst (@miborst) May 24, 2019

[…]Dell Technologies is enhancing its Dell SafeBIOS offering with a new utility for off-host BIOS verification and integrations with CrowdStrike, Secureworks and VMware Workspace ONE for off-host BIOS verification with their tools.[…]

https://blog.dellemc.com/en-us/bios-verification-protects-pc-firmware-against-threats

https://twitter.com/qrs/status/1250095637535887367

Another reason why firmware should be Open Source, not Closed Source.

https://airbreak.dev/

https://github.com/osresearch/airbreak

Re: https://firmwaresecurity.com/2020/04/14/6-new-security-advisories-from-intel-2/

I guess I need to wait now for the monthly blog post to go along with the list of advisories. I guess that’s good, there’s now a blog post with hopefully more information.

Today we released a technical whitepaper concerning CSME and CVE-2019-0090 along with 6 security advisories.https://t.co/qOQWXQ17RX

— Jerry Bryant (@jerry_Intel) April 14, 2020

https://blogs.intel.com/technology/2020/04/ipas-security-advisories-for-april-2020/#gs.3ex7zc

Click to access cve-2019-0090-whitepaper.pdf

[1/3] Intel has published 15 pages about CVE-2019-0090 [see: https://t.co/2xQS13mT0j].
In my opinion, this document can give a false sense of security:
1. For attack we did NOT use Intel-SA-00086; pic.twitter.com/nRHFIDZZjT

— Maxim Goryachy (@h0t_max) April 14, 2020

[2/3]
2. Hardware based Anti-rollback isn't protected again vulnerabilities in ROM;
3. Attacker can be exploited this issue, not only through ISH (it is confirmed by Intel engineers); pic.twitter.com/UTuEY7j1m7

— Maxim Goryachy (@h0t_max) April 14, 2020

[3/3]
4. Key may be extracted because we have code execution BEFORE erasing keys and in some version of ME attacker can re-calculate keys for new SVN;
5. Table Impact of "Impact CVE…" looks like facts manipulations to me because this issue not related with CVE-2017-5705/7. pic.twitter.com/w5A4Tsn5ll

— Maxim Goryachy (@h0t_max) April 14, 2020

Windows-centric. Visual Studio-centric. Intel-centric. Mostly C, a bit of asm.

No docs.

Most of the code on this new Github project is 10 hours old, but some of files are 10 months old.

“\DosDevices\PlatboxDev” device is created, and some IOCtls are enabled. List of IOCTLs roughly resembles the CHIPSEC kernel mode driver API.

ISSUE_SW_SMI
EXECUTE_SHELLCODE
READ_PCI_HEADER
READ_PCI_BYTE
READ_PCI_WORD
READ_PCI_DWORD
WRITE_PCI_BYTE
WRITE_PCI_WORD
WRITE_PCI_DWORD
GET_PCI_BAR_SIZE
READ_PHYSICAL_MEM
WRITE_PHYSICAL_MEM
READ_MSR
WRITE_MSR
PATCH_CALLBACK
RESTORE_CALLBACK
REMOVE_ALL_CALLBACKS_HOOKS

https://github.com/n3k/Platbox

INTEL-SA-00363: Intel NUC Firmware Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00363.html

INTEL-SA-00359: Intel Binary Configuration Tool for Windows Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00359.html

INTEL-SA-00351: Intel Modular Server Compute Module Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00351.html

INTEL-SA-00344: Intel Driver and Support Assistant Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00344.html

INTEL-SA-00338: Intel PROSet/Wireless WiFi Software Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00338.html

INTEL-SA-00327: Intel Data Migration Software Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00327.html

AMI announces new AMI FirST Firmware Security Testing Suite for x86/x64 architectures: https://t.co/xqUisvueIR pic.twitter.com/yZSpFrJA2k

— AMI (@AMI_PR) April 13, 2020

Abridged first paragraph of PR:

AMI announcees AMI FirST™ Firmware Security Testing Suite, a set of integrated security test tools that provide dependable verification of production firmware security for x86/x64 architectures. AMI FirST tests stay current with the latest critical developments in mitigating firmware security threats and CHIPSEC for comprehensive testing, vulnerability protection and prevention of security defect regression.[…]

https://ami.com/en/news/press-releases/ami-announces-new-ami-first-firmware-security-testing-suite-for-x86x64-architectures/

https://ami.com/en/products/security-services-and-solutions/ami-first-firmware-security-testing/

Tails 4.5 is out: https://t.co/WOQYwgVYE3

It adds support for Secure Boot and fixes critical vulnerabilities in Tor Browser. pic.twitter.com/pD02YQ3vcE

— Tails (@Tails_live) April 7, 2020

https://tails.boum.org/news/version_4.5/#index1h2

More info:
https://tails.boum.org/blueprint/UEFI_Secure_boot/
https://tails.boum.org/contribute/design/UEFI/
https://tails.boum.org/blueprint/UEFI/

Click to access 24593.pdf

#AMD refreshed the "AMD64 Architecture Programmer's Manual Volume 2: System Programming" 24593.pdf to 3.33 with Secure Nested Paging (SEV-SNP)https://t.co/nndFzrwnqA pic.twitter.com/fE6lRCO2mW

— InstLatX64 (@InstLatX64) April 9, 2020

More info:
https://www.youtube.com/watch?v=yr56SaJ_0QI

Click to access 24593.pdf

Just created a mailing list of fuzzing engines' devs and topic researchers, it's open for all, so fyi – https://t.co/ZablFbllnR ps: some fuzzers' authors have already joined). pps: it's not really a help forum.

— Robert Swiecki (@robertswiecki) April 5, 2020

https://groups.google.com/forum/#!forum/fuzzing-discuss

I just noticed that @colinoflynn and @jzvw will release a book on #hardware #hacking through @nostarch ! 😃
👉 https://t.co/gRi1fMzIY4#hype

— Requiem (@Requiem_fr) April 8, 2020

The Hardware Hacking Handbook
by Colin O’Flynn and Jasper van Woudenberg
July 2020 (Estimated), 300 pp.

The Hardware Hacking Handbook is a deep dive into hardware attacks on embedded systems, perfect for anyone interested in designing, analyzing, and attacking devices. You’ll start with a crash course in embedded systems and threats to them, as well as hardware interfaces and how to set up a test lab, all while learning invaluable theoretical background. Real-life examples and hands-on labs throughout allow you to explore hardware interfaces and complete various side channel or fault attacks on real devices. You’ll learn fault injection attacks and methods like voltage glitching, clock glitching, and optical and electromagnetic fault injection, side channel power analysis, and differential fault analysis.

https://nostarch.com/hardwarehacking

Roughly like the kernel mode driver that CHIPSEC uses. With ACPI-parsing code. And Windows-centric.

https://github.com/nickelshh/WindowsHwAccess