Jailbreak Detection dans les applications iOS : essence, méthodes de détection et vérification

Qu'est-ce que Jailbreak Detection ?

Jailbreak Detection est le processus d'identification des appareils iOS dont les restrictions du système d'exploitation ont été supprimées. Le jailbreak modifie le noyau iOS, désactive la signature de code, donne accès au système de fichiers complet et permet de charger des bibliothèques non autorisées. Pour une application s'exécutant sur un tel appareil, il n'y a aucune garantie d'intégrité de l'environnement d'exécution : tout processus peut lire la mémoire de l'application, intercepter le trafic SSL/TLS en installant ses propres certificats dans le magasin de confiance du système et injecter du code via Cydia Substrate ou Substitute.

Les applications financières sur iOS sont tenues de mettre en œuvre Jailbreak Detection selon les normes PCI DSS — pour la certification, l'application doit prouver qu'elle ne s'exécute pas sur un appareil compromis. OWASP Mobile Security (2024) classe l'absence de Jailbreak Detection comme vulnérabilité M8. Pour les applications App Store, Apple n'interdit pas le blocage des fonctionnalités sur les appareils jailbreakés, mais recommande de combiner les vérifications côté client et côté serveur pour ne pas dépendre uniquement du code client qui pourrait être modifié.

L'architecture de Jailbreak Detection sur iOS est plus complexe que Root Detection sur Android en raison du modèle sandbox. Sur Android, une application peut lire /proc pour analyser le système. Le sandbox iOS bloque l'accès direct à la plupart des indicateurs système. Les développeurs sont contraints d'utiliser des techniques alternatives telles que la vérification de la disponibilité des fichiers dans les zones restreintes via l'API canAccessFile ou le lancement de processus enfants via fork() avec vérification du code de sortie. Les vérifications modernes sont construites sur la tentative d'actions disponibles uniquement sous jailbreak et l'analyse du résultat.

Méthodes de détection basées sur les fichiers

L'approche la plus simple et historiquement la première consiste à vérifier la présence de fichiers et d'applications qui ne sont installés que sur les appareils jailbreakés. Malgré leur simplicité, les vérifications de fichiers restent une couche de défense de base, car les contourner nécessite une action active de l'utilisateur.

Vérification des paquets de jailbreak

Sur un appareil jailbreaké, des applications comme Cydia, Sileo, Zebra ou Installer sont présentes. Leur présence est vérifiée via NSFileManager : [[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]. Les paquets d'unc0ver, checkra1n, Taurine et Chimera sont vérifiés de manière similaire. Ces vérifications peuvent être contournées via des tweaks HideJB qui interceptent les appels NSFileManager.

Vérification des utilitaires dans /usr/bin

Le jailbreak installe des utilitaires UNIX indisponibles dans iOS standard : apt, dpkg, ssh, rsync, sftp, dd, readlink et autres. L'existence de /usr/bin/ssh, /bin/bash, /bin/sh et /usr/libexec/sftp-server est vérifiée. Si l'un de ces fichiers est détecté avec succès, la probabilité d'un jailbreak est élevée. Pour iOS 13–17, il est également pertinent de vérifier la présence de /var/jb — le répertoire racine bootstrap pour unc0ver et Taurine.

Vérification des bibliothèques dynamiques

MobileSubstrate (CydiaSubstrate.dylib) et Substitute sont des bibliothèques d'injection de code dans les processus. Leur présence est vérifiée via dlopen() avec le drapeau RTLD_NOLOAD. Si la bibliothèque est chargée dans l'espace d'adressage — le processus s'exécute dans un environnement jailbreaké. C'est une vérification plus fiable, car HideJB ne peut pas décharger une bibliothèque déjà chargée dans un processus.

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

Vérifications dynamiques en temps réel

Les vérifications dynamiques effectuent des actions interdites dans le sandbox iOS et analysent le résultat. Si l'action n'est pas bloquée — l'appareil est très probablement jailbreaké.

Vérification de fork() et posix_spawn()

Dans iOS standard, l'appel fork() retourne -1 avec errno = EPERM. Sur un appareil jailbreaké, fork() peut réussir car les restrictions du sandbox sont supprimées. Cette vérification est fiable mais peut produire des faux positifs sur certaines versions d'iOS. fork() peut également être remplacé par posix_spawn() pour vérifier la capacité de lancer un processus enfant.

Vérification de la signature système du sandbox

Tentative de lecture de fichiers dans les zones restreintes : /etc/master.passwd, /var/log/system.log, /private/var/cache. Dans iOS standard, ces lectures retournent une erreur. Si l'application lit ces fichiers avec succès — le sandbox est désactivé. De plus, la capacité d'écrire dans /private/ est vérifiée — dans un sandbox, toutes les partitions système sont montées en lecture seule pour les applications normales.

Vérification des symboles système

Le jailbreak modifie les bibliothèques système, y compris le cache partagé dyld. La vérification du hachage des frameworks système ou des symboles individuels peut révéler une modification. Pour iOS 14+, la présence du symbole jit_region_create ou d'autres signes de fonctionnement de Fugu14/checkra1n dans l'espace d'adressage du noyau est vérifiée en lisant sysctl kern.version.

- (BOOL)isJailbrokenByRuntime {
    // Vérification de fork()
    int pid = fork();
    if (pid == 0) {
        exit(0);
    }
    if (pid > 0) {
        waitpid(pid, NULL, 0);
        return YES;
    }

    // Vérification d'accès aux fichiers système
    FILE *f = fopen("/etc/master.passwd", "r");
    if (f) {
        fclose(f);
        return YES;
    }

    // Vérification de 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;
}

Implémentation native en Objective-C

Le code Swift est facilement désassemblé et contourné via Substrate. Une implémentation native en Objective-C avec des appels directs à libobjc et aux fonctions système C rend les vérifications considérablement plus résistantes au contournement.

Utilisation de stat() au lieu de NSFileManager

L'appel stat() de libc ne peut pas être intercepté au niveau Objective-C. Les tweaks HideJB qui interceptent les méthodes NSFileManager n'affectent pas stat(). Une vérification native avec stat() détecte les indicateurs de fichiers même sur les appareils avec des modules HideJB installés. La combinaison de stat() pour les fichiers et de dlopen() avec RTLD_NOLOAD pour les bibliothèques fournit deux canaux de détection non chevauchants.

Vérification de l'intégrité de la signature de code

La fonction native SecStaticCodeCheckValidity vérifie la signature de code de l'application par rapport au certificat Apple. Sur un appareil jailbreaké, cette vérification peut être falsifiée via un patch du noyau. Pour contourner la falsification, la vérification doit être effectuée à partir de code natif avec un appel via dlopen() depuis Security.framework, plutôt que via Swift Bridge.

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

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

    // dlopen pour vérifier Substrate sans chargement
    void *substrate = dlopen(
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        RTLD_NOLOAD
    );
    if (substrate) {
        dlclose(substrate);
        return YES;
    }

    return NO;
}

Méthodes de contournement de Jailbreak Detection

Comprendre les techniques de contournement est essentiel pour construire une protection robuste. Les outils de contournement modernes évoluent activement, et un ensemble statique de vérifications devient inefficace en quelques mois.

HideJB et Shadow

HideJB est un tweak qui intercepte les appels à NSFileManager, stat(), dlopen() et fork(), en remplaçant les valeurs de retour. HideJB fonctionne au niveau de Cydia Substrate, interceptant à la fois les fonctions Objective-C et C. La version de HideJB pour iOS 15–16 (Shadow) utilise une méthodologie de hooks au niveau du noyau. Contre-mesure : effectuez la vérification dans un processus séparé avec remise du résultat via IPC, ce qui brise la chaîne de hooks.

Choicy et Liberty Lite

Choicy permet de désactiver Substrate pour des processus spécifiques. L'utilisateur désactive simplement l'injection pour l'application protégée — toutes les vérifications de bibliothèques retournent false. Liberty Lite est un contournement complet qui couvre la plupart des vérifications des bibliothèques de protection populaires. Contre-mesure : vérification côté serveur via DeviceCheck et App Attest — le serveur vérifie que l'appareil possède un certificat Apple valide qui ne peut pas être falsifié sur un appareil jailbreaké.

Contournement via Fugu14 et KFD

Les exploits du noyau, tels que Fugu14 et KFD, exécutent du code dans l'espace du noyau, permettant d'intercepter les appels système avant que l'application ne les voie. À ce niveau, les vérifications stat() et fork() deviennent inefficaces. La seule contre-mesure fiable est l'attestation côté serveur avec vérification que l'appareil a passé la procédure Apple Attestation. Ce protocole est basé sur des clés cryptographiques à l'intérieur du Secure Enclave, qui sont illisibles même avec un exploit au niveau du noyau.

Architecture de sécurité iOS et rôle du jailbreak

Pour construire une détection de jailbreak efficace, il est nécessaire de comprendre quels mécanismes de sécurité iOS sont désactivés lors du jailbreak.

Chaîne de démarrage sécurisé (Secure Boot Chain)

iOS démarre via une séquence de vérifications de signature : Boot ROM → iBoot → iOS Kernel. Si le jailbreak utilise un exploit de bootrom (checkra1n), toute la chaîne de démarrage sécurisé est compromise — les vérifications au niveau de l'application sont inutiles. Si un exploit logiciel uniquement (unc0ver, Taurine, Fugu14) est utilisé, la chaîne de démarrage n'est pas brisée et les services Apple tels que App Attest restent fiables.

Protection des patches du noyau (KPP)

À partir d'iOS 10, Apple a introduit KPP — une protection matérielle qui revérifie l'intégrité du noyau toutes les 200 ms. Tous les jailbreaks modernes (iOS 14–17) utilisent un contournement KTRR via PAC ou APRR, mais KPP laisse des traces sous forme de tables système sysctl modifiées. La vérification de kern.version pour la présence de chaînes telles que pwned, prod ou xnu avec une version non standard peut révéler un patch du noyau.

Intégrité du sandbox

Le sandbox iOS fonctionne au niveau TrustedBSD en utilisant des entitlements. Le jailbreak remplace le profil du sandbox par allow-all. Une application peut vérifier le sandbox en tentant de lire un fichier en dehors de son répertoire Documents. En cas de succès — le sandbox a été modifié. L'intégrité du sandbox est l'un des rares indicateurs qui ne peut pas être falsifié sans un exploit au niveau du noyau, car la vérification des permissions est effectuée dans le noyau avant de pouvoir être interceptée.