Apple EFI firmware update spreadsheet

This is an interesting twitter thread, if you have a Mac:

See-Also Firmware_Vault:

Wikileaks: Vault 7: Dark Matter

Today, March 23rd 2017, WikiLeaks releases Vault 7 “Dark Matter”, which contains documentation for several CIA projects that infect Apple Mac firmware (meaning the infection persists even if the operating system is re-installed) developed by the CIA’s Embedded Development Branch (EDB). These documents explain the techniques used by CIA to gain ‘persistence’ on Apple Mac devices, including Macs and iPhones and demonstrate their use of EFI/UEFI and firmware malware. Among others, these documents reveal the “Sonic Screwdriver” project which, as explained by the CIA, is a “mechanism for executing code on peripheral devices while a Mac laptop or desktop is booting” allowing an attacker to boot its attack software for example from a USB stick “even when a firmware password is enabled”. The CIA’s “Sonic Screwdriver” infector is stored on the modified firmware of an Apple Thunderbolt-to-Ethernet adapter. “DarkSeaSkies” is “an implant that persists in the EFI firmware of an Apple MacBook Air computer” and consists of “DarkMatter”, “SeaPea” and “NightSkies”, respectively EFI, kernel-space and user-space implants. Documents on the “Triton” MacOSX malware, its infector “Dark Mallet” and its EFI-persistent version “DerStarke” are also included in this release. While the DerStarke1.4 manual released today dates to 2013, other Vault 7 documents show that as of 2016 the CIA continues to rely on and update these systems and is working on the production of DerStarke2.0. Also included in this release is the manual for the CIA’s “NightSkies 1.2” a “beacon/loader/implant tool” for the Apple iPhone. Noteworthy is that NightSkies had reached 1.2 by 2008, and is expressly designed to be physically installed onto factory fresh iPhones. i.e the CIA has been infecting the iPhone supply chain of its targets since at least 2008. While CIA assets are sometimes used to physically infect systems in the custody of a target it is likely that many CIA physical access attacks have infected the targeted organization’s supply chain including by interdicting mail orders and other shipments (opening, infecting, and resending) leaving the United States or otherwise.



Sounds exciting, but I don’t know where to get eficheck. If someone knows, please leave a Comment to this post. Thanks!

additional Apple device property support for Linux efistub

Lukas Wunner submitted a 6-part patch to the Linux-(EFI,Kernel) lists with additional Apple EFI firmware support.

Apple device properties
Apple EFI drivers supply device properties which are needed to support Macs optimally. This series extends the efistub to retrieve the device properties before ExitBootServices is called (patch [1/6]). They are assigned to devices in an fs_initcall (patch [5/6]). As a first use case, the Thunderbolt driver is amended to take advantage of the Device ROM supplied by EFI (patch [6/6]). A by-product is a parser for EFI Device Paths which finds the struct device corresponding to a given path. This is needed to assign properties to their devices (patch [3/6]). […]

For more info:

Unicorn-based EFI emulator?

OSX Reverser has a new blog post on Apple EFI firmware passwords:

[…] This is when I had an idea! How about creating an EFI emulator and debugger using the Unicorn Engine framework? I had a feeling this wouldn’t be extremely hard and time consuming because the EFI environment is self contained – for example no linkers and syscalls to emulate. I also knew that this binary was more or less isolated, only using a few Boot and RunTime services and very few external protocols. Since the total number of Boot and RunTime services are very small this meant that there wasn’t a lot of code to be emulated. And with a couple of days work the EFI DXE Emulator was born. To my surprise I was finally able to run and debug an EFI binary in userland, speeding the reverse engineering process up immensely and quickly providing insight to previously tricky code. […]

Looking forward to an URL to this EFISwissKnife IDA plugin, and ESPECIALLY this new Unicorn-based EFI emulator! I can’t find an URL yet, though. 😦

OpenBSD 5.9 released

OpenBSD 5.9 has been released. There are a few firmware-related improvements in this release, such as:
* New efifb(4) driver for EFI frame buffer.
* amd64 can now boot from 32 bit and 64 bit EFI.
* Initial support for hardware reduced ACPI added to acpi(4).

* New asmc(4) driver for the Apple System Management Controller.
* New dwiic(4) driver for the Synopsys DesignWare I2C controller.
* Support for ACPI configured SD host controllers has been added to sdhc(4).
* The sdmmc(4) driver now supports sector mode for eMMC devices, such as those found on some BeagleBone Black boards.
* The ipmi(4) driver now supports OpenIPMI compatible character device.

Full announcement:

Linux 4.6 to see UEFI improvements

For the next Linux kernel, there are some new UEFI improvements to look forward to. Excerpting email from Ingo Molnar:

The main changes are:
– Use separate EFI page tables when executing EFI firmware code. This isolates the EFI context from the rest of the kernel, which has security and general robustness advantages. (Matt Fleming)
– Run regular UEFI firmware with interrupts enabled. This is already the status quo under other OSs. (Ard Biesheuvel)
– Various x86 EFI enhancements, such as the use of non-executable attributes for EFI memory mappings. (Sai Praneeth Prakhya)
– Various arm64 UEFI enhancements. (Ard Biesheuvel)

