<![CDATA[Jailbreak Central - The Best Jailbreak Forum! - iCloud Bypass Research]]> https://jailbreak.fce365.info/ Wed, 24 Jun 2026 20:12:50 +0000 MyBB <![CDATA[CheckM8 Free iCloud Activation Lock Bypass Software]]> https://jailbreak.fce365.info/Thread-CheckM8-Free-iCloud-Activation-Lock-Bypass-Software Wed, 16 Dec 2020 09:47:18 +0000 gsmaudit]]> https://jailbreak.fce365.info/Thread-CheckM8-Free-iCloud-Activation-Lock-Bypass-Software CheckM8 Released Free Activation Lock Screen Bypass Software for Apple A8(X), A9(X) & A10(X) devices. Software is available for macOS 10.11 or later. Jailbreak is Required but its already built in tool. CheckM8 Activation Lock Bypass Tool is free for public usage.


CheckM8 FREE Version supported:
  • Supports iOS versions from 12.4 up to iOS 14.0.1

  • Supported iPhone models: iPhones SE, 6, 6S, 7, 7 Plus, 8, 8 Plus and iPhone X

  • Supported iPad models: iPad Air (1, 2), iPad Mini (2, 3, 4), iPad (5, 6, 7), iPad Pro (1, 2), iPad Pro (9.7 & 10.5 in.)

CheckM8 FREE Version benefits:
  • 1 Click bypass activation lock screen totally for free!

  • Jailbreak is Built In CheckM8

  • Super fast - 1 Second and bypass is completed!

  • Safe bypass, after restore device will not stuck on Apple logo!

  • Working AppStore

  • Working iTunes ID

  • Working Applications


You can download CheckM8 Free Bypass iCloud Activation Lock Tool here]]> CheckM8 Released Free Activation Lock Screen Bypass Software for Apple A8(X), A9(X) & A10(X) devices. Software is available for macOS 10.11 or later. Jailbreak is Required but its already built in tool. CheckM8 Activation Lock Bypass Tool is free for public usage.


CheckM8 FREE Version supported:
  • Supports iOS versions from 12.4 up to iOS 14.0.1

  • Supported iPhone models: iPhones SE, 6, 6S, 7, 7 Plus, 8, 8 Plus and iPhone X

  • Supported iPad models: iPad Air (1, 2), iPad Mini (2, 3, 4), iPad (5, 6, 7), iPad Pro (1, 2), iPad Pro (9.7 & 10.5 in.)

CheckM8 FREE Version benefits:
  • 1 Click bypass activation lock screen totally for free!

  • Jailbreak is Built In CheckM8

  • Super fast - 1 Second and bypass is completed!

  • Safe bypass, after restore device will not stuck on Apple logo!

  • Working AppStore

  • Working iTunes ID

  • Working Applications


You can download CheckM8 Free Bypass iCloud Activation Lock Tool here]]> <![CDATA[iOS 13.3.1 / 13.3 - 12 FULL UNTETHERED iCloud Bypass RELEASED! (No re-locks) (Big News)]]> https://jailbreak.fce365.info/Thread-iOS-13-3-1-13-3-12-FULL-UNTETHERED-iCloud-Bypass-RELEASED-No-re-locks-Big-News Fri, 28 Feb 2020 19:15:45 +0000 GeoSn0w]]> https://jailbreak.fce365.info/Thread-iOS-13-3-1-13-3-12-FULL-UNTETHERED-iCloud-Bypass-RELEASED-No-re-locks-Big-News
The tool is untethered, which means you only have to do it once per restore, so if you don't restore your phone with iTunes to a different iOS, and if you don't update it, you should be fine. This bypass although fully functional, does not provide carrier service support, so no SIM card. App Store works, iTunes sync works, and so on, but no calls/texts. The creator of this tool mentioned on his Twitter that he won't provide service functionality.

While normally iCloud Activation is a very useful feature that keeps bad intentioned folks at bay, it becomes a real nuisance when you purchase a second-hand device and it turns out it's locked and the seller vanished. It's also a real nuisance when you forget your Apple ID or password and are locked out of your own device. 

