Jailbreak Detection sa mga iOS app: esensya, mga paraan ng pagtuklas at pagsusuri

Ano ang Jailbreak Detection?

Jailbreak Detection — ang proseso ng pagtukoy ng mga iOS device kung saan inalis ang mga paghihigpit ng operating system. Binabago ng jailbreak ang kernel ng iOS, hindi pinapagana ang code signing, nagbibigay ng access sa buong file system at pinapayagan ang pag-load ng mga hindi awtorisadong library. Para sa isang app na tumatakbo sa naturang device, walang garantiya ng integridad ng kapaligiran ng pagpapatupad: anumang proseso ay maaaring magbasa ng memorya ng app, humarang ng SSL/TLS traffic sa pamamagitan ng pag-install ng sariling mga certificate sa system store, at mag-inject ng code sa pamamagitan ng Cydia Substrate o Substitute.

Ang mga financial app sa iOS ay kinakailangang magpatupad ng Jailbreak Detection ayon sa mga kinakailangan ng PCI DSS standard — para sa sertipikasyon, dapat patunayan ng app na hindi ito tumatakbo sa isang nakompromisong device. Inuuri ng OWASP Mobile Security (2024) ang kawalan ng Jailbreak Detection bilang vulnerability M8. Para sa mga App Store app, hindi ipinagbabawal ng Apple ang pagharang ng functionality sa mga jailbreak na device, ngunit inirerekomenda na pagsamahin ang client-side at server-side checks upang hindi umasa lamang sa client code na maaaring mabago.

Ang arkitektura ng Jailbreak Detection sa iOS ay mas kumplikado kaysa sa Root Detection sa Android dahil sa modelo ng sandbox. Sa Android, maaaring basahin ng app ang /proc para sa pagsusuri ng system. Hinaharangan ng iOS sandbox ang direktang pag-access sa karamihan ng mga system indicator. Ang mga developer ay napipilitang gumamit ng mga diskarte sa paglampas, tulad ng pagsusuri ng pagkakaroon ng file sa mga ipinagbabawal na zone sa pamamagitan ng canAccessFile API o paglulunsad ng mga child process sa pamamagitan ng fork() na may pagsusuri ng exit code. Ang mga modernong pagsusuri ay batay sa pagsubok na magsagawa ng mga aksyon na available lamang sa jailbreak at pagsusuri ng resulta.

Mga paraan ng pagtuklas ng jailbreak batay sa file

Ang pinakasimpleng at makasaysayang unang diskarte — pagsusuri ng pagkakaroon ng mga file at app na naka-install lamang sa mga jailbreak na device. Sa kabila ng pagiging simple, ang mga pagsusuri ng file ay nananatiling pangunahing layer ng proteksyon, dahil ang paglampas sa mga ito ay nangangailangan ng mga aktibong aksyon mula sa user.

Pagsusuri ng mga jailbreak package