U-Boot: EFI patches applied, and new bootefi command

Alexander Graf of SuSE has been adding EFI support to U-Boot.  He also just added a new boot loader command, ‘bootefi’, as well:

[PATCH v6 19/30] efi_loader: Add “bootefi” command

In order to execute an EFI application, we need to bridge the gap between U-Boot’s notion of executing images and EFI’s notion of doing the same. The best path forward IMHO here is to stick completely to the way U-Boot deals with payloads. You manually load them using whatever method to RAM and then have a simple boot command to execute them. So in our case, you would do

  # load mmc 0:1 $loadaddr grub.efi
  # bootefi $loadaddr

which then gets you into a grub shell. Fdt information known to U-boot via the fdt addr command is also passed to the EFI payload.

Tom Rini of the U-Boot project also just posted a message saying that the EFI patches have been mostly applied:

EFI loader support largely enabled

What I mean by the subject is that with the EFI loader patches enabled U-Boot itself (not SPL) now includes the EFI loader and required bits on ARM/aarch64.  This is in general I think a good thing.  I’ve however disabled it on a few boards due to size constraints.  This is an average gain of ~12KiB in U-Boot proper.  I fully expect a number of platform patches opting out of this support due to it just not being a real usecase and I am agreeable to talking about making it not enabled by default.  So, lets kick things off.

For more information, see the U-Boot sources or mailing list archives:

EFI_BruteForce: EFI PIN of Apple MacBooks

I just noticed an old article and tool by Kooftness, for brute-forcing the (or an) Apple EFI firmware password.  As I understand the article, the original code didn’t generate results while they had access to the laptop, but since then the code has been revised (7 months ago) and others claim success with the code. I am unclear if this is a 3rd party PIN tool or the main Apple Firmware Password feature.

These Teensyduino sketches (for Teensy embeded boards) and shell scripts are tools to bruteforce EFI or iCloud locks.

Recently I got my hands on a MacBook Pro that after three weeks of being bought the seller desided that he wanted it back. He expressed this by locking it with a 4 digit PIN and a message that stated “Give me back the laptop and give you back the money”, with out calling or anything. […] I was told that an alternative solution would be to get a fresh MBP, extract its firmware and flash it using a PIC programmer. He also told me that there are ways to get around this attacking the thunderbolt port but these two options have a high risk in bricking the $2.000 laptop. […] I have received confirmation that this code is working, as we can see in this thread at MacRumors […]

“If you can’t remember the firmware password for your Mac, schedule a service appointment with an Apple Retail Store or Apple Authorized Service Provider.”

It appears that any current/former Apple Store  “genius” can most likely bypass the Apple Firmware Password protection. 😦 I suppose any vendor who can reset the PIN can use it like the above merchant, to blackmail the customer for access to their device.

I look forward to seeing the results of LegbaCore working at Apple …though I am afraid that their new models will become less configurable, more like modern Windows boxes, unable to run anything but Apple-approved OSes and pre-OS code (eg, rEFInd).

OpenPOWER port comments, and EFI creation story

A few weeks ago, I noticed a new Github project where someone at IBM had ported UEFI to OpenPOWER. Later that day, someone *ELSE* at IBM had *ALSO* ported UEFI to OpenPOWER — two ports! And they found out about each other because of my blog, too funny! Anyway, they’re actively conversing on the Comments thread on the blog:

In addition to OpenPOWER issues, the Comments section has MULTIPLE people posting comments, which is a first for this blog! There’s some good background on history of EFI, including a pointer to 2005-era message that includes the ‘creation saga’ of EFI! In the past, Apple used OpenFirmware on PowerPC-based Macs, and PC vendors used BIOS on x86-based PCs. When Windows NT started support for non-x86 systems, ARC was used for the RISC vendors. Then Intel Itanium needed a solution. They nearly used ARC or OpenFirmware, before going down the route for EFI for Itanium, which later grew into UEFI and is now on Apple and PC systems as well. Here’s an excerpt with Andrew Fish talking about how EFI was created:

“At that time, two firmware solutions were put on the table as
replacements for BIOS architectures for the Itanium: Alpha Reference
Console (ARC) and Open Firmware. It turned out that nobody really
owned the inellectual property to ARC, and in any case, it did not
have enough extensible properties to make it practical for a
horizontal industry. At this point, Open Firmware became the
frontrunner as Apple and Sun both used it. However, Open Firmware was
not without its own technical challenges. The PC had started down a
path of using the Advanced Configuration and Power Interface (ACPI) as
its runtime namespace to describe the platform to the operating
system. As I liked to say at the time, the only thing worse than one
namespace is keeping two namespaces in sync. The other problem was the
lack of third party support for Open Firmware. We invited the
FirmWorks guys to come visit us at Dupont (WA), and we had a great
talk. Given we had just gone through an exercise of inventing a
firmware base from scratch, I think we were uniquely qualified to
appreciate what Open Firmware had been able to achieve. Unfortunately,
it became clear that the infrastructure to support a transition to
Open Firmware did not exist. Given the namespace issue with Open
Firmware and the lack of industry enabling infrastructure, we decided
to go on and make EFI a reality.”