As always, do not forget to SUBSCRIBE to stay updated with the latest #iOS and #Jailbreak news, updates and tutorials!
~ GeoSn0w

]]>
The tool is untethered, which means you only have to do it once per restore, so if you don't restore your phone with iTunes to a different iOS, and if you don't update it, you should be fine. This bypass although fully functional, does not provide carrier service support, so no SIM card. App Store works, iTunes sync works, and so on, but no calls/texts. The creator of this tool mentioned on his Twitter that he won't provide service functionality.

While normally iCloud Activation is a very useful feature that keeps bad intentioned folks at bay, it becomes a real nuisance when you purchase a second-hand device and it turns out it's locked and the seller vanished. It's also a real nuisance when you forget your Apple ID or password and are locked out of your own device. 

As always, do not forget to SUBSCRIBE to stay updated with the latest #iOS and #Jailbreak news, updates and tutorials!
~ GeoSn0w

]]> <![CDATA[apple tech 752 and other devs have a 13.3 solution]]> https://jailbreak.fce365.info/Thread-apple-tech-752-and-other-devs-have-a-13-3-solution Tue, 21 Jan 2020 16:25:09 +0000 mbh989092]]> https://jailbreak.fce365.info/Thread-apple-tech-752-and-other-devs-have-a-13-3-solution https://www.youtube.com/watch?v=ZMBOix4hI64
or just go download the whole thing at
http://appletech752.com/downloads.html
just dont restart your device after cause it relies on checkra1n jailbreak]]> https://www.youtube.com/watch?v=ZMBOix4hI64
or just go download the whole thing at
http://appletech752.com/downloads.html
just dont restart your device after cause it relies on checkra1n jailbreak]]> <![CDATA[13.3 Bypass App by ShiftKey]]> https://jailbreak.fce365.info/Thread-13-3-Bypass-App-by-ShiftKey Wed, 15 Jan 2020 04:00:23 +0000 meikatun]]> https://jailbreak.fce365.info/Thread-13-3-Bypass-App-by-ShiftKey
Probably GeoSnow can work with this guy for a workaround for the bugs he have and make it for Mac?

https://twitter.com/LeoManrique7
https://www.youtube.com/watch?v=Xq4zkyQSjnU

QUICK EDIT: I just test it on parallels and I actually was able to bypass on iOS 13.3, it have some bugs like there's no home button, neither the assistive touch works. so you need to plug to the computer to use it, neither the power button works.

looks like all the third party apps can't be launched and the rotation and volume buttons neither, but probably there's a solution?]]>
Probably GeoSnow can work with this guy for a workaround for the bugs he have and make it for Mac?

https://twitter.com/LeoManrique7
https://www.youtube.com/watch?v=Xq4zkyQSjnU

QUICK EDIT: I just test it on parallels and I actually was able to bypass on iOS 13.3, it have some bugs like there's no home button, neither the assistive touch works. so you need to plug to the computer to use it, neither the power button works.

looks like all the third party apps can't be launched and the rotation and volume buttons neither, but probably there's a solution?]]> <![CDATA[iTunes bug/exploit to crash Activation Lock screen and proceed to Welcome screen.]]> https://jailbreak.fce365.info/Thread-iTunes-bug-exploit-to-crash-Activation-Lock-screen-and-proceed-to-Welcome-screen Thu, 21 Nov 2019 00:18:04 +0000 failbr34k]]> https://jailbreak.fce365.info/Thread-iTunes-bug-exploit-to-crash-Activation-Lock-screen-and-proceed-to-Welcome-screen
However, due to the nature of the bug, iTunes doesn't have lockdown on the UDID and will read from it but not perfom actions like restoring a backup.

I don't want to make the bug to be public before I've managed to pull something useful out of it or am able to hand it off to skilled hands to help nail it quick.

But thank's to checkra1n and itunes not ever seeing it coming (you would never be able to do this with an iPhone that wasn't bootrom pwnd) we might have a way of restoring backups which could lead to full unlock.

