apple_set_os.efi: Tiny EFI program for unlocking the Intel IGD on the Macbook Pro 11,3 for Linux and Windows. It has been made to be easily chainloaded by unmodified EFI bootloader like Grub, rEFInd etc. The Macbook Pro 11,3 model’s EFI is switching off the Intel GPU if you boot anything but Mac OS X. So a little trick by faking the OS identifiction is required to make all hardware accessible. All credits belong to Andreas Heider who originally discovered this hack.[…]
Greg Kroah-Hartman of the Linux Foundation submitted version 4.10 of a 81-part(!) patch to the Linux kernel by Baoquan He of Red Hat.
[PATCH 4.10 65/81] x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization
4.10-stable review patch. If anyone has any objections, please let me know.
commit a46f60d76004965e5669dbf3fc21ef3bc3632eb4 upstream.
Currently KASLR is enabled on three regions: the direct mapping of physical memory, vamlloc and vmemmap. However the EFI region is also mistakenly included for VA space randomization because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END. (This breaks kexec and possibly other things that rely on stable addresses.) The EFI region is reserved for EFI runtime services virtual mapping which should not be included in KASLR ranges. In Documentation/x86/x86_64/mm.txt, we can see:
ffffffef00000000 – fffffffeffffffff (=64 GB) EFI region mapping space
EFI uses the space from -4G to -64G thus EFI_VA_START > EFI_VA_END, Here EFI_VA_START = -4G, and EFI_VA_END = -64G. Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.
More info: see the linux-efi/linux-kernel list.
This is an interesting twitter thread, if you have a Mac:
See-Also Firmware_Vault: https://firmwaresecurity.com/2015/07/15/tool-review-uefi-spider-and-firmware_vault/
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!
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]). […]
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. 😦