Advertisement

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
iOS BootChain Explained / CFW iCloud Bypass Patches Needed
#1
Information 
One of the most well-known methods of bypassing iOS iCloud Activation is through a CFW (Custom Firmware) which is a patched version of iOS that usually has the Setup.app patched or removed. This has been done for as long as the activation existed ever since exploits like limera1n were released by geohot. This is not a new method, but over the years, the BootChain of iOS has changed a bit making patching a bit different.

For the sake of respecting Apple's intellectual property, I will not upload any modified iOS CFWs / iPSWs. However, in this post, I will detail the BootChain components, what they do and what patches need to be done on an individual basis for a CFW to boot using the newly released CheckM8 SecureROM (BootROM) exploit by security researcher @axi0mX.

The iOS Boot Sequence:

- SecureROM (BootROM) - It all starts here. This is the very first code that runs on the iOS device when it powers on. It's a small piece of code that handles the lowest level of the BootChain. This code is written into the silicon itself. No way for Apple or any other party to update this code via software. They'd basically need to produce a different SoC (A10 Chip, for example) and replace the one on your phone with the new one that has the BootROM exploit patched. iOS BootROM exploits are extremely rare and extremely expensive on the 0day market. Limera1n is maybe the most well-known BootROM exploit. It works on iPhone 4 and lower (A4 SoC). Up until @axi0mX released his CheckM8 BootROM exploit 2 weeks ago, we had no such exploit publicly available for A5 devices (iPhone 4S) or newer. CheckM8 supports iPhone 4S all the way up to iPhone X, and it was patched in the A12 SoC used in iPhone XS, XR, etc. The BootROM contains Apple's ROOT CA.

- LLB (Low-Level Bootloader) - This is also known as the "iBoot first-stage loader" and it is the first part of the chain loaded by the SecureROM after an SHSH2 blob check. This is part of the IPSW file for each iOS version. An exploit in here would be very powerful but it would be patchable by the next version. LLB runs a couple of setup routines, then it checks the SHSH2 blob of iBoot, loads it in memory and jumps to it if everything goes to plan (assuming a normal boot). When building a CFW, an initial patch would be here. You will need to patch iBoot downstream, so you need to also patch LLB to not check iBoot's signature.

- iBoot (iBoot Second-stage Loader) - This is another IPSW component flashed onto the device. It's being often the target for so-called iBoot exploits because they're also powerful. Such exploits allow verbose boot, custom boot logo, and jailbreaks to be loaded. Unfortunately, such exploits can also be patched. The ubiquitous "Recovery Mode" is run by iBoot. It provides an interactive interface that can be used over USB through either a normal USB -> Lightning cable, or a DCSD one. DCSD cables are Apple's Internal tools so they will not be discussed here. There's already a lot of research on those on The iPhone Wiki. iBoot is responsible for finding and loading the XNU Kernel. iBoot needs to be patched if you are planning to load a custom or patched kernel.

- The XNU Kernel - The Kernel and its kexts run the entire device. The security such as AMFI (Apple Mobile File Integrity) + CoreTrust, which handle code signing on iOS, the SandBox profiles which restrict apps based on their entitlements (part of the MACF Framework - Mandatory Access Control Framework), as well as any other driver or bit of code required for apps to run, for devices to work such as Bluetooth, GPS, etc, and also the entire memory management is being handled by the kernel. All iOS apps run under the kernel.

Apps such as the SpringBoard, daemons such as launchd, lockdownd, fairplayd, and many others, all run under the kernel itself. No kernel = no OS. So, if you are looking to jailbreak the device the CFW way, you would need to patch the kernel to disable AMFI, SandBoxing, maybe get tfp0 by patching the task_for_pid() function to allow you to get the task port for pid 0 (PID 0 = the kernel), and patch the kernel to allow remounting of the ROOT FS as Read / Write. I won't go into the details of these patches as they will be the subject of a different post under a different section of the forum.