For now, this is where I get:


.png   Screen Shot 2019-11-20 at 9.35.15 AM.png (Size: 371 KB / Downloads: 86)

I open up the floor for discussion.]]>
However, due to the nature of the bug, iTunes doesn't have lockdown on the UDID and will read from it but not perfom actions like restoring a backup.

I don't want to make the bug to be public before I've managed to pull something useful out of it or am able to hand it off to skilled hands to help nail it quick.

But thank's to checkra1n and itunes not ever seeing it coming (you would never be able to do this with an iPhone that wasn't bootrom pwnd) we might have a way of restoring backups which could lead to full unlock.

For now, this is where I get:


.png   Screen Shot 2019-11-20 at 9.35.15 AM.png (Size: 371 KB / Downloads: 86)

I open up the floor for discussion.]]> <![CDATA[Says not in DFU mode but I am?]]> https://jailbreak.fce365.info/Thread-Says-not-in-DFU-mode-but-I-am Wed, 06 Nov 2019 01:06:24 +0000 deathmill]]> https://jailbreak.fce365.info/Thread-Says-not-in-DFU-mode-but-I-am https://github.com/tihmstar/img4tool.git but once i downloaded it, the img4tool is a folder and not a unix file? can anyone help me? im watching this video https://www.youtube.com/watch?v=rA5pogxROks&t=29sand he has his img4tool as a unix file and not a folder. i downloaded a separate img4tool that was compiled and it seems to be a unix file.. i followed the instructions on the video using chmod 775 and dragging and dropping the img4 and the img4tool. and after that, i changed the directory and did cd and dragged the pwndfu-master folder into the terminal. once i dragged it in the terminal i did ./ipwndfu -p to run it right? so after i run it i usually get an error. its supposed to say, "device is already in pwned DFU Mode" but mine says it's not in the DFU mode when i got it in the dfu mode... the video also says that if the itunes recovery mode thing pops up, you're in recovery mode and your screen would be black. So I am certain that i'm in the DFU mode but it tells me that i'm not in the DFU mode, please help!
discord : lil shroom#3973 (please add me on discord)]]> https://github.com/tihmstar/img4tool.git but once i downloaded it, the img4tool is a folder and not a unix file? can anyone help me? im watching this video https://www.youtube.com/watch?v=rA5pogxROks&t=29sand he has his img4tool as a unix file and not a folder. i downloaded a separate img4tool that was compiled and it seems to be a unix file.. i followed the instructions on the video using chmod 775 and dragging and dropping the img4 and the img4tool. and after that, i changed the directory and did cd and dragged the pwndfu-master folder into the terminal. once i dragged it in the terminal i did ./ipwndfu -p to run it right? so after i run it i usually get an error. its supposed to say, "device is already in pwned DFU Mode" but mine says it's not in the DFU mode when i got it in the dfu mode... the video also says that if the itunes recovery mode thing pops up, you're in recovery mode and your screen would be black. So I am certain that i'm in the DFU mode but it tells me that i'm not in the DFU mode, please help!
discord : lil shroom#3973 (please add me on discord)]]> <![CDATA[iOS 13.1.3 / 13 / 12 CFW Creation: How To Extract Keys And Decrypt IPSW]]> https://jailbreak.fce365.info/Thread-iOS-13-1-3-13-12-CFW-Creation-How-To-Extract-Keys-And-Decrypt-IPSW Wed, 23 Oct 2019 09:30:33 +0000 GeoSn0w]]> https://jailbreak.fce365.info/Thread-iOS-13-1-3-13-12-CFW-Creation-How-To-Extract-Keys-And-Decrypt-IPSW
This step is crucial in the process of CFW creation on iOS because if you cannot decrypt the files, you cannot patch them. The CheckM8 exploit released by @axi0mX is compatible with iPhone 4S all the way up to iPhone X on all iOS versions compatible with these devices, past present or future. So you can do this procedure on any supported iOS version. Keep in mind that the keys you obtain using #CheckM8 are usable for your iPhone model. For example, if you have an iPhone X and you extract the keys for iOS 13.1.3 iBoot, the keys will work on all iPhone X devices on that version. The GID key changes per CPU not per individual device.

]]>
This step is crucial in the process of CFW creation on iOS because if you cannot decrypt the files, you cannot patch them. The CheckM8 exploit released by @axi0mX is compatible with iPhone 4S all the way up to iPhone X on all iOS versions compatible with these devices, past present or future. So you can do this procedure on any supported iOS version. Keep in mind that the keys you obtain using #CheckM8 are usable for your iPhone model. For example, if you have an iPhone X and you extract the keys for iOS 13.1.3 iBoot, the keys will work on all iPhone X devices on that version. The GID key changes per CPU not per individual device.

]]> <![CDATA[How to Decrypt iOS (iBoot, iBEC, iBSS, Ramdisk, etc) on iOS 13 / iOS 12 With CheckM8]]> https://jailbreak.fce365.info/Thread-How-to-Decrypt-iOS-iBoot-iBEC-iBSS-Ramdisk-etc-on-iOS-13-iOS-12-With-CheckM8 Mon, 21 Oct 2019 21:16:21 +0000 GeoSn0w]]> https://jailbreak.fce365.info/Thread-How-to-Decrypt-iOS-iBoot-iBEC-iBSS-Ramdisk-etc-on-iOS-13-iOS-12-With-CheckM8
For the sake of this post, I will use an iPod Touch 2019 (iPod Touch 7) which has the A10 Chip (compatible with CheckM8). I am also using the latest version of the CheckM8 exploit which is part of the ipwndfu repo on @axi0mX's GitHub.

