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 Integrity

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