- iBEC and iBSS - iBEC stands for iBoot Epoch Change and iBSS stands for iBoot Single Stage. These two components are uploaded from fake DFU mode during a restore. They're both stripped-down versions of iBoot but they lack the support for filesystems. They're used to load one another. iBSS is being loaded in fake DFU mode and it loads iBEC. iBEC receives, checks and loads the Restore Ramdisk and the restore process begins. You meet iBEC and iBSS every time you restore an iPSW from fake DFU mode. iBEC also talks with iTunes (or whichever software handles the restore on the computer-side). iBEC checks the signature of all the IMG4 (IM4P) or IMG3 files which are the contains in which most iOS Firmware components are stored.

For iOS CFW purposes, both iBEC and iBSS would need to be patched out of all the checks they do. This can be done in any Disassembler that supports ARM (64-Bit) files.

Also, for a CFW to restore, if there were changes to the ROOT FS DMG file (such as removal of Setup.app), the ASR binary inside the Restore Ramdisk also needs to be patched because it would otherwise fail to restore the modified Root FileSystem.

These together form the so-called iOS Trusted BootChain. Trusted, because every time a new part of the chain is loaded, a check is being done to ensure no tampering has been done. That's why all the checks need to be stripped.

That's mostly it for now. Stay posted.
~GeoSn0w
Reply
#2
thanks Goe!It so hard for me,I am reading and googling.
Reply
#3
(11-01-2019, 01:55 PM)Prontera Wrote: thanks Goe!It so hard for me,I am reading and googling.

I hope it helps :-)
Reply
#4
(10-12-2019, 03:52 PM)GeoSn0w Wrote: One of the most well-known methods of bypassing iOS iCloud Activation is through a CFW (Custom Firmware) which is a patched version of iOS that usually has the Setup.app patched or removed. This has been done for as long as the activation existed ever since exploits like limera1n were released by geohot. This is not a new method, but over the years, the BootChain of iOS has changed a bit making patching a bit different.

For the sake of respecting Apple's intellectual property, I will not upload any modified iOS CFWs / iPSWs. However, in this post, I will detail the BootChain components, what they do and what patches need to be done on an individual basis for a CFW to boot using the newly released CheckM8 SecureROM (BootROM) exploit by security researcher @axi0mX.

The iOS Boot Sequence:

- SecureROM (BootROM) - It all starts here. This is the very first code that runs on the iOS device when it powers on. It's a small piece of code that handles the lowest level of the BootChain. This code is written into the silicon itself. No way for Apple or any other party to update this code via software. They'd basically need to produce a different SoC (A10 Chip, for example) and replace the one on your phone with the new one that has the BootROM exploit patched. iOS BootROM exploits are extremely rare and extremely expensive on the 0day market. Limera1n is maybe the most well-known BootROM exploit. It works on iPhone 4 and lower (A4 SoC). Up until @axi0mX released his CheckM8 BootROM exploit 2 weeks ago, we had no such exploit publicly available for A5 devices (iPhone 4S) or newer. CheckM8 supports iPhone 4S all the way up to iPhone X, and it was patched in the A12 SoC used in iPhone XS, XR, etc. The BootROM contains Apple's ROOT CA.

- LLB (Low-Level Bootloader) - This is also known as the "iBoot first-stage loader" and it is the first part of the chain loaded by the SecureROM after an SHSH2 blob check. This is part of the IPSW file for each iOS version. An exploit in here would be very powerful but it would be patchable by the next version. LLB runs a couple of setup routines, then it checks the SHSH2 blob of iBoot, loads it in memory and jumps to it if everything goes to plan (assuming a normal boot). When building a CFW, an initial patch would be here. You will need to patch iBoot downstream, so you need to also patch LLB to not check iBoot's signature.