Now, as you probably know, if you wanna build an iOS CFW you need to patch iBEC, iBSS, iBoot, the Ramdisk and so on. These are part of an IMG4 / IM4P container on 64-Bit iOS devices, and IMG3 containers on 32-Bit devices like iPhone 5, iPhone 5C and 4S. The container is encrypted. The key used to decrypt it is only available on the device's silicon and it cannot be extracted and used outside. However, using CheckM8, we can get access to the AES engine and ask it to derivate the decryption KEY and IV for us by feeding it the KBAG from the firmware component. Of course, normally, iOS turns this engine off ass soon as iBoot finishes doing its job at boot-time, but using this exploit we can just use it how much we want.

Keep in mind that each iOS device has a different key, so the decryption keys for iBEC for example from my iPod 7 will not work on the same iBEC from the same iOS version your iPhone 5S (for example). Each device model has a different GID key. Brute-forcing the key is useless. There way too many possible keys it would take billions of years to brute-force if even possible. While the GID key remains tightly encapsulated and protected, we can still take advantage of it if the iOS device is pwned at iBoot or SecureROM level.

Important note: The Key and IV used to decrypt the iOS components are actually stored inside each component as part of their IMG4 container inside the KBAG. However, the KEY + IV pair is also encrypted with another unique key called a GID key. This is the key we can never extract. Using the open window checkM8 brings to this key through the AES engine, we can decrypt the KBAG which will render the unencrypted plain-text Key and IV used to decrypt the actual data.

1.0 Gathering your tools:

For this operation, you will need a couple of tools. They are all listed here, available for you to download. 
Please do keep in mind that at the time I am writing this write-up, you can only do this on a macOS machine. Either virtual or physical.

> ipwndfu: https://github.com/axi0mX/ipwndfu
> IMG4TOOL: https://github.com/tihmstar/img4tool
> IMG4: https://mega.nz/#!kh9HwALK!z65nLcHWj_Ivu...q3XHe97_Vg

2.0 Obtaining the right iPSW file for your iOS version and device.

Of course, if you wanna decrypt the iOS for your device, you need the proper IPSW you wanna convert into a CFW. I recommend using ipsw.me to get the iPSW file for your iOS version and your device. Once you have it, rename it from ".ipsw" to ".zip" so that you can extract it. Double-click on the archive to extract it and wait until the extraction is complete.

Inside the iPSW you can see that there is a specific directory structure. Inside the DFU folder, you can find the iBEC and iBSS. Apple combines nowadays the firmware for multiple devices with the same screen size into the same IPSW, so make sure you get the files for your model. Usually, they are named after the device identifier.

For the sake of this write-up, I will extract the iBoot and the iBSS for my iPod and place them on my Desktop.

3.0 Obtaining the KBAG from the IM4P / IMG4 firmware component.

As I said, the decryption keys for each component are stored inside the component itself, but they're encrypted. The encrypted chunk is called a KBAG. We can use IMG4TOOL by @tihmstar to extract the KBAG.

In Terminal run the following commands:
 
Code:
chmod 775 /path/to/your/compiled/IMG4TOOL
./img4tool -a /path/to/encrypted/file

Then press Return (Enter).

In my case, it looks like this:

[Image: 1.png]

As you can see, the program yields two different KBAGs, num 1 and num 2. You're interested in num 1 because that one is for RELEASE fused devices. The other one is for DEVELOPMENT devices which they use internally at the factory.
You need to copy the long alphanumeric string after num: 1. That is your KBAG.

So in my case, the KBAG is:
 
Code:
493d1322792f9688c135567ee1c30e388ef162b030d229a986f8fded4b0a45d2cb1971400fb93cf6b884bf223b11944d

4.0 Decrypting the KBAG with CheckM8 and a compatible pwned device.

As you can see, we got the KBAG, but it's completely useless. We cannot use it to decrypt the data because the KBAG is an encrypted pair of KEY + IV. We need to pwn the matching device with checkm8 in DFU mode, and then use the AES engine to decrypt the KBAG.

Follow these steps to get your device in PWNED DFU MODE with CheckM8.

1) Plug the device to the computer using a USB cable.
2) Press and hold POWER + either HOME if you have an iPhone 6S Plus or older, or Volume DOWN until the phone goes dark. 
3) Wait 5 seconds while holding both after the screen goes black.
4) Release the Power button but keep holding HOME or Volume Down depending on the device, for 14 more seconds.
5) Release the HOME / Volume Down button.
6) Now run the ipwndfu in terminal.

The command should look like this, assuming you extracted the GitHub repo for ipwndfu in a folder on Desktop:
 
Code:
cd /Users/geosn0w/Desktop/ipwndfu-master
./ipwndfu -p

You may need to run the ./ipwndfu -p more than once if it fails. Once it succeeds it should look like mine:

[Image: 2.png]

Now that the device is pwned, we can abuse its AES engine to decrypt our KEY + IV.
To decrypt the KBAG, we need to run "./ipwndfu --decrypt-gid=YOUR KBAG" in Terminal. It should look like this once done:

[Image: 3.png]

As you can see, the decryption was successful and we obtained yet another confusing string. Fear not, this is the actual KEY and IV, but they are concatenated.

5.0 Extracting the KEY + IV for your component

That long string is basically the KEY and the IV, you just don't know how much of it is the key and how much of it is the IV. The first 64 characters are the KEY and the rest 32 are the IV.

So in this case, the KEY is:
570c42b1ae1af1ab9639b5b4b1983938b52b19662dabd101d74ca0529aa914e5

And the IV is:
3080bfc320a827ac89d3106831a06166

6.0 Using the KEY + IV to decrypt the firmware component

Now we can use the KEY + IV and the tool called IMG4 to actually decrypt iBSS / iBoot etc.
To do that, we need to run the following commands:
 
Code:
chmod 775 /Users/geosn0w/Desktop/img4
/Users/geosn0w/Desktop/img4 -image /Users/geosn0w/Desktop/iBoot.n112.RELEASE.im4p iBoot-Decrypted-AF 570c42b1ae1af1ab9639b5b4b1983938b52b19662dabd101d74ca0529aa914e53080bfc320a827ac89d3106831a06166

Of course, adapt the paths for your computer/locations.

Once we press enter, we should get only one word: the type of the file. In this case "ibot" means iBoot file. This means that the decryption was successful. You can see that by the fact that a new file was created with the second file name you specified (iBoot-Decrypted-AF) and when you open that file in a HEX editor, it should look like this.

[Image: 22.png]

And that's all :-) You can now patch, reverse engineer or do whatever to the decrypted file.
~GeoSn0w (@FCE365)

NOTE: This forum is not endorsed in any way by Apple Inc. iPhone and iOS are trademarks of Apple Inc. All the info provided here is strictly for educational purposes. You are the only one responsible for how you use this information.]]>
For the sake of this post, I will use an iPod Touch 2019 (iPod Touch 7) which has the A10 Chip (compatible with CheckM8). I am also using the latest version of the CheckM8 exploit which is part of the ipwndfu repo on @axi0mX's GitHub.

Now, as you probably know, if you wanna build an iOS CFW you need to patch iBEC, iBSS, iBoot, the Ramdisk and so on. These are part of an IMG4 / IM4P container on 64-Bit iOS devices, and IMG3 containers on 32-Bit devices like iPhone 5, iPhone 5C and 4S. The container is encrypted. The key used to decrypt it is only available on the device's silicon and it cannot be extracted and used outside. However, using CheckM8, we can get access to the AES engine and ask it to derivate the decryption KEY and IV for us by feeding it the KBAG from the firmware component. Of course, normally, iOS turns this engine off ass soon as iBoot finishes doing its job at boot-time, but using this exploit we can just use it how much we want.

Keep in mind that each iOS device has a different key, so the decryption keys for iBEC for example from my iPod 7 will not work on the same iBEC from the same iOS version your iPhone 5S (for example). Each device model has a different GID key. Brute-forcing the key is useless. There way too many possible keys it would take billions of years to brute-force if even possible. While the GID key remains tightly encapsulated and protected, we can still take advantage of it if the iOS device is pwned at iBoot or SecureROM level.

Important note: The Key and IV used to decrypt the iOS components are actually stored inside each component as part of their IMG4 container inside the KBAG. However, the KEY + IV pair is also encrypted with another unique key called a GID key. This is the key we can never extract. Using the open window checkM8 brings to this key through the AES engine, we can decrypt the KBAG which will render the unencrypted plain-text Key and IV used to decrypt the actual data.

1.0 Gathering your tools:

For this operation, you will need a couple of tools. They are all listed here, available for you to download. 
Please do keep in mind that at the time I am writing this write-up, you can only do this on a macOS machine. Either virtual or physical.

> ipwndfu: https://github.com/axi0mX/ipwndfu
> IMG4TOOL: https://github.com/tihmstar/img4tool
> IMG4: https://mega.nz/#!kh9HwALK!z65nLcHWj_Ivu...q3XHe97_Vg

2.0 Obtaining the right iPSW file for your iOS version and device.

Of course, if you wanna decrypt the iOS for your device, you need the proper IPSW you wanna convert into a CFW. I recommend using ipsw.me to get the iPSW file for your iOS version and your device. Once you have it, rename it from ".ipsw" to ".zip" so that you can extract it. Double-click on the archive to extract it and wait until the extraction is complete.

Inside the iPSW you can see that there is a specific directory structure. Inside the DFU folder, you can find the iBEC and iBSS. Apple combines nowadays the firmware for multiple devices with the same screen size into the same IPSW, so make sure you get the files for your model. Usually, they are named after the device identifier.

For the sake of this write-up, I will extract the iBoot and the iBSS for my iPod and place them on my Desktop.

3.0 Obtaining the KBAG from the IM4P / IMG4 firmware component.

As I said, the decryption keys for each component are stored inside the component itself, but they're encrypted. The encrypted chunk is called a KBAG. We can use IMG4TOOL by @tihmstar to extract the KBAG.

In Terminal run the following commands:
 
Code:
chmod 775 /path/to/your/compiled/IMG4TOOL
./img4tool -a /path/to/encrypted/file

Then press Return (Enter).

In my case, it looks like this:

[Image: 1.png]

As you can see, the program yields two different KBAGs, num 1 and num 2. You're interested in num 1 because that one is for RELEASE fused devices. The other one is for DEVELOPMENT devices which they use internally at the factory.
You need to copy the long alphanumeric string after num: 1. That is your KBAG.

So in my case, the KBAG is:
 
Code:
493d1322792f9688c135567ee1c30e388ef162b030d229a986f8fded4b0a45d2cb1971400fb93cf6b884bf223b11944d

4.0 Decrypting the KBAG with CheckM8 and a compatible pwned device.

As you can see, we got the KBAG, but it's completely useless. We cannot use it to decrypt the data because the KBAG is an encrypted pair of KEY + IV. We need to pwn the matching device with checkm8 in DFU mode, and then use the AES engine to decrypt the KBAG.

Follow these steps to get your device in PWNED DFU MODE with CheckM8.

1) Plug the device to the computer using a USB cable.
2) Press and hold POWER + either HOME if you have an iPhone 6S Plus or older, or Volume DOWN until the phone goes dark. 
3) Wait 5 seconds while holding both after the screen goes black.
4) Release the Power button but keep holding HOME or Volume Down depending on the device, for 14 more seconds.
5) Release the HOME / Volume Down button.
6) Now run the ipwndfu in terminal.

The command should look like this, assuming you extracted the GitHub repo for ipwndfu in a folder on Desktop:
 
Code:
cd /Users/geosn0w/Desktop/ipwndfu-master
./ipwndfu -p

You may need to run the ./ipwndfu -p more than once if it fails. Once it succeeds it should look like mine:

[Image: 2.png]

Now that the device is pwned, we can abuse its AES engine to decrypt our KEY + IV.
To decrypt the KBAG, we need to run "./ipwndfu --decrypt-gid=YOUR KBAG" in Terminal. It should look like this once done:

[Image: 3.png]

As you can see, the decryption was successful and we obtained yet another confusing string. Fear not, this is the actual KEY and IV, but they are concatenated.

5.0 Extracting the KEY + IV for your component

That long string is basically the KEY and the IV, you just don't know how much of it is the key and how much of it is the IV. The first 64 characters are the KEY and the rest 32 are the IV.

So in this case, the KEY is:
570c42b1ae1af1ab9639b5b4b1983938b52b19662dabd101d74ca0529aa914e5

And the IV is:
3080bfc320a827ac89d3106831a06166

6.0 Using the KEY + IV to decrypt the firmware component

Now we can use the KEY + IV and the tool called IMG4 to actually decrypt iBSS / iBoot etc.
To do that, we need to run the following commands:
 
Code:
chmod 775 /Users/geosn0w/Desktop/img4
/Users/geosn0w/Desktop/img4 -image /Users/geosn0w/Desktop/iBoot.n112.RELEASE.im4p iBoot-Decrypted-AF 570c42b1ae1af1ab9639b5b4b1983938b52b19662dabd101d74ca0529aa914e53080bfc320a827ac89d3106831a06166

Of course, adapt the paths for your computer/locations.

Once we press enter, we should get only one word: the type of the file. In this case "ibot" means iBoot file. This means that the decryption was successful. You can see that by the fact that a new file was created with the second file name you specified (iBoot-Decrypted-AF) and when you open that file in a HEX editor, it should look like this.

[Image: 22.png]

And that's all :-) You can now patch, reverse engineer or do whatever to the decrypted file.
~GeoSn0w (@FCE365)

NOTE: This forum is not endorsed in any way by Apple Inc. iPhone and iOS are trademarks of Apple Inc. All the info provided here is strictly for educational purposes. You are the only one responsible for how you use this information.]]> <![CDATA[iOS BootChain Explained / CFW iCloud Bypass Patches Needed]]> https://jailbreak.fce365.info/Thread-iOS-BootChain-Explained-CFW-iCloud-Bypass-Patches-Needed Sat, 12 Oct 2019 15:52:05 +0000 GeoSn0w]]> https://jailbreak.fce365.info/Thread-iOS-BootChain-Explained-CFW-iCloud-Bypass-Patches-Needed
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]]>
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]]>