Pedro Vilaca has created EFI DXE Emulator. It is an EFI DXE phase binaries emulator based on Unicorn. It allows to run EFI DXE binaries inside a Unicorn virtual nachine with a basic interactive debugger that allows to step and interact with the EFI code. It works by implementing basic EFI Boot and Runtime services. Not every service is yet implemented, such as services to load and locate other binaries. This can be done with extra work, since the core code to load binaries already exists, although it needs to be modularized. Can be used to easier reverse some EFI binaries that don’t interact with hardware or graphical EFI interface. The debugger is still pretty basic but allows to view and modify registers and memory, step into calls or over them, and breakpoints. […] Even with all its limitations this is a pretty useful tool for reversing some EFI binaries, improving a lot the reverse engineering process from a static analysis only (for us who don’t have 6k JTAG based EFI debuggers). It’s also a nice showcase of Unicorn potential and limitations. With further development it could be expanded to fuzzing and vulnerability discovery in firmware world.[…]

https://reverse.put.as/2019/10/29/crafting-an-efi-emulator/

https://github.com/gdbinit/efi_dxe_emulator

This AMD flash dumping tool is part of Divination, a Windows-centric tool that reminds me of RWEverything and the CHIPSEC kernel-mode drivers, and similar interfaces:

https://github.com/depletionmode/divination

https://github.com/depletionmode/divination/blob/master/examples/amd_dump_flash.py

Two new tools: dumpACPITables.py and scanACPITables.py:

[…] The plugin is able to extract the ACPI tables from a memory dump in raw and aml format (for description of the parameters see “-h” option in volatility). The files are extracted to a special folder e.g. ./dumpedTables/ and sub-folders are created for every base pointer (RSDP) found in the specified memory region.[…]

https://github.com/mdenzel/ACPI-rootkit-scan

Threatpost excerpt:
Flaws in Das U-Boot affect third-party hardware that uses the universal bootloader as an underlying component. Multiple vulnerabilities have been found in Das U-Boot, a universal bootloader commonly used in embedded devices like Amazon Kindles, ARM Chromebooks and networking hardware. The bugs could allow attackers to gain full control of an impacted device’s CPU and modify anything they choose. Researchers at ForAllSecure found the flaws in U-Boot’s file system drivers. They include a recursive stack overflow in the DOS partition parser, a pair of buffer-overflows in ext4 and a double-free memory corruption flaw in ext4. They open the door to denial-of-service attacks, device takeover and code-execution.[…] ForAllSecure also found five low-severity divide-by-zero bugs, triggered by invalid extended file systems. U-Boot patched the bugs as of its v. 2019.10 release – but devices are likely still vulnerable given that the update process is controlled by the vendor of the device rather than U-Boot itself.[…]

https://lists.denx.de/pipermail/u-boot/2019-July/375516.html

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13106

https://nvd.nist.gov/vuln/detail/CVE-2019-13106#vulnCurrentDescriptionTitle

The UEFI Forum’s recent webinar is now archived and available for on-demand viewing:

Click to access UEFI%20SDL%20Webinar_Final%20Slides%20-%20PDF.pdf

I hope the UEFI Forum also starts doing some webinars for downstream consumers of UEFI firmware (eg: enterprise blue team defenders), nost just upstream firmware engineers.

I hope the UEFI Forum starts to address security a bit better than indirectly referencing CHIPSEC. Current UEFI Forum tests (SCTs) are basically useless when it comes to security. Intel CHIPSEC only works on INTEL processors, not AMD nor ARM processors, so any CHIPSEC reference for UEFI firmware security is USE:LESS for non-Intel systems. There was a partial ARM port [1] but it was never upstreamed. Linaro started work on LUV (which includes CHIPSEC) but hasn’t finished the work[2]. As I understand things, AMD won’t be able to port current CHIPSEC to AMD since current CHIPSEC interface works with public Intel interfaces but would require non-public interfaces to make it work for AMD. Unless something changes, I don’t see how CHIPSEC will ever work on non-Intel platforms. You’d think ARM and/or AMD, or one of their larger customers, would have a vested interest in fixing this problem. 😦 Before you buy a new UEFI system, ask if you have security tools to audit that system, starting with if those tools are ported to that CPU.

[1] https://firmwaresecurity.com/2016/10/11/chipsec-ported-to-arm/

[2] https://firmwaresecurity.com/2015/05/11/linaro-makes-luvos-live-available-for-arm64/

Regarding this Apple EFI malware: https://firmwaresecurity.com/2017/12/03/efivalidate-and-mojo_thor/

most code activity was in 2017, but there’ve been a few changes in the last few weeks, mostly related to the new Apple T2 processor:

https://github.com/rickmark/mojo_thor/commits/master

https://github.com/rickmark/mojo_thor

Apple security readers: it looks like you still need to follow-up with author, see the readme.

PS: The author is also the author of efivalidate:

https://github.com/rickmark/efivalidate

Click to access Firmware_Security_Testing_Methodology_Version1.pdf

Note there is a companion VM:

https://github.com/scriptingxss/EmbedOS

Hmm, I can only find the PDF version of this content, no HTML/wiki version… See-also:

https://www.owasp.org/index.php/OWASP_Embedded_Application_Security

https://scriptingxss.gitbook.io/embedded-appsec-best-practices/

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project

https://www.owasp.org/index.php/IoT_Testing_Guides

A couple of weeks ago I presented a workshop about firmware extraction at the conference Hack.lu in Luxembourg. The goal of this workshop was to provide a very basic knowledge of how to dump a firmware from a device, to allow people to start their own project. Our targets here are two small routers.[…]

