Introduction

Back to iOS 5.x era (2011-2012), iOS jailbreaking was mostly at its peak in terms of active users. The community around was important, each new iOS releases were creating such a hype. There were a lot of iDevice jailbreaking news dedicated blogs with great content. Starting from iOS 7.x, I noticed a progressive lost of interest in iOS jailbreaking for most people. From days to days, I think that tweaks and unofficial applications development releases decreased a lot and products quality dropped significantly. Also, most of those blogs I used to read back in the time became inactive or have been closed. I would say, in my opinion, iOS jailbreaking was a thing. I highly doubt that I will revive such good times with current Apple software and products, especially with their most recent security model.

However, there are still some unsolved puzzles left on older devices... :^)

For this writeup, we will focus on devices listed below. Those were the ones released by Apple before mid-2012.





The basic idea of iOS jailbreaking is to take control over Apple's chain of trust at some point on the device, starting from the low-level bootchain to the userland. More early the corruption occurs, more control the attacker has. We can divide iOS jailbreak types into three categories.

  1. SecureROM (or BootROM) exploits


  2. iBoot exploits


  3. Userland (kernel) exploits


Back in early 2012, most publicly available untethered jailbreaks were based on Limera1n BootROM exploit for the initial unsigned code execution coupled with another untethered BootROM exploit or a kernel land (userland) one to get persistence.

At this time, Apple also released A5 devices for which they patched Limera1n on the BootROM. There was now two categories of devices in terms of jailbreaking.

For many years, there was no publicly available low-level exploit for A5 and up devices. In 2019, @axi0mx released checkm8 BootROM exploit for devices from A5 to A11. This is an exploit running on DFU mode, similar to Limera1n. This is not a persistent (I mean untethered) exploit, it still requires to put device in DFU mode and inject the payloads via USB to take control over the low-level bootchain.

Somewhere in 2017, @p0sixninja released an interesting source code written in C language that he used as a Proof-of-Concept demo for Mobile Hacking BlackHat training class back in the time. This source code was written to exploit a heap buffer overflow vulnerability in iOS 5.x iBoot HFS+ block device read function. Since iOS 5.x was deprecated many years ago, most people in the iOS jailbreak community were not interested by this work. This iBoot exploit was still superior than current publicly available low-level exploits for those iOS 5 firmwares, because it could lead to an untethered jailbreak for any firmwares supported by the affected devices. I tried to compile that code myself and run it on an iPhone 4 on iOS 5.1.1, but I could not even got the code to compile properly. It remained lost for more than a year until @nyan_satan successfully exploited it in november 2018. After seeing his work, I was interested to try to exploit it on my iPad 2nd (Wi-Fi+Cellular) and acquire some iOS low-level exploitation knowledge. After I worked on implementing manually this exploit with the help of him, I understood that this code will not work as-is because the environment on which the exploit is based isn't static. For example, we will use the HFS+ heap buffer address to base our exploitation setup, but this buffer address tends to be different depending of multiple factors like position and size of the exploit partition on the block device. Also, any changes made to device NVRAM will shift the HFS+ heap buffer, making all references set in custom payloads invalid. In this code, most values (ex. addresses, references, etc.) need to be adjusted for the current exploitation environment. We will also have to add our own final exploitation payload because it is missing. P0sixninja's code will still be our reference for this epic iBoot land adventure.

With a fancy post-exploitation of this iBoot HFS+ heap buffer overflow, you will gain the following level of control over the affected devices. This HFS+ heap buffer overflow can be exploited on iOS 5.x and older iBoot versions. Therefore, a vulnerable iBoot version signed by Apple must be available to qualify an affected device.

Here is a list of concerned devices. Here are some post-exploitation examples we can do with this.

Since iBoot is a software, flashable component, it can be fixed. Apple patched this HFS+ heap buffer overflow in iOS 6.x iBoot builds. However, you can still downgrade to a vulnerable iBoot if you got SHSH blobs for 5.x firmwares.

For this writeup, we are going to downgrade back an iPad 2nd (Wi-Fi + Cellular, K94AP) back to iOS 5.0.1 (9A405) using SHSH blobs then exploit the HFS+ heap buffer overflow vulnerability on iBoot.



> Part 1: Download iOS firmwares