Iboot G2 Firmware

[Liisa Komara]

Theclosed-source code is top-secret, proprietary, copyright Apple, and yet has been quietly doing the rounds between security researchers and device jailbreakers on Reddit for four or so months, if not longer. Where exactly it came from, no one is sure for now.

Crucially, within the past day or so, someone decided to dump a copy of this secret sauce on popular developer hangout GitHub for all to find. Links to the files began circulating on Twitter in the past few hours.

The source was swiftly taken down following a DMCA complaint by Apple, which means the code must be legit or else Cupertino would have no grounds to strip it from the website. However, at least one clone of the software blueprints has remerged on GitHub, meaning you can find it if you look hard enough.

According to those who have looked through the leaked iBoot source, the blueprints look legit. They include low-level system code written in 32 and 64-bit Arm assembly, drivers, internal documentation, operating system utilities, build tools, and more. Every file of the code is marked "this document is the property of Apple Inc," and: "It is considered confidential and proprietary. This document may not be reproduced or transmitted in any form, in whole or in part, without the express written permission of Apple Inc."

iBoot is a second-stage bootloader that's responsible for providing iOS's Recovery Mode to fix kit that gets screwed up. It runs on-screen, and over a physical USB or serial interface. When not in the recovery position, it verifies that a legit build of iOS is present, and if so, it starts up the software when the iThing is powered on or rebooted. The bootloader is highly protected, is stored in an encrypted form on devices, and is key to maintaining the integrity of the operating system.

No one's going to hack your iPhone or iPad over the air, nor via a webpage or an app, from this leak. The code is useful for the tight-knit crowd of eggheads who like rummaging through firmware code looking for holes to exploit to jailbreak devices using a tethered physical connection to a computer. Apple has recently-ish stepped up its security, with its secure coprocessors and other measures, to thwart jailbreaks. Perhaps now fans will be able to find new ways to jailbreak and customize their iGear, now the blueprints for the bootloader are sitting on the internet in plain sight.

Instead, we recommend you just sit back, relax, and marvel at how Apple somehow managed to lose control of such a central, critical and hush-hush component of its software stack. And wonder what else has leaked from Cupertino's highly secretive idiot-tax operations.

If the version is higher than that given here, it indicates that Mac has installed a more recent version of macOS, which has installed a later version of the firmware. This is almost invariably the result of installing a beta-release of the next version of macOS. This occurs even when the newer macOS is installed to an external disk.

If the installed version of firmware has a version which is lower than that shown, you can try installing macOS again to see if that updates the firmware correctly. If it still fails to update, you should contact Apple Support.

Some months ago I had installed an old version of Ventura on an external SSD and did boot the mini2018 to check new things like stage manager. But it was the regular one, so the firmware was probably even older at that time.

Before going any further, if the Mac is running High Sierra or later, check its EFI firmware integrity using the eficheck tool. Open Terminal, and in its command line type

/usr/libexec/firmwarecheckers/eficheck/eficheck --integrity-check

What is very different with Apple silicon Macs is that their firmware can be downgraded by Configurator, as well as upgraded (by installing more recent macOS). For example, if you upgraded your M-series Mac to Ventura, its iBoot version will have changed to 8419.41.10, as it will be in Monterey 12.6.1 or Big Sur 11.7.1, which install the same firmware. If you wanted to revert that Mac to Monterey 12.6, complete with its older iBoot and firmware, then you could download the IPSW image for 12.6 from Apple and restore that to your Mac using Configurator. That will return it to factory fresh condition, with 12.6 and its firmware running.

More recent versions of macOS, since Big Sur, provide detailed information about what has happened during macOS updates, in the text log at /System/Volumes/Update/restore.log. If you suspect that there may have been a problem with the firmware installer during an update, you may find information and error codes that provide clues as to what happened. However, this file is very large and unwieldy. Good luck!

Have you heard that the cups printing on macs leaves a cashe version on the mac? By a security expert, he has channel on YouTube. Sun Knudsen. I image you could incorporate code like he uses many of us have sensitive info to print.

Security Measures for DFU Mode on Apple Silicon MacBook Pros :

