Swift-Apple-EFI-Patcher: Apple EFI Patcher written in Swift with Flashrom Integration

Apple EFI Patcher written in Swift with Flashrom integration. This application was developed out of a need for a simple user-friendly and native macOS based approach to working with Apple EFI roms. The result is an all-in-one application capable of utilizing affordable SPI / eeprom chip reading hardware for reading/dumping from, patching and writing to EFI Rom chips. This application integrates flashrom support in order to communicate with hardware, thus incorporating a lot of the methodologies and current hardware already utilized by technicians.[…]




EFI-Firmware-Password-Simulator: macOS EFI Password Simulator

A new macOS EFI password tool has appeared on Github today
…but I’ve no time today to look at how it works. 😦

CLOSED-SOURCE WARNING: The project includes a few pre-compiled .EFI binaries but no source, so be careful.




macOS EFI Unlocker V1.0 for VMware: allows non-server versions of MacOS to be run with VMWare

The macOS EFI Unlocker removes the check for server versions of Mac OS X verisons:

* 10.5 Leopard
* 10.6 Snow Leopard

allowing the non-server versions of Mac OS X to be run with VMware products. Later versions of Mac OS X and macOS
do not need the modified firmware due to Apple removing the restrictions imposed on 10.5 and 10.6.

EFI Unlocker 1 is designed for the following products:

* VMware Workstation and Player versions 14/15
* VMware Fusion versions 10/11

The checks for the server versions are done in VMware’s virtual EFI firmware and looks for a file called
ServerVersion.plist in the installation media and the installed OS. The patch modifies the firmware to check
for a file present on all versions of Mac OS X called SystemVersion.plist.

The patch uses a tool called UEFIPatch to make the modifications.

Please note you may need to use macOS Unlocker version 3 to run on non-Apple hardware.


Howard Oakley on Booting the Mac

Howard Oakley has yet another new blog post on how Apple EFI works:

Booting the Mac: Will my Mac boot from this disk? A visual guide

There have been multiple recent blog posts on Apple EFI from this author! Eg:






Debian UEFI Secure Boot report from DebConf

DebConf, the Debian conference is happening, and there’s a EFI Secure Boot talk. Slides are listed on the debian-efi list below:




ApfsSupportPkg – Open source apfs.efi loader based on reverse-engineered Apple’s ApsfJumpStart driver

Apple has a new file system, APFS. This causes Hackintosh people lots of grief. There are lots of Apple APFS binaries online, and now there’s this:


Implementation of AppleLoadImage protocol discoverd in ApfsJumpStart Apple driver. This protocol installs in CoreDxe Apple’s firmware. Gives ability to use native ApfsJumpStart driver from Apple firmware

cugu for awesome research according APFS structure
CupertinoNet and Download-Fritz for Apple EFI reverse-engineering
vit9696 for codereview and support in the development

EFI3M: EFI Multi-boot Menu Maker

EFI3M builds a Multi-boot menu for computers with an EFI firmware. The menu will be displayed when booting the computer and allows the user to start any of the installed system from its EFI boot loader: not only Linux distributions, but also BSD distributions, Microsoft Windows, Apple OS X, pretty much any system that has a boot loader in an ESP (EFI System Partition) on any drive of the computer, be it a hard disk, a SSD, a NVMe, whatever. The multi boot menu is installed in an internal ESP as /EFI/efibootmenu/BOOTx64.EFI alongside its configuration file grub.cfg and also, optionally, in /EFI/BOOT/ which is the fall back directory looked at by the firmware, if it is not not already busy. It can also be installed on an USB stick, to allow booting any installed system if for some reason booting would otherwise fail.


Duo Labs: organizations can be “software secure but firmware vulnerable”

Duo Labs, who has EFIgy, an EFI firmware update status tool for Mac, is interviewed by InfoSecurity Magazine on the topic of EFI security:

[…]Although efforts to compromise EFI are most often carried out as part of highly targeted attacks, they remain a major threat to organizations, he warned. […] Smith revealed newly updated research from Duo Security which details shortcomings in Apple’s EFI update processes. Drawing on data collected from 73,000 customer machines, the findings show that 4.2% were running the wrong EFI version – much higher than the 1% or so expected. That rose to nearly 43% for the oldest Mac model on the market, dating back to 2015. The results also showed that organizations could be “software secure but firmware vulnerable.” […] He called on tech firms to introduce “the same degree” of transparency into the firmware update process as they do with software updates. Duo Security chose to study Apple because the firm’s singular ecosystem made it easier to analyze, but Smith warned that failings in the Wintel space are arguably even more acute.[…]



Duo on Apple firmware security (and new EFIgy release)

Nice article on latest Apple changes to firmware security, T2 processor, Secure Boot, etc, are discussed here. Maybe one day Apple will create a similar whitepaper.



EFI-RPM-macros: helps packaging of EFI code into Red Hat RPMs

efi-rpm-macros provides a set of RPM macros for use in EFI-related packages.

The following variables are meaningful on the make command line:

EFI_ESP_ROOT the directory where the EFI System Partition is mounted
EFI_ARCHES the rpm arches %efi will match on
EFI_VENDOR the vendor name for your EFI System Partition directory

The following rpm macros are set:

%efi the arches that EFI packages should be built on, suitable for use with %ifarch
%efi_vendor the vendor name for your EFI System Partition directory
%efi_esp_root the directory where the EFI system Partition is mounted
%efi_esp_efi the full path to \EFI on the EFI System Partition
%efi_esp_boot the full path to \EFI\BOOT on the EFI System Partition
%efi_esp_dir the full path to your vendor directory on the EFI System Partition
%efi_arch the EFI architecture name, e.g. x64
%efi_arch_upper the EFI architecture name in upper case, e.g. X64