Uncategorized

Setting up Mac for EFI development

Setup EFI Development environment on Mac OSX Sierra (10.12.X)

Mikal Villa Mikal Villa • 07/10/2017

Oh no! a lot of text. Well, luckly half of the post is troubleshooting. EFI development setup is easy 🙂

Okay, before starting this guide you should have some tools installed already.[…]

https://0xcc.re/setup-efi-development-environment-on-mac-osx-sierra-10-12-x/

Standard
Uncategorized

apple_set_os.efi: unlock Intel IGD on MacBook Pro

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

https://github.com/0xbb/apple_set_os.efi

More info:
https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00442.html

Standard
Uncategorized

Linux Kernel: exclude EFI from KASLR VA space randomization

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.

Standard
Uncategorized

Apple EFI firmware update spreadsheet

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

https://support.apple.com/en-us/HT201518

https://docs.google.com/spreadsheets/d/1qGRVF1aRokQgm_LuTsFUN2Knrh0Sd3Gp0ziC_VIWqoM/edit#gid=0

See-Also Firmware_Vault: https://firmwaresecurity.com/2015/07/15/tool-review-uefi-spider-and-firmware_vault/

Standard
Uncategorized

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.

https://wikileaks.org/vault7/darkmatter/?cia

https://wikileaks.org/vault7/darkmatter/document/SonicScrewdriver_1p0/
https://wikileaks.org/vault7/darkmatter/document/DerStarke_v1_4_DOC/
https://wikileaks.org/vault7/darkmatter/document/DerStarke_v1_4_RC1_IVVRR_Checklist/
https://wikileaks.org/vault7/darkmatter/document/Triton_v1_3_DOC/
https://wikileaks.org/vault7/darkmatter/document/DarkSeaSkies_1_0_URD/

 

Standard
Uncategorized

eficheck

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

Standard
Uncategorized

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:
https://github.com/l1k/linux/commits/apple_properties_v1
http://vger.kernel.org/majordomo-info.html

Standard