Sa isang jailbreak na device, naroroon ang mga app na Cydia, Sileo, Zebra o Installer. Ang kanilang presensya ay sinusuri sa pamamagitan ng NSFileManager: [[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]. Katulad nito, ang mga package mula sa unc0ver, checkra1n, Taurine at Chimera ay sinusuri. Ang mga pagsusuring ito ay nilalampasan sa pamamagitan ng HideJB tweaks na humaharang ng mga tawag sa NSFileManager.

Pagsusuri ng mga utility sa /usr/bin

Ang jailbreak ay nag-i-install ng mga UNIX utility na hindi available sa stock iOS: apt, dpkg, ssh, rsync, sftp, dd, readlink at iba pa. Ang pagkakaroon ng /usr/bin/ssh, /bin/bash, /bin/sh at /usr/libexec/sftp-server ay sinusuri. Kapag matagumpay na natukoy ang alinman sa mga file na ito, mataas ang posibilidad ng jailbreak. Para sa iOS 13–17, mahalaga ring suriin ang pagkakaroon ng /var/jb — root directory ng bootstrap para sa unc0ver at Taurine.

Pagsusuri ng mga dynamic na library

Ang MobileSubstrate (CydiaSubstrate.dylib) at Substitute — mga library para sa pag-inject ng code sa mga proseso. Ang kanilang presensya ay sinusuri sa pamamagitan ng dlopen() na may flag na RTLD_NOLOAD. Kung ang library ay na-load sa address space — ang proseso ay tumatakbo sa isang kapaligiran na may jailbreak. Ito ay isang mas maaasahang pagsusuri dahil hindi maaaring i-unload ng HideJB ang isang library na na-load na sa proseso.

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

Mga dynamic na pagsusuri sa runtime

Ang mga dynamic na pagsusuri ay nagsasagawa ng mga aksyon na ipinagbabawal sa iOS sandbox at sinusuri ang resulta. Kung ang aksyon ay hindi naharang — ang device ay malamang na may jailbreak.

Pagsusuri ng fork() at posix_spawn()

Sa stock iOS, ang tawag na fork() ay nagbabalik ng -1 na may errno = EPERM. Sa isang jailbreak na device, ang fork() ay maaaring isagawa dahil ang mga paghihigpit ng sandbox ay inalis. Ang pagsusuring ito ay maaasahan ngunit maaaring magdulot ng false positives sa ilang bersyon ng iOS. Ang fork() ay maaari ring palitan ng posix_spawn() upang suriin ang posibilidad ng paglulunsad ng child process.

Pagsusuri ng system signature ng sandbox

Pagsubok na magbasa ng mga file sa mga ipinagbabawal na zone: /etc/master.passwd, /var/log/system.log, /private/var/cache. Sa stock iOS, ang mga pagbasang ito ay nagbabalik ng error. Kung matagumpay na nabasa ng app ang mga file na ito — ang sandbox ay hindi pinagana. Dagdag pa, ang posibilidad ng pagsulat sa /private/ ay sinusuri — sa sandbox, lahat ng system partition ay naka-mount bilang read-only para sa mga ordinaryong app.

Pagsusuri ng mga system symbol

Binabago ng jailbreak ang mga system library, kabilang ang dyld shared cache. Ang pagsusuri ng hash ng system frameworks o indibidwal na mga symbol ay maaaring makakita ng pagbabago. Para sa iOS 14+, ang pagkakaroon ng symbol na jit_region_create o iba pang mga palatandaan ng Fugu14/checkra1n sa kernel address space ay sinusuri sa pamamagitan ng pagbabasa ng sysctl kern.version.

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

    // Pagsusuri ng access sa mga system file
    FILE *f = fopen("/etc/master.passwd", "r");
    if (f) {
        fclose(f);
        return YES;
    }

    // Pagsusuri ng 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 na implementasyon sa Objective-C

Ang Swift code ay madaling ma-disassemble at malampasan sa pamamagitan ng Substrate. Ang native na implementasyon sa Objective-C na may direktang tawag sa libobjc at C system function ay ginagawang mas lumalaban sa paglampas ang mga pagsusuri.

Paggamit ng stat() sa halip na NSFileManager

Ang tawag na stat() mula sa libc ay hindi maaaring maharang sa antas ng Objective-C. Ang HideJB tweaks na humaharang ng mga pamamaraan ng NSFileManager ay hindi nakakaapekto sa stat(). Ang native na pagsusuri na may stat() ay nakakatuklas ng mga file indicator kahit sa mga device na may naka-install na HideJB modules. Ang kombinasyon ng stat() para sa mga file at dlopen() na may RTLD_NOLOAD para sa mga library ay nagbibigay ng dalawang hindi magkakapatong na channel ng pagtuklas.

Pagsusuri ng integridad ng code signature

Ang native function na SecStaticCodeCheckValidity ay sumusuri sa code signature ng app para sa pagsunod sa Apple certificate. Sa isang jailbreak na device, ang pagsusuring ito ay maaaring palitan sa pamamagitan ng kernel-patch. Upang maiwasan ang pagpapalit, ang pagsusuri ay dapat isagawa mula sa native code na may tawag sa pamamagitan ng dlopen() mula sa Security.framework, hindi sa pamamagitan ng Swift Bridge.

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

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

    // dlopen para suriin ang Substrate nang hindi naglo-load
    void *substrate = dlopen(
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        RTLD_NOLOAD
    );
    if (substrate) {
        dlclose(substrate);
        return YES;
    }

    return NO;
}

Mga paraan upang lampasan ang Jailbreak Detection

