Jailbreak Detection у застосунках для iOS: суть, методи виявлення та перевірка

Що таке Jailbreak Detection?

Jailbreak Detection — процес ідентифікації iOS-пристроїв, на яких знято обмеження операційної системи. Джейлбрейк модифікує ядро iOS, вимикає код-підпис, надає доступ до повної файлової системи та дозволяє завантажувати неавторизовані бібліотеки. Для застосунку, що працює на такому пристрої, відсутні гарантії цілісності середовища виконання: будь-який процес може читати пам'ять застосунку, перехоплювати SSL/TLS-трафік через встановлення власних сертифікатів у сховищі системи та інжектувати код через Cydia Substrate або Substitute.

Фінансові застосунки під iOS зобов'язані впроваджувати Jailbreak Detection за вимогами стандарту PCI DSS — для сертифікації застосунок повинен доводити, що не працює на скомпрометованому пристрої. OWASP Mobile Security (2024) класифікує відсутність Jailbreak Detection як вразливість M8. Для застосунків App Store Apple не забороняє блокувати функціональність на джейлбрейкнутих пристроях, однак рекомендує поєднувати client-side та server-side перевірки, щоб не покладатися виключно на клієнтський код, який може бути модифікований.

Архітектура Jailbreak Detection в iOS складніша, ніж Root Detection в Android, через модель sandbox. На Android застосунок може читати /proc для аналізу системи. iOS-пісочниця (sandbox) блокує прямий доступ до більшості системних індикаторів. Розробники змушені використовувати обхідні техніки, такі як перевірка доступності файлів у заборонених зонах через API canAccessFile або запуск дочірніх процесів через fork() з перевіркою exit code. Сучасні перевірки будуються на спробі виконання дій, доступних тільки при джейлбрейку, та аналізі результату.

Файлові методи виявлення джейлбрейку

Найпростіший та історично перший підхід — перевірка наявності файлів та застосунків, які встановлюються тільки на пристроях з джейлбрейком. Незважаючи на примітивність, файлові перевірки залишаються базовим шаром захисту, оскільки їх обхід вимагає активних дій з боку користувача.

Перевірка пакетів джейлбрейку

На джейлбрейкнутому пристрої присутні застосунки Cydia, Sileo, Zebra або Installer. Їх наявність перевіряється через NSFileManager: [[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]. Аналогічно перевіряються пакети від unc0ver, checkra1n, Taurine та Chimera. Ці перевірки обходяться через HideJB-твіки, які перехоплюють виклики NSFileManager.

Перевірка утиліт в /usr/bin

Джейлбрейк встановлює UNIX-утиліти, недоступні в stock iOS: apt, dpkg, ssh, rsync, sftp, dd, readlink та інші. Перевіряється існування /usr/bin/ssh, /bin/bash, /bin/sh та /usr/libexec/sftp-server. При успішному виявленні будь-якого з цих файлів ймовірність джейлбрейку висока. Для iOS 13–17 актуально також перевіряти наявність /var/jb — кореневого каталогу bootstrap для unc0ver та Taurine.

Перевірка динамічних бібліотек

MobileSubstrate (CydiaSubstrate.dylib) та Substitute — бібліотеки для інжекції коду в процеси. Їх наявність перевіряється через dlopen() з прапором RTLD_NOLOAD. Якщо бібліотека завантажена в адресний простір — процес працює в середовищі з джейлбрейком. Це більш надійна перевірка, оскільки HideJB не може вивантажити вже завантажену в процес бібліотеку.

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

Динамічні перевірки часу виконання

Динамічні перевірки виконують дії, які в iOS-пісочниці заборонені, та аналізують результат. Якщо дію не заблоковано — пристрій, швидше за все, має джейлбрейк.

Перевірка fork() та posix_spawn()

У stock iOS виклик fork() повертає -1 з errno = EPERM. На джейлбрейкнутому пристрої fork() може виконатися, оскільки обмеження пісочниці знято. Ця перевірка надійна, але може призводити до хибних спрацьовувань на деяких версіях iOS. fork() також можна замінити на posix_spawn() для перевірки можливості запуску дочірнього процесу.

Перевірка системного підпису sandbox

Спроба читання файлів у заборонених зонах: /etc/master.passwd, /var/log/system.log, /private/var/cache. У stock iOS ці читання повертають помилку. Якщо застосунок успішно читає ці файли — sandbox вимкнено. Додатково перевіряється можливість запису в /private/ — у пісочниці всі системні розділи змонтовані як read-only для звичайних застосунків.

Перевірка системних символів

Джейлбрейк модифікує системні бібліотеки, включаючи dyld shared cache. Перевірка хешу системних фреймворків або окремих символів може виявити модифікацію. Для iOS 14+ перевіряється наявність символу jit_region_create або інших ознак роботи Fugu14/checkra1n в адресному просторі ядра через читання sysctl kern.version.

- (BOOL)isJailbrokenByRuntime {
    // Перевірка fork()
    int pid = fork();
    if (pid == 0) {
        exit(0);
    }
    if (pid > 0) {
        waitpid(pid, NULL, 0);
        return YES;
    }

    // Перевірка доступу до системних файлів
    FILE *f = fopen("/etc/master.passwd", "r");
    if (f) {
        fclose(f);
        return YES;
    }

    // Перевірка 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;
}

Нативна реалізація на Objective-C

Swift-код легко дизасемблюється та обходиться через Substrate. Нативна реалізація на Objective-C з прямими викликами libobjc та системних функцій C робить перевірки значно стійкішими до обходу.

Використання stat() замість NSFileManager

Виклик stat() з libc не може бути перехоплений на рівні Objective-C. HideJB-твіки, які перехоплюють методи NSFileManager, не впливають на stat(). Нативна перевірка з stat() виявляє файлові індикатори навіть на пристроях з встановленими HideJB-модулями. Комбінація stat() для файлів та dlopen() з RTLD_NOLOAD для бібліотек дає два непересічні канали виявлення.

Перевірка цілісності код-підпису

Нативна функція SecStaticCodeCheckValidity перевіряє код-підпис застосунку на відповідність сертифікату Apple. На джейлбрейкнутому пристрої ця перевірка може бути підмінена через kernel-patch. Для обходу підміни слід виконувати перевірку з нативного коду з викликом через dlopen() з Security.framework, а не через Swift Bridge.

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

- (BOOL)nativeCheckForJailbreak {
    // stat() обхід NSFileManager hook
    struct stat st;
    if (stat("/Applications/Cydia.app", &st) == 0) {
        return YES;
    }

    // dlopen для перевірки Substrate без завантаження
    void *substrate = dlopen(
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        RTLD_NOLOAD
    );
    if (substrate) {
        dlclose(substrate);
        return YES;
    }

    return NO;
}

Методи обходу Jailbreak Detection

Розуміння технік обходу необхідне для побудови стійкого захисту. Сучасні інструменти обходу активно розвиваються, і статичний набір перевірок стає неефективним протягом кількох місяців.

HideJB та Shadow

HideJB — твік, який перехоплює виклики NSFileManager, stat(), dlopen() та fork() і підмінює значення, що повертаються. HideJB працює на рівні Cydia Substrate, тому перехоплює як Objective-C, так і C-функції. Версія HideJB для iOS 15–16 (Shadow) використовує методологію kernel-level hooks. Контр-захід: виконання перевірки в окремому процесі з передачею результату через IPC, що розриває ланцюжок hook.

Choicy та Liberty Lite

Choicy дозволяє вимикати Substrate для конкретних процесів. Користувач просто вимикає інжекцію для захищеного застосунку — всі перевірки на бібліотеки повертають false. Liberty Lite — комплексний обхід, який закриває більшість перевірок з популярних бібліотек захисту. Контр-захід: серверна верифікація через DeviceCheck та App Attest — на сервері перевіряється, що пристрій має валідний Apple-сертифікат, який не може бути підроблений на джейлбрейкнутому пристрої.

Обхід через Fugu14 та KFD

Експлойти ядра, такі як Fugu14 та KFD, виконують код у просторі ядра (kernel-space), що дозволяє перехоплювати системні виклики до того, як їх побачить застосунок. На цьому рівні перевірки stat() та fork() стають неефективними. Єдина надійна контр-захід — серверна атестація з перевіркою, що пристрій пройшов процедуру Apple Attestation. Цей протокол заснований на криптографічних ключах всередині Secure Enclave, які недоступні для читання навіть при kernel-level експлойті.

Архітектура безпеки iOS та роль джейлбрейку

Для побудови ефективного Jailbreak Detection необхідно розуміти, які саме механізми безпеки iOS вимикаються при джейлбрейку.

Secure Boot Chain

iOS завантажується через послідовність перевірок підписів: Boot ROM → iBoot → iOS Kernel. Якщо джейлбрейк використовує bootrom exploit (checkra1n), весь Secure Boot Chain скомпрометований — перевірки на прикладному рівні марні. Якщо використовується software-only експлойт (unc0ver, Taurine, Fugu14), ланцюжок завантаження не порушено, і Apple-сервіси, такі як App Attest, залишаються довіреними.

Kernel Patch Protection (KPP)

Починаючи з iOS 10, Apple впровадила KPP — апаратний захист, який перевіряє цілісність ядра кожні 200 мс. Всі сучасні джейлбрейки (iOS 14–17) використовують KTRR bypass через PAC або APRR, але KPP залишає сліди у вигляді змінених системних таблиць sysctl. Перевірка kern.version на наявність рядків pwned, prod або xnu з нестандартною версією може виявити наявність kernel patch.

Цілісність Sandbox

iOS Sandbox працює на рівні TrustedBSD, використовуючи entitlements. Джейлбрейк підмінює sandbox profile на allow-all. Застосунок може перевірити sandbox через спробу читання будь-якого файлу поза своєю директорією Documents. Якщо успішно — sandbox модифіковано. Цілісність Sandbox — один з небагатьох індикаторів, який неможливо підробити без kernel-level експлойту, оскільки перевірка дозволів виконується в ядрі до того, як вона може бути перехоплена.