https://cookie47948628.wordpress.com/2019/11/05/a-start-in-hardware-hacking/

Click to access snarf-it_pub.pdf

https://cfp.hack.lu/hacklu19/talk/8YR7UM/

Alas, I don’t see this workshop in the list of available videos for this event:

https://peertube.opencloud.lu/videos/trending?a-state=42

US DHS has released version 9.2 of CSET, their CyberSecurity Eval Tool, and it has a one reference to NIST 147 (BIOS security) …but I don’t see that the tool does anything with firmware security. The same SQL table that references NIST 147 also references many other specs.

And it might be Windows-centric (at least only has Windows releases, unsure if the source will build on other OSes, it appears to be tied to IIS and ASP.NET). I enjoy the screenshots of how to use the Windows intaller showing to accept their UNSIGNED code. 🙂

https://github.com/arunmagesh/hw_hacking_cheatsheet

This is an abstract from a Microsoft Ignite session, taking place November 4-8 in Florida:

Managing Surface UEFI BIOS settings with Microsoft Intune
Karan Dhillon, Daniel Gerrity

Introducing Device Firmware Management Configuration Interface (DFCI) as managed through Microsoft Intune for Surface devices. Now you can lock down the BIOS menu as part of Windows Autopilot device setup and manage BIOS settings for all your devices from the Microsoft 365 Device Management Admin Center. Learn how to add DFCI management to your Autopilot deployment, configure settings for boot options and hardware restrictions, and retire devices from DFCI management.

https://www.microsoft.com/en-us/ignite

https://myignite.techcommunity.microsoft.com/sessions/79751

See-also:

https://docs.microsoft.com/en-us/intune/configuration/device-firmware-configuration-interface-windows

https://docs.microsoft.com/en-us/windows/client-management/mdm/uefi-csp

There’s a relatively-new UEFI library, which appears to have been created by Microsoft Project Mu, and later upstreamed to Tianocore. There’s a related extension project as well. This code would be useful for tools analyzing UEFI binaries and source projects.

Tianocore Edk2 PyTool Library (edk2toollib) is a Tianocore maintained project consisting of a python library supporting UEFI firmware development. This package’s intent is to provide an easy way to organize and share python code to facilitate reuse across environments, tools, and scripts. […] The package contains classes and modules that can be used as the building blocks of tools that are relevant to UEFI firmware developers. […] Examples:

• File parsers for edk2 specific file types. These parse the file and provide an object for interacting with the content.
• UEFI specific services for encoding/decoding binary structures.
• UEFI defined values and interfaces for usage in python
• Python wrappers for other system cli tools ( signtool, catalog file generation, inf file generation, etc)
• Python utilities to provide consistent logging, command invocation, path resolution, etc

https://github.com/tianocore/edk2-pytool-library

https://github.com/tianocore/edk2-pytool-extensions

https://github.com/microsoft/mu_pip_python_library

Steve McIntyre has posted a long message to the debian-efi mailing list, with a summary of the “Secure Boot BoF” from the last Debian Conference earlier this year(DebConf19), with a good summary of how Debian implements UEFI Secure Boot:

https://lists.debian.org/debian-efi/2019/10/msg00051.html

https://www.einval.com/~steve/talks/Debconf19-SecureBoot/

More info:
https://wiki.debian.org/SecureBoot

The materials for this recent USB hacking workshop are now online:

https://mini.usbc.tf/

So! A while ago I worked on adding -ftime-trace support for Clang. That landed and shipped in Clang 9.0 in September of 2019, so ＼(＾O＾)／ Looks like it will also be coming to Sony development tools soon (see SN Systems blog post). All that is good, but it works on one compiled file at a time. If you know which source files are problematic in your whole build, then great. But what if you don’t, and just want to see things like “which headers are most expensive to include across whole codebase”? I built a little tool just for that: Clang Build Analyzer. […]

https://github.com/aras-p/ClangBuildAnalyzer

https://aras-p.info/blog/2019/09/28/Clang-Build-Analyzer/

https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profiler-for-Clang/

Purism, a Linux OEM, has a new blog post describing their anti-interdiction service and a how it works with their bootloader:

https://puri.sm/posts/anti-interdiction-services/

There is a UEFI Pixelflut server, using UDPv6 and GOP, written in the Zig language.

Pixelflut is a multiplayer canvas. What happens if you give a bunch of hackers the ability to change pixel colors on a projector screen? Pixelflut is a very simple ASCII based network protocol to draw pixels on a screen. You can write a basic client in a single line of shell code if you want, but you only get to change a single pixel at a time. […]

https://github.com/nrdmn/uefi-pixelflut

More-info:
https://github.com/defnull/pixelflut
https://cccgoe.de/wiki/Pixelflut

Mimoja’s Firmware Toolkit (MFT) is a free and open-source online service and corresponding libraries to: unpack, read, parse, and analyse x86 bios updates and firmware images. Hopefully longterm it will be able to modify images as well. It aims to build the worlds biggest bios (firmware) database to be able to track: Microcode spread, Vulnerability tracking, Binary Blob updates, CPU and mainboard model spread, and Vendor update schedules.

https://firmware.doctor/

https://github.com/Mimoja/MFT

There’s a new ACPI AML interpreter:

Simple AML Bytecode Interpreter (SABI) is a simple bytecode interpreter for the ACPI Machine Language (AML), which is an essential component of the firmware (such as UEFI) on many modern machines. As such, the code allows an operating system to implement full ACPI support in the kernel. […]The directory tools contains userspace programs with limited functionality. The userspace program printns reads an AML table (DSDT or SSDT) from disk and prints the dynamically generated namespace.[…]

https://github.com/mrlhansen/sabi