Full post:

I thought ARC stood for “Advanced RISC Consortium”, but I can’t argue with Andrew, maybe it originally stood for “Alpha Reference Console”.  (During these years, I was doing “ring0′ work, not firmware, and my favorite box at the time was a DEC Alpha AXP with ARC-based firmware.) ARC is very similar to early EFI: a single firmware image with a FAT partition where additional firmware images are stored, using ‘variables’ to specify the boot loader to invoke. ARC died off, like all the RISC-based Windows NT platforms, a shame, IMO. The ARC spec is still archived by the NetBSD project, who still supports ARC:

I wonder how life would be today if Intel would have chosen ARC or OpenFirmware?

Apple EFI security update for Mac OS X 10.9.5

Apple has announced an EFI securtity update for Mac OS X 10.9.5, apparently due to LegbaCore/MITRE research.

APPLE-SA-2015-10-21-6 Mac EFI Security Update 2015-002

Mac EFI Security Update 2015-002 is now available and addresses the following: EFI
Available for:  OS X Mavericks v10.9.5
Impact:  An attacker can exercise unused EFI functions
Description:  An issue existed with EFI argument handling. This was addressed by removing the affected functions.
CVE-ID: CVE-2015-7035 : Corey Kallenberg, Xeno Kovah, John Butterworth, and Sam Cornwell of The MITRE Corporation, coordinated via CERT
Installation note: Mac EFI Security Update 2015-002 may be obtained from the Mac App Store.

Full message:

In addition to this EFI update, Apple has released Multiple Security Updates:


SyScan is happening soon. There are multiple hardware/firmware-level talks, including one on VxWorks. And, since I’ve a bit of a UEFI focus, there is this one:

Is There An EFI Monster Inside Your Apple?

Pedro Vilaça
A few months ago I publicly disclosed an Apple EFI firmware zero day. It was a very powerful bug allowing direct access to the EFI firmware from the operating system. EFI rootkits are some of the most powerful and most interesting rootkits. Because they work at a very low level they can play a lot of tricks to hide themselves from forensics and persist for a long time. EFI monsters are a bit like jaguars, stealthy and rarely seen by humans. This doesn’t mean they do not exist. EFI monsters are most certainly part of spy agencies rootkits catalog. Very few tools exist to chase them. This talk is about introducing you to the EFI world so you can also start to chase these monsters. EFI world might look scary but it’s a bit easier than you think and a lot of fun. Thunderstrike 2 (to be presented at BlackHat) is a fine example of the power of EFI rootkits and the problems they present.

44con presentations available

44con just finished. I didn’t mention this event earlier, but it included a few interesting presentations and workshops:

Is there an EFI monster inside your apple?
Pedro Vilaça

Hands-on JTAG for fun and root shells
Joe FitzPatrick

Pen Test Partners IoT Workshop
Dave Lodge

UEFI for OpenBSD??

Hmm, I was under the impression that of the BSDs, only FreeBSD supported UEFI. (As well as MacOSX, of course.) But it appears that despite Theo’s previous comments on UEFI 🙂 that there might be some UEFI support in OpenBSD eventually:

From last year, GSOC’14 for OpenBSD (UEFI and GPT), I’ve not studied to see if these have been upstreamed yet:

From 2 days ago, a new OpenBSD-centric boot loader:
It looks like the latter project needs some hardware help, besides the author’s VIAO, if you can help them out…

quiz: define ‘firmworm’

The pre-conference preview videos are coming out… 🙂 One firmware one that caught my attention:

Thunderstrike 2 “firmworm” for MacBooks Preview Video

Apple Mac Mini EFI firmware update 1.8

As reported by Apple Support, and mentioned by Apple Insider and 9to5Mac news sites, Apple just released a firmware update for Mac Mini hardware for some models.

“This update is recommended for Mac mini (late 2012) models. This update addresses an issue that may prevent a USB keyboard from being recognized after the system wakes from sleep.”

I don’t know specifics of this release, and what security implications this has.

More Information:

LinuxCon North America this August in Seattle

LinuxCon North America is happening this August, in Seattle for the first time (I think). A quick look at their schedule shows a variety of interesting presentations related to firmware security:

* Extending the Secure Boot Certificate and Signature Chain of Trust in the OS – Fionnuala Gunter, Hypori
* Resurrecting Internet Booting – Boot Boot, Booting Over the Internet – John Hawley, Intel
* Demystifying ACPI and EFI via Python and BITS – Josh Triplett
* ACPI for Network Switches – Dustin Byford, Cumulus Networks
* Tying TPMs Throughout The Stack – Matthew Garrett, CoreOS
* Turtles All The Way: Running Linux on Open Hardware – Rob Landley
* ACPI 6 and Linux – Rafael J. Wysocki, Intel
* The Bare-Metal Hypervisor as a Platform for Innovation – Russell Pavlicek, Citrix
* Suspend/Resume at the Speed of Light – Len Brown, Intel

Josh Triplett on BIOS BITS sounds especially interesting. It’ll be interesting to see if the boot boot reboot will get integrated with UEFI HTTP Boot support.

More information: