Jailbreak Detection in iOS-apps: essentie, detectiemethoden en controle

Wat is Jailbreak Detection?

Jailbreak Detection — het proces van identificatie van iOS-apparaten waarvan de beperkingen van het besturingssysteem zijn opgeheven. Jailbreak wijzigt de iOS-kernel, schakelt code-ondertekening uit, biedt toegang tot het volledige bestandssysteem en maakt het laden van niet-geautoriseerde bibliotheken mogelijk. Voor een app die op een dergelijk apparaat draait, zijn er geen garanties voor de integriteit van de uitvoeringsomgeving: elk proces kan het geheugen van de app lezen, SSL/TLS-verkeer onderscheppen door eigen certificaten in de systeemopslag te installeren en code injecteren via Cydia Substrate of Substitute.

Financiële apps op iOS zijn verplicht om Jailbreak Detection te implementeren volgens de eisen van de PCI DSS-standaard — voor certificering moet de app aantonen dat deze niet op een gecompromitteerd apparaat draait. OWASP Mobile Security (2024) classificeert het ontbreken van Jailbreak Detection als kwetsbaarheid M8. Voor App Store-apps verbiedt Apple het blokkeren van functionaliteit op jailbreak-apparaten niet, maar raadt aan om client-side en server-side controles te combineren om niet uitsluitend te vertrouwen op clientcode die gewijzigd kan zijn.

De architectuur van Jailbreak Detection in iOS is complexer dan Root Detection in Android vanwege het sandbox-model. Op Android kan een app /proc lezen voor systeemanalyse. De iOS-sandbox blokkeert directe toegang tot de meeste systeemindicatoren. Ontwikkelaars moeten omzeilingstechnieken gebruiken, zoals het controleren van bestandstoegankelijkheid in verboden zones via de canAccessFile-API of het starten van subprocessen via fork() met controle van de exitcode. Moderne controles zijn gebaseerd op het proberen uit te voeren van acties die alleen beschikbaar zijn bij jailbreak en analyse van het resultaat.

Bestandsgebaseerde methoden voor jailbreak-detectie

De eenvoudigste en historisch eerste benadering — controle op aanwezigheid van bestanden en apps die alleen op jailbreak-apparaten worden geïnstalleerd. Ondanks de eenvoud blijven bestandscontroles een basale beschermingslaag, omdat het omzeilen ervan actieve acties van de gebruiker vereist.

Controle van jailbreak-pakketten

Op een jailbreak-apparaat zijn de apps Cydia, Sileo, Zebra of Installer aanwezig. Hun aanwezigheid wordt gecontroleerd via NSFileManager: [[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]. Op vergelijkbare wijze worden pakketten van unc0ver, checkra1n, Taurine en Chimera gecontroleerd. Deze controles worden omzeild via HideJB-tweaks die NSFileManager-aanroepen onderscheppen.

Controle van hulpprogramma's in /usr/bin

Jailbreak installeert UNIX-hulpprogramma's die niet beschikbaar zijn in stock iOS: apt, dpkg, ssh, rsync, sftp, dd, readlink en andere. Het bestaan van /usr/bin/ssh, /bin/bash, /bin/sh en /usr/libexec/sftp-server wordt gecontroleerd. Bij succesvolle detectie van een van deze bestanden is de kans op een jailbreak groot. Voor iOS 13–17 is het ook relevant om de aanwezigheid van /var/jb te controleren — de root-bootstrapdirectory voor unc0ver en Taurine.

Controle van dynamische bibliotheken

MobileSubstrate (CydiaSubstrate.dylib) en Substitute — bibliotheken voor code-injectie in processen. Hun aanwezigheid wordt gecontroleerd via dlopen() met de vlag RTLD_NOLOAD. Als de bibliotheek in het adresruimte is geladen — draait het proces in een jailbreak-omgeving. Dit is een betrouwbaardere controle omdat HideJB een reeds in het proces geladen bibliotheek niet kan verwijderen.

- (BOOL)isJailbrokenByFiles {
    NSArray *paths = @[
        @"/Applications/Cydia.app",
        @"/Applications/Sileo.app",
        @"/Applications/Zebra.app",
        @"/usr/bin/ssh",
        @"/bin/bash",
        @"/var/jb",
        @"/etc/apt"
    ];

    for (NSString *path in paths) {
        if ([[NSFileManager defaultManager]
            fileExistsAtPath:path]) {
            return YES;
        }
    }
    return NO;
}

- (BOOL)isSubstrateLoaded {
    void *handle = dlopen(
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        RTLD_NOLOAD | RTLD_LAZY
    );
    if (handle) {
        dlclose(handle);
        return YES;
    }
    return NO;
}

Dynamische runtime-controles

Dynamische controles voeren acties uit die verboden zijn in de iOS-sandbox en analyseren het resultaat. Als de actie niet wordt geblokkeerd — heeft het apparaat hoogstwaarschijnlijk een jailbreak.

Controle van fork() en posix_spawn()

In stock iOS retourneert de aanroep fork() -1 met errno = EPERM. Op een jailbreak-apparaat kan fork() worden uitgevoerd omdat de sandbox-beperkingen zijn opgeheven. Deze controle is betrouwbaar, maar kan valse positieven veroorzaken op sommige iOS-versies. fork() kan ook worden vervangen door posix_spawn() om de mogelijkheid te controleren om een subproces te starten.

Controle van systeemhandtekening van sandbox

Poging om bestanden te lezen in verboden zones: /etc/master.passwd, /var/log/system.log, /private/var/cache. In stock iOS retourneren deze leespogingen een fout. Als de app deze bestanden succesvol leest — is de sandbox uitgeschakeld. Aanvullend wordt de mogelijkheid om naar /private/ te schrijven gecontroleerd — in de sandbox zijn alle systeempartities alleen-lezen gemount voor gewone apps.

Controle van systeemsymbolen

Jailbreak wijzigt systeembibliotheken, waaronder de dyld shared cache. Het controleren van de hash van systeemframeworks of individuele symbolen kan wijziging detecteren. Voor iOS 14+ wordt de aanwezigheid van het symbool jit_region_create of andere tekenen van Fugu14/checkra1n in de kernel-adresruimte gecontroleerd via het lezen van sysctl kern.version.

- (BOOL)isJailbrokenByRuntime {
    // Controle van fork()
    int pid = fork();
    if (pid == 0) {
        exit(0);
    }
    if (pid > 0) {
        waitpid(pid, NULL, 0);
        return YES;
    }

    // Controle van toegang tot systeembestanden
    FILE *f = fopen("/etc/master.passwd", "r");
    if (f) {
        fclose(f);
        return YES;
    }

    // Controle van sysctl kern.version
    size_t size = 0;
    sysctlbyname("kern.version", NULL, &size, NULL, 0);
    if (size > 0) {
        char *version = malloc(size);
        sysctlbyname("kern.version", version, &size, NULL, 0);
        NSString *str = [NSString stringWithUTF8String:version];
        free(version);
        if ([str containsString:"pwned"]) {
            return YES;
        }
    }

    return NO;
}

Native implementatie in Objective-C

Swift-code wordt gemakkelijk gedisassembleerd en omzeild via Substrate. Native implementatie in Objective-C met directe aanroepen van libobjc en C-systeemfuncties maakt controles aanzienlijk beter bestand tegen omzeiling.

Gebruik van stat() in plaats van NSFileManager

De stat()-aanroep van libc kan niet worden onderschept op Objective-C-niveau. HideJB-tweaks die NSFileManager-methoden onderscheppen, hebben geen invloed op stat(). Native controle met stat() detecteert bestandsindicatoren zelfs op apparaten met geïnstalleerde HideJB-modules. De combinatie van stat() voor bestanden en dlopen() met RTLD_NOLOAD voor bibliotheken biedt twee niet-overlappende detectiekanalen.

Controle van codehandtekeningintegriteit

De native functie SecStaticCodeCheckValidity controleert de codehandtekening van de app op overeenstemming met het Apple-certificaat. Op een jailbreak-apparaat kan deze controle worden vervangen via kernel-patch. Om vervanging te voorkomen, moet de controle worden uitgevoerd vanuit native code met een aanroep via dlopen() uit Security.framework, niet via Swift Bridge.

#import <sys/stat.h>
#import <dlfcn.h>

- (BOOL)nativeCheckForJailbreak {
    // stat() omzeiling van NSFileManager hook
    struct stat st;
    if (stat("/Applications/Cydia.app", &st) == 0) {
        return YES;
    }

    // dlopen voor controle van Substrate zonder laden
    void *substrate = dlopen(
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        RTLD_NOLOAD
    );
    if (substrate) {
        dlclose(substrate);
        return YES;
    }

    return NO;
}

Methoden om Jailbreak Detection te omzeilen

Inzicht in omzeilingstechnieken is noodzakelijk voor het bouwen van duurzame beveiliging. Moderne omzeilingsinstrumenten ontwikkelen zich actief en een statische set controles wordt binnen enkele maanden ineffectief.

HideJB en Shadow

HideJB — een tweak die NSFileManager-, stat()-, dlopen()- en fork()-aanroepen onderschept en retourwaarden vervangt. HideJB werkt op Cydia Substrate-niveau en onderschept zowel Objective-C- als C-functies. De HideJB-versie voor iOS 15–16 (Shadow) maakt gebruik van kernel-level hooks. Tegenmaatregel: uitvoeren van de controle in een apart proces met overdracht van het resultaat via IPC, wat de hook-keten verbreekt.

Choicy en Liberty Lite

Choicy maakt het mogelijk Substrate uit te schakelen voor specifieke processen. De gebruiker schakelt eenvoudigweg injectie uit voor de beveiligde app — alle bibliotheekcontroles retourneren false. Liberty Lite — een uitgebreide omzeiling die de meeste controles van populaire beveiligingsbibliotheken dekt. Tegenmaatregel: serververificatie via DeviceCheck en App Attest — op de server wordt gecontroleerd of het apparaat een geldig Apple-certificaat heeft dat niet kan worden vervalst op een jailbreak-apparaat.

Omzeiling via Fugu14 en KFD

Kernel-exploits zoals Fugu14 en KFD voeren code uit in de kernel-ruimte (kernel-space), waardoor systeemaanroepen kunnen worden onderschept voordat de app ze ziet. Op dit niveau worden stat()- en fork()-controles ineffectief. De enige betrouwbare tegenmaatregel — serverattestatie met controle dat het apparaat de Apple Attestation-procedure heeft doorlopen. Dit protocol is gebaseerd op cryptografische sleutels binnen de Secure Enclave, die zelfs bij een kernel-level exploit niet leesbaar zijn.

iOS-beveiligingsarchitectuur en de rol van jailbreak

Voor het bouwen van effectieve Jailbreak Detection is het noodzakelijk te begrijpen welke beveiligingsmechanismen van iOS worden uitgeschakeld bij een jailbreak.

Secure Boot Chain

iOS start via een reeks handtekeningcontroles: Boot ROM → iBoot → iOS Kernel. Als de jailbreak gebruikmaakt van een bootrom-exploit (checkra1n), is de gehele Secure Boot Chain gecompromitteerd — controles op applicatieniveau zijn nutteloos. Als een software-only exploit (unc0ver, Taurine, Fugu14) wordt gebruikt, is de opstartketen niet geschonden en blijven Apple-diensten zoals App Attest betrouwbaar.

Kernel Patch Protection (KPP)

Vanaf iOS 10 heeft Apple KPP geïmplementeerd — een hardwarematige beveiliging die de integriteit van de kernel elke 200 ms opnieuw controleert. Alle moderne jailbreaks (iOS 14–17) gebruiken KTRR-omzeiling via PAC of APRR, maar KPP laat sporen achter in de vorm van gewijzigde sysctl-systeemtabellen. Controle van kern.version op aanwezigheid van de strings pwned, prod of xnu met een niet-standaard versie kan de aanwezigheid van een kernel-patch detecteren.

Sandbox-integriteit

De iOS-sandbox werkt op TrustedBSD-niveau met behulp van entitlements. Jailbreak vervangt het sandbox-profiel door allow-all. Een app kan de sandbox controleren door te proberen een bestand buiten de eigen Documents-map te lezen. Als dit lukt — is de sandbox gewijzigd. Sandbox-integriteit — een van de weinige indicatoren die niet kan worden vervalst zonder kernel-level exploit, omdat de machtigingscontrole in de kernel wordt uitgevoerd voordat deze kan worden onderschept.