- iBoot (iBoot Second-stage Loader) - This is another IPSW component flashed onto the device. It's being often the target for so-called iBoot exploits because they're also powerful. Such exploits allow verbose boot, custom boot logo, and jailbreaks to be loaded. Unfortunately, such exploits can also be patched. The ubiquitous "Recovery Mode" is run by iBoot. It provides an interactive interface that can be used over USB through either a normal USB -> Lightning cable, or a DCSD one. DCSD cables are Apple's Internal tools so they will not be discussed here. There's already a lot of research on those on The iPhone Wiki. iBoot is responsible for finding and loading the XNU Kernel. iBoot needs to be patched if you are planning to load a custom or patched kernel.

- The XNU Kernel - The Kernel and its kexts run the entire device. The security such as AMFI (Apple Mobile File Integrity) + CoreTrust, which handle code signing on iOS, the SandBox profiles which restrict apps based on their entitlements (part of the MACF Framework - Mandatory Access Control Framework), as well as any other driver or bit of code required for apps to run, for devices to work such as Bluetooth, GPS, etc, and also the entire memory management is being handled by the kernel. All iOS apps run under the kernel.

Apps such as the SpringBoard, daemons such as launchd, lockdownd, fairplayd, and many others, all run under the kernel itself. No kernel = no OS. So, if you are looking to jailbreak the device the CFW way, you would need to patch the kernel to disable AMFI, SandBoxing, maybe get tfp0 by patching the task_for_pid() function to allow you to get the task port for pid 0 (PID 0 = the kernel), and patch the kernel to allow remounting of the ROOT FS as Read / Write. I won't go into the details of these patches as they will be the subject of a different post under a different section of the forum.

- iBEC and iBSS - iBEC stands for iBoot Epoch Change and iBSS stands for iBoot Single Stage. These two components are uploaded from fake DFU mode during a restore. They're both stripped-down versions of iBoot but they lack the support for filesystems. They're used to load one another. iBSS is being loaded in fake DFU mode and it loads iBEC. iBEC receives, checks and loads the Restore Ramdisk and the restore process begins. You meet iBEC and iBSS every time you restore an iPSW from fake DFU mode. iBEC also talks with iTunes (or whichever software handles the restore on the computer-side). iBEC checks the signature of all the IMG4 (IM4P) or IMG3 files which are the contains in which most iOS Firmware components are stored.

For iOS CFW purposes, both iBEC and iBSS would need to be patched out of all the checks they do. This can be done in any Disassembler that supports ARM (64-Bit) files.

Also, for a CFW to restore, if there were changes to the ROOT FS DMG file (such as removal of Setup.app), the ASR binary inside the Restore Ramdisk also needs to be patched because it would otherwise fail to restore the modified Root FileSystem.

These together form the so-called iOS Trusted BootChain. Trusted, because every time a new part of the chain is loaded, a check is being done to ensure no tampering has been done. That's why all the checks need to be stripped.

That's mostly it for now. Stay posted.
~GeoSn0w
So isn't it possible to have iphone activated by cloning plist and required files from other same device to checkra1n jailbreaked device? I mean for cellular network and iMessage/Facetime
Reply
#5
Thank you Geo, this is good information and very well explained.  Smile
little big french, almost beginner, just try to understand ios system
Reply
#6
Hey guys so I recently got an Apple Watch from a friend and it’s activation locked. I was wondering if there’s anyway we can make a tweak that bypasses activation within the watch app. I’ve been trying but to no avail.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
Video iOS 13.3.1 / 13.3 - 12 FULL UNTETHERED iCloud Bypass RELEASED! (No re-locks) (Big News) GeoSn0w 0 1,814 02-28-2020, 07:15 PM
Last Post: GeoSn0w
  13.3 Bypass App by ShiftKey meikatun 1 1,948 01-19-2020, 05:39 PM
Last Post: mbh989092

Forum Jump:


Users browsing this thread: 1 Guest(s)

About Us
    Welcome to the Jailbreak Central Forum! Here you can get the latest iOS Jailbreak News from iDevice Central, ask your jailbreak questions and request help, and find the best iOS modding tools for downgrade, CFW iCloud Bypass, Jailbreak and so on. :-)