Jailbreak Detection nelle app iOS: essenza, metodi di rilevamento e verifica

Cos'è Jailbreak Detection?

Jailbreak Detection è il processo di identificazione dei dispositivi iOS che hanno avuto le restrizioni del sistema operativo rimosse. Il jailbreak modifica il kernel iOS, disabilita la firma del codice, fornisce accesso all'intero file system e consente di caricare librerie non autorizzate. Per un'applicazione in esecuzione su tale dispositivo, non ci sono garanzie di integrità dell'ambiente di esecuzione: qualsiasi processo può leggere la memoria dell'applicazione, intercettare il traffico SSL/TLS installando i propri certificati nell'archivio fiduciario del sistema e iniettare codice tramite Cydia Substrate o Substitute.

Le applicazioni finanziarie su iOS sono tenute a implementare Jailbreak Detection secondo gli standard PCI DSS — per la certificazione, l'applicazione deve dimostrare di non funzionare su un dispositivo compromesso. OWASP Mobile Security (2024) classifica l'assenza di Jailbreak Detection come vulnerabilità M8. Per le applicazioni App Store, Apple non vieta il blocco delle funzionalità sui dispositivi jailbroken, ma raccomanda di combinare controlli lato client e lato server per non fare affidamento esclusivamente sul codice client che potrebbe essere modificato.

L'architettura di Jailbreak Detection su iOS è più complessa di Root Detection su Android a causa del modello sandbox. Su Android, un'applicazione può leggere /proc per analizzare il sistema. La sandbox iOS blocca l'accesso diretto alla maggior parte degli indicatori di sistema. Gli sviluppatori sono costretti a utilizzare tecniche alternative come la verifica della disponibilità dei file nelle zone vietate tramite l'API canAccessFile o l'avvio di processi figli tramite fork() con verifica del codice di uscita. I controlli moderni si basano sul tentativo di azioni disponibili solo sotto jailbreak e sull'analisi del risultato.

Metodi di Rilevamento Basati su File

L'approccio più semplice e storicamente il primo è verificare la presenza di file e applicazioni che vengono installati solo su dispositivi jailbroken. Nonostante la semplicità, i controlli dei file rimangono uno strato di difesa di base, poiché bypassarli richiede un'azione attiva da parte dell'utente.

Verifica dei Pacchetti di Jailbreak

Su un dispositivo jailbroken, sono presenti applicazioni come Cydia, Sileo, Zebra o Installer. La loro presenza viene verificata tramite NSFileManager: [[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]. I pacchetti di unc0ver, checkra1n, Taurine e Chimera vengono verificati in modo simile. Questi controlli possono essere bypassati tramite tweak HideJB che intercettano le chiamate NSFileManager.

Verifica delle Utilità in /usr/bin

Il jailbreak installa utilità UNIX non disponibili in iOS standard: apt, dpkg, ssh, rsync, sftp, dd, readlink e altre. Viene verificata l'esistenza di /usr/bin/ssh, /bin/bash, /bin/sh e /usr/libexec/sftp-server. Se uno qualsiasi di questi file viene rilevato con successo, la probabilità di jailbreak è alta. Per iOS 13–17, è anche rilevante verificare la presenza di /var/jb — la directory root di bootstrap per unc0ver e Taurine.

Verifica delle Librerie Dinamiche

MobileSubstrate (CydiaSubstrate.dylib) e Substitute sono librerie per l'iniezione di codice nei processi. La loro presenza viene verificata tramite dlopen() con il flag RTLD_NOLOAD. Se la libreria è caricata nello spazio degli indirizzi — il processo è in esecuzione in un ambiente jailbroken. Questo è un controllo più affidabile, poiché HideJB non può scaricare una libreria già caricata in un processo.

- (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;
}

Controlli Dinamici in Tempo di Esecuzione

I controlli dinamici eseguono azioni vietate nella sandbox iOS e analizzano il risultato. Se l'azione non viene bloccata — il dispositivo è molto probabilmente jailbroken.

Verifica di fork() e posix_spawn()

In iOS standard, la chiamata fork() restituisce -1 con errno = EPERM. Su un dispositivo jailbroken, fork() può avere successo poiché le restrizioni della sandbox sono state rimosse. Questo controllo è affidabile ma può produrre falsi positivi su alcune versioni di iOS. fork() può anche essere sostituito con posix_spawn() per verificare la capacità di avviare un processo figlio.

Verifica della Firma del Sistema Sandbox

Tentativo di leggere file in zone vietate: /etc/master.passwd, /var/log/system.log, /private/var/cache. In iOS standard, queste letture restituiscono un errore. Se l'applicazione legge con successo questi file — la sandbox è disabilitata. Inoltre, viene verificata la capacità di scrivere in /private/ — in una sandbox, tutte le partizioni di sistema sono montate come sola lettura per le applicazioni normali.

Verifica dei Simboli di Sistema

Il jailbreak modifica le librerie di sistema, inclusa la cache condivisa dyld. Verificare l'hash dei framework di sistema o di singoli simboli può rivelare la modifica. Per iOS 14+, la presenza del simbolo jit_region_create o di altri segni di funzionamento di Fugu14/checkra1n nello spazio degli indirizzi del kernel viene verificata leggendo sysctl kern.version.

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

    // Verifica dell'accesso ai file di sistema
    FILE *f = fopen("/etc/master.passwd", "r");
    if (f) {
        fclose(f);
        return YES;
    }

    // Verifica di 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;
}