Ang pag-unawa sa mga diskarte sa paglampas ay kinakailangan para sa pagbuo ng matibay na proteksyon. Ang mga modernong tool sa paglampas ay aktibong umuunlad, at ang isang static na hanay ng mga pagsusuri ay nagiging hindi epektibo sa loob ng ilang buwan.

HideJB at Shadow

Ang HideJB — isang tweak na humaharang ng mga tawag sa NSFileManager, stat(), dlopen() at fork() at pinapalitan ang mga ibinalik na halaga. Gumagana ang HideJB sa antas ng Cydia Substrate, kaya hinaharang nito ang parehong Objective-C at C function. Ang bersyon ng HideJB para sa iOS 15–16 (Shadow) ay gumagamit ng kernel-level hook methodology. Kontra-m sukat: pagsasagawa ng pagsusuri sa isang hiwalay na proseso na may paglipat ng resulta sa pamamagitan ng IPC, na pumuputol sa chain ng hook.

Choicy at Liberty Lite

Pinapayagan ng Choicy na huwag paganahin ang Substrate para sa mga partikular na proseso. Ang user ay hindi pinapagana lamang ang injection para sa protektadong app — lahat ng pagsusuri ng library ay nagbabalik ng false. Liberty Lite — isang komprehensibong paglampas na sumasaklaw sa karamihan ng mga pagsusuri mula sa mga sikat na library ng proteksyon. Kontra-m sukat: server verification sa pamamagitan ng DeviceCheck at App Attest — sa server, sinusuri kung ang device ay may valid na Apple certificate na hindi maaaring pekein sa isang jailbreak na device.

Paglampas sa pamamagitan ng Fugu14 at KFD

Ang mga kernel exploit tulad ng Fugu14 at KFD ay nag-execute ng code sa kernel space, na nagpapahintulot sa pagharang ng mga system call bago makita ng app ang mga ito. Sa antas na ito, ang mga pagsusuri ng stat() at fork() ay nagiging hindi epektibo. Ang tanging maaasahang kontra-m sukat — server attestation na may pagsusuri na ang device ay dumaan sa Apple Attestation procedure. Ang protocol na ito ay batay sa cryptographic key sa loob ng Secure Enclave, na hindi nababasa kahit na sa kernel-level exploit.

Arkitektura ng seguridad ng iOS at papel ng jailbreak

Para sa pagbuo ng epektibong Jailbreak Detection, kinakailangang maunawaan kung aling mga mekanismo ng seguridad ng iOS ang hindi pinapagana sa jailbreak.

Secure Boot Chain

Ang iOS ay nagbo-boot sa pamamagitan ng isang sequence ng mga pagsusuri ng lagda: Boot ROM → iBoot → iOS Kernel. Kung ang jailbreak ay gumagamit ng bootrom exploit (checkra1n), ang buong Secure Boot Chain ay nakompromiso — ang mga pagsusuri sa antas ng app ay walang silbi. Kung ang software-only exploit (unc0ver, Taurine, Fugu14) ay ginagamit, ang boot chain ay hindi nilalabag, at ang mga serbisyo ng Apple tulad ng App Attest ay nananatiling mapagkakatiwalaan.

Kernel Patch Protection (KPP)

Simula sa iOS 10, ipinatupad ng Apple ang KPP — isang hardware protection na muling sumusuri sa integridad ng kernel bawat 200 ms. Lahat ng modernong jailbreak (iOS 14–17) ay gumagamit ng KTRR bypass sa pamamagitan ng PAC o APRR, ngunit ang KPP ay nag-iiwan ng mga bakas sa anyo ng mga binagong sysctl system table. Ang pagsusuri ng kern.version para sa pagkakaroon ng mga string na pwned, prod o xnu na may hindi karaniwang bersyon ay maaaring makakita ng pagkakaroon ng kernel patch.

Sandbox Integrity

Ang iOS Sandbox ay gumagana sa antas ng TrustedBSD gamit ang entitlements. Pinapalitan ng jailbreak ang sandbox profile sa allow-all. Maaaring suriin ng app ang sandbox sa pamamagitan ng pagsubok na magbasa ng anumang file sa labas ng direktoryo ng Documents nito. Kung matagumpay — ang sandbox ay nabago. Sandbox Integrity — isa sa ilang mga indicator na hindi maaaring pekein nang walang kernel-level exploit, dahil ang pagsusuri ng pahintulot ay isinasagawa sa kernel bago ito maharang.