Jailbreak Detection w aplikacjach dla iOS: istota, metody wykrywania i testowanie

Co to jest Jailbreak Detection?

Jailbreak Detection — proces identyfikacji urządzeń iOS, na których zdjęto ograniczenia systemu operacyjnego. Jailbreak modyfikuje jądro iOS, wyłącza podpisywanie kodu, zapewnia dostęp do pełnego systemu plików i umożliwia ładowanie nieautoryzowanych bibliotek. Dla aplikacji działającej na takim urządzeniu nie ma gwarancji integralności środowiska wykonawczego: każdy proces może odczytać pamięć aplikacji, przechwycić ruch SSL/TLS poprzez instalację własnych certyfikatów w magazynie systemu i wstrzykiwać kod przez Cydia Substrate lub Substitute.

Aplikacje finansowe na iOS są zobowiązane do wdrożenia Jailbreak Detection zgodnie z wymogami standardu PCI DSS — do certyfikacji aplikacja musi udowodnić, że nie działa na skompromitowanym urządzeniu. OWASP Mobile Security (2024) klasyfikuje brak Jailbreak Detection jako podatność M8. Dla aplikacji w App Store Apple nie zabrania blokowania funkcjonalności na urządzeniach z jailbreakiem, jednak zaleca łączenie sprawdzeń po stronie klienta i serwera, aby nie polegać wyłącznie na kodzie klienckim, który może być zmodyfikowany.

Architektura Jailbreak Detection w iOS jest bardziej złożona niż Root Detection w Androidzie ze względu na model piaskownicy. W Androidzie aplikacja może czytać /proc w celu analizy systemu. Piaskownica iOS (sandbox) blokuje bezpośredni dostęp do większości wskaźników systemowych. Deweloperzy są zmuszeni do stosowania technik obejścia, takich jak sprawdzanie dostępności plików w strefach zabronionych przez API canAccessFile lub uruchamianie procesów potomnych przez fork() z kontrolą kodu wyjścia. Nowoczesne sprawdzenia opierają się na próbie wykonania działań dostępnych tylko przy jailbreaku i analizie wyniku.

Plikowe metody wykrywania jailbreaka

Najprostsze i historycznie pierwsze podejście — sprawdzenie obecności plików i aplikacji, które są instalowane tylko na urządzeniach z jailbreakiem. Mimo swojej prostoty, sprawdzenia plikowe pozostają podstawową warstwą ochrony, ponieważ ich obejście wymaga aktywnych działań ze strony użytkownika.

Sprawdzenie pakietów jailbreaka