Implementazione Nativa in Objective-C

Il codice Swift viene facilmente disassemblato e bypassato tramite Substrate. Un'implementazione nativa in Objective-C con chiamate dirette a libobjc e funzioni di sistema C rende i controlli significativamente più resistenti al bypass.

Uso di stat() Invece di NSFileManager

La chiamata stat() da libc non può essere intercettata a livello Objective-C. I tweak HideJB che intercettano i metodi NSFileManager non influenzano stat(). Un controllo nativo con stat() rileva gli indicatori di file anche su dispositivi con moduli HideJB installati. La combinazione di stat() per i file e dlopen() con RTLD_NOLOAD per le librerie fornisce due canali di rilevamento non sovrapposti.

Verifica dell'Integrità della Firma del Codice

La funzione nativa SecStaticCodeCheckValidity verifica la firma del codice dell'applicazione rispetto al certificato Apple. Su un dispositivo jailbroken, questo controllo potrebbe essere falsificato tramite una patch del kernel. Per evitare la falsificazione, il controllo dovrebbe essere eseguito da codice nativo con una chiamata tramite dlopen() da Security.framework, anziché tramite Swift Bridge.

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

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

    // dlopen per verificare Substrate senza caricare
    void *substrate = dlopen(
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        RTLD_NOLOAD
    );
    if (substrate) {
        dlclose(substrate);
        return YES;
    }

    return NO;
}

Metodi di Bypass di Jailbreak Detection

Comprendere le tecniche di bypass è essenziale per costruire una protezione robusta. Gli strumenti di bypass moderni si evolvono attivamente e un insieme statico di controlli diventa inefficace entro pochi mesi.

HideJB e Shadow

HideJB è un tweak che intercetta le chiamate a NSFileManager, stat(), dlopen() e fork(), sostituendo i valori di ritorno. HideJB funziona a livello di Cydia Substrate, intercettando sia funzioni Objective-C che C. La versione di HideJB per iOS 15–16 (Shadow) utilizza una metodologia di hook a livello di kernel. Contromisura: eseguire il controllo in un processo separato con consegna del risultato tramite IPC, che rompe la catena di hook.

Choicy e Liberty Lite

Choicy consente di disabilitare Substrate per processi specifici. L'utente disabilita semplicemente l'iniezione per l'applicazione protetta — tutti i controlli delle librerie restituiscono false. Liberty Lite è un bypass completo che copre la maggior parte dei controlli delle librerie di protezione più diffuse. Contromisura: verifica lato server tramite DeviceCheck e App Attest — il server verifica che il dispositivo abbia un certificato Apple valido che non può essere falsificato su un dispositivo jailbroken.

Bypass tramite Fugu14 e KFD

Gli exploit del kernel, come Fugu14 e KFD, eseguono codice nello spazio del kernel, consentendo di intercettare le chiamate di sistema prima che l'applicazione le veda. A questo livello, i controlli stat() e fork() diventano inefficaci. L'unica contromisura affidabile è l'attestazione lato server con verifica che il dispositivo abbia superato la procedura Apple Attestation. Questo protocollo si basa su chiavi crittografiche all'interno del Secure Enclave, che sono illeggibili anche con un exploit a livello di kernel.

Architettura di Sicurezza iOS e il Ruolo del Jailbreak

Per costruire un efficace Jailbreak Detection, è necessario capire quali meccanismi di sicurezza iOS vengono disabilitati durante il jailbreak.

Catena di Avvio Sicuro (Secure Boot Chain)

iOS si avvia tramite una sequenza di controlli della firma: Boot ROM → iBoot → iOS Kernel. Se il jailbreak utilizza un exploit di bootrom (checkra1n), l'intera catena di avvio sicuro viene compromessa — i controlli a livello di applicazione sono inutili. Se viene utilizzato un exploit solo software (unc0ver, Taurine, Fugu14), la catena di avvio non viene spezzata e i servizi Apple come App Attest rimangono fidati.

Protezione delle Patch del Kernel (KPP)

A partire da iOS 10, Apple ha introdotto KPP — una protezione hardware che riverifica l'integrità del kernel ogni 200 ms. Tutti i jailbreak moderni (iOS 14–17) utilizzano il bypass di KTRR tramite PAC o APRR, ma KPP lascia tracce sotto forma di tabelle di sistema sysctl modificate. Verificare kern.version per la presenza di stringhe come pwned, prod o xnu con una versione non standard può rivelare una patch del kernel.

Integrità della Sandbox

La sandbox iOS opera a livello TrustedBSD utilizzando entitlement. Il jailbreak sostituisce il profilo della sandbox con allow-all. Un'applicazione può verificare la sandbox tentando di leggere qualsiasi file al di fuori della sua directory Documents. In caso di successo — la sandbox è stata modificata. L'integrità della Sandbox è uno dei pochi indicatori che non può essere falsificato senza un exploit a livello di kernel, poiché il controllo dei permessi viene eseguito nel kernel prima che possa essere intercettato.