Understanding Jailbreaks

When it comes to iPhones, the term “jailbreak” (coined with the first iOS version before it was even named “iOS”) combines technology and the concept of breaking free from restrictions:

Jail: Originally refers to a metaphorical prison or confinement. In the context of iPhones, it represents the restrictions and limitations imposed by Apple on the 3rd party apps that run on their iOS operating system. Apple maintains strict control over what users can and cannot do with their devices through their App Store policies and system security measures. These limitations include restrictions on installing apps from sources other than the App Store, customizing the device’s appearance and functionality, and accessing the operating system’s inner workings.
Break: Implies escaping or freeing oneself from confinement. In the context of iPhone jailbreaking, it means circumventing or bypassing the restrictions set by Apple’s iOS. This process involves exploiting vulnerabilities in the iOS system to gain root access or administrative privileges, allowing users to modify the device in ways that Apple does not typically permit.

Jailbreaking an iPhone gives the end-user full execute and write access. So, when you put it all together, “jailbreak” in the context of iPhones essentially means breaking free from the restrictions and limitations imposed by Apple’s iOS, allowing users to gain more control over their devices and customize them to their liking. The term reflects the idea of liberating your iPhone from the metaphorical “jail” of Apple’s restrictions, giving you more freedom and flexibility with your device.
The desire to liberate one’s phone has given birth to a Jailbreak “community” made up of hackers, curious users, and threat actors. As with any self-respecting community, a Reddit group ( r/jailbreak ) has formed, YouTube channels have been created (and purged), and the dark/grey web supports the sharing of jailbreaking tips, techniques, and procedures among community members. Jailbreaks have long been sought after, and those who discover, execute, and share jailbreaks earn fame or notoriety within the jailbreak community.
Note that Jailbreaking can void warranties and may have legal implications, so it’s not something Apple officially supports or encourages. Also note that while “breaking free” from Apple’s policy voids Apple’s warranty, it is not, in and of itself, illegal, and many in the jailbreaking community consider it their right or even obligation to take part in jailbreaks, and not necessarily for malicious purposes. While the community of hackers, threat actors, and merry pranksters has loosely formed a grassroots jailbreak community dedicated to frustrating Apple’s efforts to lock down their OS, a for-profit industry that cracks iOS has also taken root. Companies like NSO, Cellebrite, and Paragon offer sophisticated jailbreak techniques for a fee; and law enforcement agencies, as well as governments around the world – though they are loathe to publicly admit it – almost surely avail themselves of these services.
In the world of application security , jailbreaks take on outsized importance because any time a threat actor wants to tamper with (modify) an application, one of the first things they must do is jailbreak a phone so that they can ensure that the modified application can be run. In other words, while jailbreaking a phone is not illegal or even unethical, jailbreaking is, in most cases, a necessary step towards actually using an app that has been tampered with. Therefore, detecting jailbroken phones is integral to any application hardening solution.
At the same time, Apple has consistently put time, money, effort, and ingenuity into preventing jailbreaks altogether. Over time, jailbreaks have become more complicated, often requiring multiple exploits to fully jailbreak the device due to Apple’s security improvements. The evolution of Apple’s efforts to prevent jailbreaks is long and storied – essentially a cat-and-mouse game that has spurred innovation in the jailbreak “community” and within Apple itself.
While jailbreak detection is integral to ensuring the security of publicly available applications, not all jailbreaks are created equal; some jailbreaks don’t even pose a major security threat.
This post will 1) describe the evolution of iPhone jailbreaks and 2) elaborate on which types of jailbreaks give full access to system resources in the original sense of the word, and which are less powerful cousins of the traditional jailbreak.
The Joint Evolution of iOS and Jailbreaks
Figure 1: A group of merry jailbreakers at DEF CON (August 2011). Photo Credit: Dreamyshade – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=38871495
The Early Days: BootROM Exploits
In the beginning, jailbreaking was primarily focused on the bootROM, a fundamental component of the iOS device’s boot process. The bootROM is a low-level piece of software permanently etched into the hardware, making exploits at this level particularly powerful. Attacks on the bootROM affect the entire chain of trust: the bootloader, the kernel, and, eventually, the userland environment. A successful bootROM exploit could grant unparalleled access to the device, allowing for permanent modifications that could survive software updates and resets. This era was marked by famous exploits like Limera1n and PwnageTool , which unlocked iPhones en masse, enabling custom firmware installations and deep system modifications.
The Shift to iBoot: Bootloader Vulnerabilities
As Apple fortified the bootROM, attackers turned their sights to iBoot, the next stage in the iOS boot process. Exploits in the bootloader, like redsn0w and Sn0wbreeze, though less permanent than bootROM vulnerabilities, still offered extensive control over the device. By compromising iBoot, attackers could influence the kernel and userland environment, allowing for significant customization and bypassing Apple’s ecosystem restrictions. These vulnerabilities were patchable via software updates, making them a less durable but still effective means of jailbreaking.
The Kernel Era: Patching and Protection
The progression toward kernel exploits marked a significant evolution in jailbreaking tactics. Kernel-level vulnerabilities, exploited by tools such as Pangu , Taig , and Yalu , allowed for the execution of unsigned code and deep system modifications without altering the boot process. This era consolidated a more refined approach to jailbreaking, focusing on operational flexibility within Apple’s security architecture. Jailbreaks like Electra and Unc0ver further exemplified this strategy, navigating through Apple’s defenses to modify the system while maintaining a semblance of compliance with iOS’s security protocols.
Modern Jailbreaks: Precision and Process-Specific Exploits
2015 was a tipping point in the history of jailbreaks. Apple, having effectively shored up defenses of both the bootROM and iBoot, was no longer willing to simply react to various exploits in their kernel with periodic patches and went on the offensive against the jailbreak community with a series of innovations that have essentially kept the jailbreak community – as well as companies such as Cellebrite and NSO – on their heels.
In iOS 9 (Sept 2015), Apple introduced Kernel Patch Protection (KPP), their most critical security update. KPP refers to code implemented in the kernel to protect read-execute and read-only memory in the kernelcache. It does so by having random checks every so often.
Since Sept 2015, the jailbreaks have been divided into KPPLess and KPP Bypass. KPPLess is a technique where KPP is still running – that means evading the KPP check. KPP Bypass disables KPP altogether. Before KPP, an attacker mostly needed to have kernel write capability to patch the security code.
In A10 chips, originally shipped with iOS 10 in June 2016, Apple introduced KTRR, Kernel Text Read only Region, which prevents modification of the iOS kernel at runtime. Older chips attempted to do this via a monitor program loaded in EL3, but the method was inherently flawed, and the Jailbreak Community had long figured out ways to bypass the monitoring program. Beginning with the A10 chips, Apple effectively moved security checks into the hardware itself, thus making the lives of the Jailbreakers (both in the community and in the for-profit sector) more difficult.
In June 2018, with the release of iOS 12, Apple introduced PAC (Pointer Authentication Code), its implementation of Pointer Authentication. PAC utilizes the upper bits of a pointer to store a cryptographic signature, essentially enhancing security by verifying pointer values and additional context. Special instructions have been introduced to add an authentication code to a pointer, verify an authenticated pointer’s PAC, and restore the original pointer value. This gives the system a way to make cryptographically strong guarantees about the likelihood that certain pointers have been tampered with by attackers, which offers the possibility of greatly improving application security.
When A12 chips came out later that year (Sept 2018), Apple introduced Page Protection Layer (PPL). PPL’s goal is to prevent threat actors from modifying a process’s executable code or its page tables, even after obtaining kernel read/write/execute privileges. This is another exploit mitigation that can make it more difficult to chain together attacks. It does this by leveraging APRR to create a “kernel inside the kernel” that protects page tables. The only way for the kernel to modify page tables is to enter PPL by calling a “PPL routine,” which is analogous to a syscall from XNU into PPL. This limits the entry points into the kernel code that can modify page tables to just those PPL routines. Can we sum up why this A12 change was significant to the jailbreak community?
The jailbreak community had a period of relative calm until June 2021, when Apple introduced iOS15. iOS15 gave the jailbreak community hives by introducing SSV, the Sealed System Volume. This mechanism is a kernel-level security feature that seals the volume with a cryptographic signature known only to Apple, which rejects any code attempting to modify the system content, which will then prevent any unauthorized changes made before iOS boots. This method forced the jailbreak community to change the entire structure of previous jailbreak architectures. Since then, the jailbreaks have been divided into rootless and rootful.
Rootless jailbreaks keep all the files and modifications outside of root, usually in /var and /private/preboot . Rootful jailbreaks use bind mounts which effectively create a “fake” root, which then acts like the real rootfs , but requires a bootROM exploit.
Since the jailbreak was achieved without patching the kernel code, the effects now aren’t system-wide but more per process. This means that instead of jailbreaking the operating system, jailbreaking is now done per process.
We can look at it this way – in the era of “premodern” jailbreaks, it was enough to patch the kernel, which caused the entire system to be affected. Now, where many jailbreaks ( Chimera , checkra1n ) are tampering with kernel data structures instead of directly patching the kernel’s code, the tampering is happening per process. This state complicates the detection of the jailbreak. While most of the system’s integrity seems intact, logic is implemented to determine whether a process has been jailbroken or not. Meaning, unless intended, the process stays jailed. This, in turn, means that even if this type of jailbreak grants access to resources that Apple does not intend for the app to have access to, it does not give access to all processes, which is important because it means that the jailbreak itself is not necessarily dangerous to all (or even any) of the apps on the phone.
This new way of jailbreaking is technically complicated, to say the least. It requires hooks in launchd where all of the processes are being invoked, execve hooks, and insertion all of the new process jailbreaks immediately after process creation. And unfortunately (from the jailbreaking community’s perspective), all of this technical creativity leads to fewer “freedoms.”
Implications for Application Security Engineers and DevSecOps Managers
So, what does all this mean to you, the application security engineer? Well, one of the best defense mechanisms we supply to you is “Runtime Application Self Protection,” or RASP. RASP allows our customers to program their apps to react automatically when and if guards and protections are triggered. Some customers have long used RASP to take action when and if jailbreaks are triggered.
But if the extensive history of the ongoing cat-and-mouse game between Apple and the Jailbreak community has taught us anything, it’s that not all jailbreaks are created equal. Some require “tethering” to a computer, offering little functional value to curious users or anyone beyond the most determined threat actors and academics. Various types exist, such as “semi-tethered,” rootless, and “rootful.” Some are arguably not worthy of the moniker “jailbreak” due to their limited scope, resembling more like hacker experiments than a working “product.” While Apple’s continued efforts to deter jailbreaks have forced innovation in the jailbreak community, they have also rendered modern jailbreaks less powerful over time. In other words, Apple’s relentless pursuit to back the jailbreaking community into a corner has made the term “jailbreak” seem almost too grandiose to refer to the advantages that these hacks are managing to confer even as the technical acumen required to accomplish these small feats has grown.
For this reason, we advise that companies who create applications for their customers apply a scalpel, instead of a hammer, to react to signs of jailbreaking. For instance, just recording that a jailbreak occurred might be enough, and it may no longer be necessary to program a reaction exclusively to a jailbreak. If you do find it necessary to program a reaction, consider which other guards are triggered in combination with the jailbreak when devising your Runtime Application Self Protection (RASP) strategy. The jailbreak is an enabler. It’s important to detect the attacks that are enabled BY the jailbreak and not only rely on jailbreak detection to stop attackers.
 
To read more about how Digital.ai Application Security can protect (by detecting jailbreaks among many other tricks) your iOS apps, download our Product Brief .