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.


mOSL: Bash script to audit and fix macOS High Sierra (10.13.x) security settings

Settings that can be audited/ fixed:

enable automatic updates
enable gatekeeper
enable firewall
enable admin password preferences
enable terminal secure entry
disable firewall builin software
disable firewall downloaded signed
disable ipv6
disable mail remote content
disable remote apple events
disable remote login
set airdrop contacts only
set appstore update check daily
check SIP
check kext loading consent
check EFI integrity
check filevault
check firmware password set



Apple: new/updated T2 chip and Secure Boot support articles

Re: https://firmwaresecurity.com/2018/07/12/apple-releases-new-systems-with-t2-chip-and-uefi-secureboot/ and


the latter Apple support article on Secure Boot has been updated recently:

About Secure Boot


Mac computers that have the Apple T2 chip


Apple releases new systems with T2 chip and UEFI SecureBoot


Apple macOS 10.13.6: UEFI SecureBoot support for iMac Pro

Re: https://firmwaresecurity.com/2017/12/13/apple-secure-boot/ and https://firmwaresecurity.com/2017/12/20/apple-kb-article-on-secure-boot/

there is more info on Apple Secure Boot:


Apple: periodic reminder: set your firmware password

Re: https://firmwaresecurity.com/2018/05/02/apple-set-your-firmware-password/


Howard Oakley: Hidden caches in macOS: where your private data gets stored

Some time ago, I proposed that macOS 10.14 should be named Gormenghast, to reflect its many concealed and neglected features. These can trip up its own security and the protection of privacy when an old system within macOS is quietly storing sensitive data in an unprotected location. A good example is the latest vulnerability in QuickLook (or Quick Look, as Apple uses both forms).  Here is a brief overview of some of the potentially sensitive information which macOS secretes away in unexpected places. If you’re concerned about protecting the security of your data, these should be places to watch; if you’re a forensic analyst, these are often rewarding places to look.[…]

Hidden caches in macOS: where your private data gets stored

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

On Intel not talking to OpenBSD about recent FPU vuln

Chip vendors controlling the security of OSes should be more transparent in their selection process. They should maintain a list of OSVs that they maintain embargoed fixes. Then uses could determine if they want to trust the OS or not, or try to lobby to try and get the ISA vendor to support their OS. Is the OS on the list, ok then they may have some chance at fixing things. If not on the list I expect to be vulnerable until the embargo ends. There are MANY more OSes than Microsoft Windows, Apple macOS, a limited number of Linux distros, and sometimes FreeBSD.

In some forums, Bryan Cantrill is crafting a fiction. He is saying the FPU problem (and other problems) were received as a leak. He is not being truthful, inventing a storyline, and has not asked me for the facts. This was discovered by guessing Intel made a mistake. We are doing the best for OpenBSD. Our commit is best effort for our user community when Intel didn’t reply to mails asking for us to be included. But we were not included, there was no reply. End of story. That leaves us to figure things out ourselves. Bryan is just upset we guessed right. It is called science.



Apple macOS 10.13.5 EFI update, CVE-2018-4251