iOS

Jailbreak URL schemesJailbreak

Asks the OS whether jailbreak apps (cydia://, sileo://, filza://, …) are installed to handle their URL schemes.

jailbreak_url_schemesCompromising by default

At a glance

Platform: iOS
Category: Jailbreak
Source: DIIntegrityChecks.m · hasJailbreakURLSchemes
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.

Calls UIApplication canOpenURL: for cydia://, sileo://, zbra://, filza://, undecimus:// and activator://. A YES means an app registered to handle that scheme is installed.

This requires the schemes to be declared in LSApplicationQueriesSchemes in Info.plist; the library's Expo config plugin injects them automatically. Without the declaration canOpenURL: always returns NO, so the check silently does nothing.

Must run on the main thread (UIKit requirement); the check dispatches to the main queue before calling.

The exploit it addresses

Why this matters.The threat.

Package managers and jailbreak utilities register custom URL schemes so tweaks can deep-link into them. Their registration is a strong signal the device hosts jailbreak tooling even if the app binaries sit at non-standard paths.

How it can be bypassed

No single check is sufficient.Known evasions.

Apple limits LSApplicationQueriesSchemes to a fixed, declared list; a jailbreak app using an undeclared scheme is invisible to this probe.

Rootless package managers and users who never install a GUI package manager leave no scheme registered.

Hooking canOpenURL: to return NO defeats it trivially.

Validation scenarios

Where this check is exercised.2 scenarios.

Blocked · ios

Validated · ios

References & further reading

All checks

← Writable system partition su binary present →