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. […]

Apple EFI firmware passwords and the SCBO myth

Apple EFI firmware passwords and the SCBO myth

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: