Introduction
Recent security assessments revealed an ongoing problem with some iOS defense frameworks and in-house solutions: an over-reliance on checks designed for rootful jailbreaks. The mobile security landscape has fundamentally changed, and defenses must evolve accordingly.
Starting with iOS 15 and iPadOS 15 Apple’s Signed System Volume (SSV) was introduced to iOS and iPadOS. This feature cryptographically protects the system volume, ensuring its integrity by verifying every byte against an Apple-signed hash. Any unauthorized modification to the system volume is detected and blocked, which is a key reason for the shift to new, rootless jailbreak models on these systems.
The main difference between rootful and rootless jailbreaks on iOS is the level of access and modification allowed on the filesystem, which directly affects where jailbreak-related files, tweaks, and package managers are stored and how persistent or detectable the jailbreak is.
Rootful: The jailbreak remounts the root (/) partition as read-write, allowing modifications anywhere in the filesystem, including system directories like /Library, /usr, and /private/var/lib/apt/.
Rootless: The jailbreak does not remount the root partition as read-write. Instead, all jailbreak-related files and tweaks are confined to user-writable areas, typically under /var/jb/.
This seemingly small change has massive implications for security checks. A defense mechanism looking for Cydia in /Applications will find nothing on a modern, rootless jailbroken device.
The Link Between Jailbreak Detection and Runtime Security
For the iOS platform, the two most critical resilience defenses are jailbreak detection and runtime injection prevention. These two are deeply interconnected. An attacker with a jailbroken device can next perform runtime injection to try to bypass additional security countermeasures or compromise an application’s security.
Runtime injection techniques allow an attacker to load malicious dynamic libraries (dylibs) into an application’s process space at runtime. These dylibs can then hook into an app’s code to alter its behavior. Common attacks include:
- Bypassing Jailbreak Checks - Libraries like shadow.dylib are explicitly designed to hook jailbreak detection methods, effectively tricking the app into thinking it’s running on a secure device.
- Disabling Certificate Pinning - A library like sslkillswitch.dylib can disable SSL certificate pinning, allowing an attacker to perform a Man-in-the-Middle (MitM) attack and intercept all network traffic to and from the app.
If a jailbreak detection fails, it acts as the first domino, allowing an attacker try to disable other security layers. Without the ability to run an application on a jailbroken device, an attacker’s job is significantly harder. Apple’s App Store applications are encrypted with FairPlay DRM, which means the application binary itself is unreadable. An attacker must run the app on a jailbroken device to dump the decrypted binary from memory for static analysis and reverse engineering.
Therefore, if an application relies entirely on outdated, rootful-only filesystem checks, it will fail to detect a modern rootless jailbreak. The application will run without issue, exposing it to traffic interception, reverse engineering, and other attacks.
Hands-on experience
Below checks were spotted in recently tested application. No other checks were implemented, which allowed to seamlessly run the application on rootless-jailbroken iOS device as it would lack jailbreak entirely.
Filesystem based checks (jailbreak and runtime)
The following disassembly presents get_suspiciousAppAndSystemPaths function:
The following paths related to filesystem-based checks were found. Below listing shows sample paths from strings section:
Based on the sample above, example catalog /private/var/lib/apt is not found on rootless jailbreak filesystem:
The catalog is in the following location:
The procursus catalog itself is symlinked to /var/jb as listed below:
Thus, proper directory to check would be /var/jb/var/lib/apt:
Library based checks
Another check resides in areSuspiciousLibrariesLoaded, and should detect dynamic libraries like frida, cynject or libcycript, marked yellow in pseudocode below.
Apart from lack of checking of newest dylibs, the main part of the defense is Swift.Set.isDisjoint, marked red, which iterates through loaded dylibs loaded in the app process. This is typically done using low-level iOS APIs such as _dyld_get_image_name().
This defense however does not prevent from using Frida server, because of the fact that it utilizes specifically implemented manual mapping technique to load the frida-agent.dylib without registering it with the dynamic linker (dyld), effectively hiding it from tools like LLDB’s image list and from programmatic checks within the application itself.
Current implementation utilises typical low-level iOS API to check what libraries loaded within application memory (_dyld_get_image_name()).
To mimic that function, debugger was connected to process spawned by Frida:
The following listing shows all mobile’s dynamic libraries loaded into the process memory. However, under 995 libraries there is no Frida:
This confirms that the such defense against Frida may be obsolete and is not enough to prevent from dynamic instrumentation.
File write based checks
The application tries to save a file under /private catalog with isPrivateDirectoryRooted function:
Since the difference on rootless filesystem, such action is not possible:
Final Thoughts
It is imperative to adjust your filesystem-based checks to detect rootless jailbreaks. An outdated detection mechanism provides a false sense of security and is effectively no security at all. Review your checks and ensure they search for artifacts in modern paths like /var/jb/ in addition to legacy rootful paths.
The following table illustrates how sample file paths have shifted:
It is, however, important to mention that relying on any single detection method is fragile. A robust security posture for 2025 and beyond requires a multi-layered defense strategy. Your jailbreak detection mechanism should combine several techniques, including but not limited to:
- Updated filesystem checks (for both rootful and rootless paths).
- Dynamic library analysis.