Na urządzeniu z jailbreakiem znajdują się aplikacje Cydia, Sileo, Zebra lub Installer. Ich obecność sprawdzana jest przez NSFileManager: [[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]. Analogicznie sprawdzane są pakiety od unc0ver, checkra1n, Taurine i Chimera. Te sprawdzenia są omijane przez tweaki HideJB, które przechwytują wywołania NSFileManager.

Sprawdzenie narzędzi w /usr/bin

Jailbreak instaluje narzędzia UNIX niedostępne w stock iOS: apt, dpkg, ssh, rsync, sftp, dd, readlink i inne. Sprawdzana jest obecność /usr/bin/ssh, /bin/bash, /bin/sh i /usr/libexec/sftp-server. W przypadku wykrycia któregokolwiek z tych plików prawdopodobieństwo jailbreaka jest wysokie. Dla iOS 13–17 należy również sprawdzić obecność /var/jb — katalogu głównego bootstrapu dla unc0ver i Taurine.

Sprawdzenie bibliotek dynamicznych

MobileSubstrate (CydiaSubstrate.dylib) i Substitute — biblioteki do wstrzykiwania kodu do procesów. Ich obecność sprawdzana jest przez dlopen() z flagą RTLD_NOLOAD. Jeśli biblioteka jest załadowana w przestrzeni adresowej — proces działa w środowisku z jailbreakiem. Jest to bardziej niezawodne sprawdzenie, ponieważ HideJB nie może wyładować już załadowanej do procesu biblioteki.

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

Dynamiczne sprawdzenia czasu wykonania

Dynamiczne sprawdzenia wykonują działania, które w piaskownicy iOS są zabronione, i analizują wynik. Jeśli działanie nie zostało zablokowane — urządzenie najprawdopodobniej ma jailbreaka.

Sprawdzenie fork() i posix_spawn()

W stock iOS wywołanie fork() zwraca -1 z errno = EPERM. Na urządzeniu z jailbreakiem fork() może się wykonać, ponieważ ograniczenia piaskownicy zostały zdjęte. To sprawdzenie jest niezawodne, ale może prowadzić do fałszywych alarmów w niektórych wersjach iOS. fork() można również zastąpić posix_spawn() w celu sprawdzenia możliwości uruchomienia procesu potomnego.

Sprawdzenie podpisu systemowego sandboxa

Próba odczytu plików w strefach zabronionych: /etc/master.passwd, /var/log/system.log, /private/var/cache. W stock iOS te odczyty zwracają błąd. Jeśli aplikacja pomyślnie odczytuje te pliki — sandbox jest wyłączony. Dodatkowo sprawdzana jest możliwość zapisu do /private/ — w piaskownicy wszystkie partycje systemowe są zamontowane jako tylko do odczytu dla zwykłych aplikacji.

Sprawdzenie symboli systemowych

Jailbreak modyfikuje biblioteki systemowe, w tym dyld shared cache. Sprawdzenie skrótu frameworków systemowych lub poszczególnych symboli może wykryć modyfikację. Dla iOS 14+ sprawdzana jest obecność symbolu jit_region_create lub innych oznak działania Fugu14/checkra1n w przestrzeni adresowej jądra przez odczyt sysctl kern.version.

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

    // Sprawdzenie dostępu do plików systemowych
    FILE *f = fopen("/etc/master.passwd", "r");
    if (f) {
        fclose(f);
        return YES;
    }

    // Sprawdzenie 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;
}

Natywna implementacja w Objective-C

Kod w Swift jest łatwo deasemblowany i omijany przez Substrate. Natywna implementacja w Objective-C z bezpośrednimi wywołaniami libobjc i funkcji systemowych C sprawia, że sprawdzenia są znacznie bardziej odporne na obejście.

Użycie stat() zamiast NSFileManager

Wywołanie stat() z libc nie może być przechwycone na poziomie Objective-C. Tweaki HideJB, przechwytujące metody NSFileManager, nie wpływają na stat(). Natywne sprawdzenie z stat() wykrywa wskaźniki plikowe nawet na urządzeniach z zainstalowanymi modułami HideJB. Połączenie stat() dla plików i dlopen() z RTLD_NOLOAD dla bibliotek daje dwa nieprzecinające się kanały wykrywania.

Sprawdzenie integralności podpisu kodu

Natywna funkcja SecStaticCodeCheckValidity sprawdza podpis kodu aplikacji pod kątem zgodności z certyfikatem Apple. Na urządzeniu z jailbreakiem to sprawdzenie może być podmienione przez kernel-patch. Aby obejść podmianę, należy wykonać sprawdzenie z kodu natywnego z wywołaniem przez dlopen() z Security.framework, a nie przez Swift Bridge.

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

- (BOOL)nativeCheckForJailbreak {
    // stat() obejście hooka NSFileManager
    struct stat st;
    if (stat("/Applications/Cydia.app", &st) == 0) {
        return YES;
    }

    // dlopen do sprawdzenia Substrate bez ładowania
    void *substrate = dlopen(
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        RTLD_NOLOAD
    );
    if (substrate) {
        dlclose(substrate);
        return YES;
    }

    return NO;
}

Metody omijania Jailbreak Detection

Zrozumienie technik obejścia jest niezbędne do zbudowania skutecznej ochrony. Nowoczesne narzędzia do obejścia aktywnie się rozwijają, a statyczny zestaw sprawdzeń staje się nieskuteczny w ciągu kilku miesięcy.

HideJB i Shadow

HideJB — tweak przechwytujący wywołania NSFileManager, stat(), dlopen() i fork() i podmieniający zwracane wartości. HideJB działa na poziomie Cydia Substrate, więc przechwytuje zarówno funkcje Objective-C, jak i C. Wersja HideJB dla iOS 15–16 (Shadow) wykorzystuje metodologię hooków na poziomie jądra. Kontr-środek: wykonanie sprawdzenia w oddzielnym procesie z przekazaniem wyniku przez IPC, co przerywa łańcuch hooków.

Choicy i Liberty Lite

Choicy umożliwia wyłączenie Substrate dla konkretnych procesów. Użytkownik po prostu wyłącza iniekcję dla chronionej aplikacji — wszystkie sprawdzenia bibliotek zwracają false. Liberty Lite — kompleksowe obejście, zamykające większość sprawdzeń z popularnych bibliotek ochrony. Kontr-środek: weryfikacja serwerowa przez DeviceCheck i App Attest — na serwerze sprawdzane jest, czy urządzenie posiada ważny certyfikat Apple, który nie może być sfałszowany na urządzeniu z jailbreakiem.

Obejście przez Fugu14 i KFD

Eksploity jądra, takie jak Fugu14 i KFD, wykonują kod w przestrzeni jądra (kernel-space), co umożliwia przechwytywanie wywołań systemowych zanim zobaczy je aplikacja. Na tym poziomie sprawdzenia stat() i fork() stają się nieskuteczne. Jedynym niezawodnym kontr-środkiem jest atestacja serwerowa z potwierdzeniem, że urządzenie przeszło procedurę Apple Attestation. Ten protokół opiera się na kluczach kryptograficznych wewnątrz Secure Enclave, które są niedostępne do odczytu nawet przy eksploicie na poziomie jądra.

Architektura bezpieczeństwa iOS i rola jailbreaka

Do zbudowania skutecznego Jailbreak Detection konieczne jest zrozumienie, które mechanizmy bezpieczeństwa iOS są wyłączane przy jailbreaku.

Secure Boot Chain

iOS uruchamia się poprzez sekwencję kontroli podpisów: Boot ROM → iBoot → iOS Kernel. Jeśli jailbreak wykorzystuje exploit bootrom (checkra1n), cały Secure Boot Chain jest skompromitowany — sprawdzenia na poziomie aplikacji są bezużyteczne. Jeśli używany jest exploit software-only (unc0ver, Taurine, Fugu14), łańcuch rozruchu nie jest naruszony, a usługi Apple, takie jak App Attest, pozostają zaufane.

Kernel Patch Protection (KPP)

Począwszy od iOS 10, Apple wdrożyło KPP — sprzętową ochronę, która ponownie sprawdza integralność jądra co 200 ms. Wszystkie nowoczesne jailbreaki (iOS 14–17) wykorzystują obejście KTRR przez PAC lub APRR, ale KPP pozostawia ślady w postaci zmodyfikowanych tablic systemowych sysctl. Sprawdzenie kern.version pod kątem obecności ciągów pwned, prod lub xnu z niestandardową wersją może wykryć obecność łatki jądra.

Sandbox Integrity

Piaskownica iOS działa na poziomie TrustedBSD, wykorzystując entitlements. Jailbreak podmienia profil sandboxa na allow-all. Aplikacja może sprawdzić sandbox poprzez próbę odczytu dowolnego pliku poza swoim katalogiem Documents. Jeśli się uda — sandbox został zmodyfikowany. Sandbox Integrity — jeden z niewielu wskaźników, którego nie można sfałszować bez eksploita na poziomie jądra, ponieważ sprawdzenie uprawnień wykonuje się w jądrze zanim może zostać przechwycone.