iOS
Writable system partitionJailbreak
Tries to create a file outside the sandbox, under /private — impossible on a stock device.
At a glance
- Platform
- iOS
- Category
- Jailbreak
- Source
- DIIntegrityChecks.m · isSystemWritable
- Default status
- Makes status compromised
- Seen firing
- Not yet seen firing in a validated run. Based on validated scenarios whose observed result includes this signal; see below.
- OWASP MASTG
- MASTG-TEST-0088
How it works
What the code inspects.
Builds a random path under /private (e.g. /private/di_integrity_<uuid>), opens it for writing with fopen, writes one byte, closes, and unlink()s it.
On a stock device the sandbox and the read-only system volume make fopen fail and the function returns NO. If the write succeeds, the process can write outside its container — only possible when the sandbox has been defeated.
The exploit it addresses
Why this matters.The threat.
Writing outside the app container means the sandbox — the boundary that stops one app from tampering with the OS or other apps — is gone. That is the defining capability a jailbreak grants.
How it can be bypassed
No single check is sufficient.Known evasions.
On modern iOS the system volume is a signed, cryptographically sealed APFS snapshot (SSV); even many jailbreaks cannot make it writable, so the check can miss rootless jailbreaks that never gain system write.
Sandbox-hooking tweaks can intercept the probe and force fopen to fail.
Validation scenarios
Where this check is exercised.1 scenario.
References & further reading
- MASTG-TEST-0088: Testing Jailbreak Detection (iOS)Open ↗
https://mas.owasp.org/MASTG/tests/ios/MASVS-RESILIENCE/MASTG-TEST-0088/
- Apple secure boot chainOpen ↗
https://support.apple.com/guide/security/secure-boot-chain-secb3000f149/web
- IOSSecuritySuite (reference check set; no source copied)Open ↗
https://github.com/securing/IOSSecuritySuite