FAT-EFI: FAT EFI loader plugin for Hopper Disassembler

This project is a FAT EFI loader plugin for Hopper Disassembler. Apple uses an extension to the standard PE format for EFI binaries to allow FAT EFI binaries that contain both 32 and 64 bits executables. It is very similar to the FAT format, except for a different magic number and for little endianness. This plugin allows to read these FAT EFI binaries with Hopper Disassembler.[…]



Similar: https://github.com/0xc010d/EFIFatBinary.hopperLoader


UEFI-var-in-disk: Inject the UEFI variable in the first sector of hard disk

Bluntly, I’m not sure what this month-old project does yet, the title/tagline sounds more interesting than the usage, and I’ve not done a code review yet.

Inject the UEFI variable in the first sector of hard disk

usage text:
efi2disk version %s\n”, TOOL_VERSION);
usage: efi2disk [options]
-r | –read Read UFEI variable information
-V | –version return version and exit
-h | –help show help/usage



proposal: add Security Version to Linux Shim

Gary Ching-Pang Lin of SuSE has submitted a proposal for Linux kernel and Shim to include a Security Version. In addition to below shim wiki page, there is active discussion on this on the Linux-EFI list.

Security Version

When a vulnerability is found, every distro will release the patch as soon as possible and push it into the update channel. However, since the signature of the old kernel is still valid, the attacker may trick the user to boot the old and insecure kernel to exploit the system. For the system with UEFI Secure Boot, although the admin can add the hashes of the insecure kernels into MokX, it could be burdensome to do this in large scale. Besides, it’s almost impossible to obsolete the kernels before a certain version. Not to mention that the old kernel sometimes might be useful for debugging. To keep the system secure and also flexible, we propose “Security Version”. The basic concept of Security Version is to use a whitelist to record the “version” of the latest known secure linux kernel. If the “version” of the kernel is lower than that in the whitelist, then the kernel is considered as “not secure”. The “version” in the whitelist can only be incremented monotonically unless the user decides to lower it.[…]



PS:  Hmm, Gmane’s linux-efi links aren’t working for me.


efivalidate (and mojo_thor)

Rick Mark has released efivalidate, a macOS-centric Ruby-based EFI checking tool. Also, by same author, Mojo_Thor project has activity. I thought it was a one-time drop, but it is actively being updated:

efivalidate is a ruby utility to take a given input EFI payload from macOS and to compare it against Apple’s validation schema. Being written in ruby this can occur off-box to ensure that the utility itself hasn’t been compromised


Loki / Thor / Mojo are a triad of Apple internal tools and malware that infects the SMC, EFI and macOS of Apple MacBooks. It is believed that direct access to the hardware is gained by re-flashing the Thunderbolt controller (via ThorUtil)




UEFIThreads: EFIDroid’s port of LittleKernel’s thread library for UEFI

UEFI is event-based, not thread-based. Earlier this month, Michael Zimmermann of the EFIDroid project posted a message on the EDK2-devel list about EFIDroid’s thread library support for UEFI, which is based on the Little Kernel threads implementation, and comparing it to the GreenThreads-UEFI project. Edited (footnotified) version of Michael’s message below.

IMO this [GreenThreads-UEFI] library[0] has some crucial problems like changing the TPL during context switching. For my project “EFIDroid” I’ve invested many months analyzing, testing and implementing my own threading implementation based on LK(LittleKernel, a MIT licensed project) threads and get/set -context. The result is a pretty stable implementation which can even be used in UEFI drivers[1]. I’m currently using this lib for my LKL(LinuxKernelLibrary) port to be able to use linux touchscreen drivers in UEFI – so you could say it has been well tested. The only “problem” is that it only supports ARM right now and that the get/set context implementation was copied (and simplified) from glibc which means that this part is GPL code.

From the Little Kernel web site:

Who is using LK?
* LK is the Android bootloader and is also used in Android Trusted Execution Environment – “Trusty TEE” Operating System.
* Newer Android phones have some chance of LK running all the time alongside Linux.
* A few ARM SoC manufacturers use LK as their default bootloader such as DragonBoard 410c based on Qualcomm Snapdragon 410 processor.
* The Fuchsia Operating System’s microkernel, Zircon is based on LK.

[0] https://github.com/Openwide-Ingenierie/GreenThreads-UEFI
[1] https://github.com/efidroid/uefi_edk2packages_EFIDroidLKLPkg/tree/master/UEFIThreads


Full message: 2017-11-02 post on EDK2-devel.