From my understanding, it is possible to put a MacBook Pro into DFU mode without requiring a password. Is this correct? Additionally, what measures are in place to prevent a hacker with physical access from loading malware firmware or wiping the device using this method? Specifically, I am referring to M1 Macs. In the past, with Intel-based Macs, it was possible to set a firmware password to prevent such attacks. I am curious as to what the equivalent is for Apple Silicon and why there are no safeguards in place to stop this type of attack. ?

One way an attacker could exploit this vulnerability is by modifying the firmware to insert malicious code and then signing it with a fake Apple signature. The attacker could then put the MacBook Pro into DFU mode and load the malicious firmware onto the device. It is not clear why there are no safeguards in place to prevent this type of attack on Apple Silicon Macs.

Apple silicon models upgraded to Sonoma should now be running with an iBoot version of 10151.1.1. If you check that in System Information, it should also report an OS Loader Version of 10151.1.1. I believe, though, that those running Ventura or Monterey are likely to report that same iBoot version, but their previous OS Loader Version of 8422.141.2, as I see here on a Ventura 13.6 VM.

Most notably, for the time being at least, the only Intel model without a T2 chip that has received a firmware update since the release of macOS 13.5 is the iMac19,1, the only one that is supported by Sonoma. Whether the next round of security updates later this year will bring any further firmware updates for other Intel models without T2 chips is an open question.

This all poses problems for SilentKnight, which automatically checks which firmware your Mac should be running. I have already updated that for iBoot in Apple silicon Macs, and intend updating reference versions for T2 firmware later today. Please bear with me as order is restored to firmware versions in the coming weeks.

One final point for those who have used eficheck on their Macs in the past: that command tool, introduced in High Sierra, no longer exists in Sonoma. It continues to work in Ventura and earlier, but only on Intel Macs without T2 chips. Macs with T2 or Apple silicon chips routinely check the integrity of their firmware when they start up, and with just the single model of iMac able to run eficheck, it has been abandoned in macOS 14. Farewell, old friend.

It therefore appears (though perhaps not easily verified) that the Monterey 12.7 update did indeed update the firmware. If you were seeing evidence of this not happening on Macs updated to 12.7 a few days ago, might Apple have done a delayed update to the firmware update distribution servers?

I found some odd things last night in settings even. Like how when I went to check for updates under beta had a warning saying something about beta will not be updated while in lockdown mode. Wish I was warned more about that in other places more clearly. So not running in lockdown anymore.

The source code of Apple's iBoot firmware on iOS devices was leaked and exposed on GitHub. How big of a deal is leaked source code? What are the potential implications for iBoot firmware?

When a device running iOS starts up, the processor immediately executes code known as the boot ROM, which was designed during chip fabrication and is implicitly trusted. This boot ROM contains Apple's root certificates, which are used to signature check the loading of the next stages: Low-Level Bootloader, followed by iBoot.

According to Apple's iOS security guide, the iBoot source code is responsible for verifying the integrity of the lowest levels of software in iOS before loading only the software that was signed by Apple, and then launching the full operating system. Device bootloaders like iBoot are critical to keeping operating systems safe, so does public access to its source code threaten the security of iOS devices?

The iBoot source code is written in the general-purpose C programming language and it was first posted on the Jailbreak subreddit last year, but garnered little attention, as the poster was new, with little Reddit karma. However, when it appeared on a GitHub repository, it became big news.

Apple sent a Digital Millennium Copyright Act (DMCA) takedown notice to GitHub. While this ensured the code was removed, it also confirmed that the code was genuine, as the DMCA notice required Apple to verify that the code was its property.

Apple has made certain sections of code for iOS and macOS open source, but iBoot has remained proprietary. Even so, a lot of it has already been reverse-engineered as bugs in the boot process reported to Apple through its bounty program can receive Apple's maximum payout of $200,000.

Theoretically, a vulnerability in the iBoot source code could allow unsigned code or code with a forged signature to be executed as iOS boots up, so the source code is certainly of interest to cybercriminals, security experts, and those looking to jailbreak or otherwise bypass Apple's security controls. Instructions for fuzzing the code with tools designed to discover weaknesses in code have already been posted online.

3a8082e126