Jailbreak Detection в приложенията за iOS: същност, методи за откриване и проверка

Какво е Jailbreak Detection?

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

Финансовите приложения за iOS са задължени да внедрят Jailbreak Detection според изискванията на стандарта PCI DSS — за сертификация приложението трябва да докаже, че не работи на компрометирано устройство. OWASP Mobile Security (2024) класифицира липсата на Jailbreak Detection като уязвимост M8. За приложенията в App Store Apple не забранява блокирането на функционалност на jailbreak-нати устройства, но препоръчва комбиниране на client-side и server-side проверки, за да не се разчита единствено на клиентски код, който може да бъде модифициран.

Архитектурата на Jailbreak Detection в iOS е по-сложна от Root Detection в Android поради модела на пясъчника. В Android приложението може да чете /proc за анализ на системата. Пясъчникът (sandbox) на iOS блокира директен достъп до повечето системни индикатори. Разработчиците са принудени да използват техники за заобикаляне, като проверка на достъпността на файлове в забранени зони чрез API canAccessFile или стартиране на дъщерни процеси чрез fork() с проверка на изходния код. Съвременните проверки се основават на опит за изпълнение на действия, достъпни само при jailbreak, и анализ на резултата.

Файлови методи за откриване на jailbreak

Най-простият и исторически първи подход — проверка за наличие на файлове и приложения, които се инсталират само на устройства с jailbreak. Въпреки простотата си, файловите проверки остават основен слой на защита, тъй като тяхното заобикаляне изисква активни действия от страна на потребителя.

Проверка на jailbreak пакети

На jailbreak-нато устройство присъстват приложенията Cydia, Sileo, Zebra или Installer. Тяхното наличие се проверява чрез NSFileManager: [[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]. Аналогично се проверяват пакетите от unc0ver, checkra1n, Taurine и Chimera. Тези проверки се заобикалят чрез HideJB туикове, които прихващат извикванията на NSFileManager.

Проверка на инструменти в /usr/bin

Jailbreak инсталира UNIX инструменти, недостъпни в stock iOS: apt, dpkg, ssh, rsync, sftp, dd, readlink и други. Проверява се съществуването на /usr/bin/ssh, /bin/bash, /bin/sh и /usr/libexec/sftp-server. При успешно откриване на който и да е от тези файлове вероятността за jailbreak е висока. За iOS 13–17 е актуално също проверяването на наличието на /var/jb — кореновата директория на bootstrap за unc0ver и Taurine.

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

MobileSubstrate (CydiaSubstrate.dylib) и Substitute — библиотеки за инжектиране на код в процеси. Тяхното наличие се проверява чрез dlopen() с флаг RTLD_NOLOAD. Ако библиотеката е заредена в адресното пространство — процесът работи в среда с jailbreak. Това е по-надеждна проверка, тъй като 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 пясъчника, и анализират резултата. Ако действието не е блокирано — устройството най-вероятно има jailbreak.

Проверка на fork() и posix_spawn()

В stock iOS извикването fork() връща -1 с errno = EPERM. На jailbreak-нато устройство fork() може да се изпълни, тъй като ограниченията на пясъчника са премахнати. Тази проверка е надеждна, но може да доведе до фалшиво положителни резултати на някои версии на iOS. fork() може също да бъде заменен с posix_spawn() за проверка на възможността за стартиране на дъщерен процес.

Проверка на системния подпис на пясъчника

Опит за четене на файлове в забранени зони: /etc/master.passwd, /var/log/system.log, /private/var/cache. В stock iOS тези четения връщат грешка. Ако приложението успешно чете тези файлове — пясъчникът е изключен. Допълнително се проверява възможността за запис в /private/ — в пясъчника всички системни дялове са монтирани като само за четене за обикновените приложения.

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

Jailbreak модифицира системни библиотеки, включително dyld shared cache. Проверката на хеша на системни frameworks или отделни символи може да разкрие модификация. За 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;
}

Native имплементация на Objective-C

Swift кодът лесно се дизасемблира и заобикаля чрез Substrate. Native имплементацията на Objective-C с директни извиквания на libobjc и системни функции на C прави проверките значително по-устойчиви на заобикаляне.

Използване на stat() вместо NSFileManager

Извикването stat() от libc не може да бъде прихванато на ниво Objective-C. HideJB туиковете, които прихващат методите на NSFileManager, не влияят на stat(). Native проверката с stat() открива файлови индикатори дори на устройства с инсталирани HideJB модули. Комбинацията от stat() за файлове и dlopen() с RTLD_NOLOAD за библиотеки дава два неприпокриващи се канала за откриване.

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

Native функцията SecStaticCodeCheckValidity проверява подписа на кода на приложението за съответствие със сертификата на Apple. На jailbreak-нато устройство тази проверка може да бъде заменена чрез kernel-patch. За да се избегне замяната, проверката трябва да се извърши от native код с извикване чрез 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 hook-ове. Контрамярка: извършване на проверката в отделен процес с предаване на резултата чрез IPC, което прекъсва веригата на hook-овете.

Choicy и Liberty Lite

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

Заобикаляне чрез Fugu14 и KFD

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

Архитектура на сигурността на iOS и ролята на jailbreak

За изграждане на ефективен Jailbreak Detection е необходимо да се разбере кои механизми за сигурност на iOS се изключват при jailbreak.

Secure Boot Chain

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

Kernel Patch Protection (KPP)

От iOS 10 нататък Apple внедри KPP — хардуерна защита, която проверява отново целостта на ядрото на всеки 200 ms. Всички съвременни jailbreak-ове (iOS 14–17) използват заобикаляне на KTRR чрез PAC или APRR, но KPP оставя следи под формата на модифицирани системни sysctl таблици. Проверката на kern.version за наличие на низове pwned, prod или xnu с нестандартна версия може да разкрие наличието на kernel patch.

Целост на пясъчника

Пясъчникът на iOS работи на ниво TrustedBSD, използвайки entitlements. Jailbreak заменя профила на пясъчника с allow-all. Приложението може да провери пясъчника чрез опит за четене на произволен файл извън своята директория Documents. Ако успее — пясъчникът е модифициран. Целост на пясъчника — един от малкото индикатори, който не може да бъде фалшифициран без kernel-level експлойт, тъй като проверката на разрешенията се извършва в ядрото, преди да може да бъде прихваната.