Jailbreak Detection i iOS-appar: essens, detekteringsmetoder och kontroll

Vad är Jailbreak Detection?

Jailbreak Detection — processen att identifiera iOS-enheter där operativsystemets begränsningar har tagits bort. Jailbreak modifierar iOS-kärnan, inaktiverar kodsignering, ger åtkomst till hela filsystemet och möjliggör inläsning av obehöriga bibliotek. För en app som körs på en sådan enhet finns inga garantier för exekveringsmiljöns integritet: vilken process som helst kan läsa appens minne, avlyssna SSL/TLS-trafik genom att installera egna certifikat i systemets lagring och injicera kod via Cydia Substrate eller Substitute.

Finansiella appar på iOS är skyldiga att implementera Jailbreak Detection enligt kraven i PCI DSS-standarden — för certifiering måste appen bevisa att den inte körs på en komprometterad enhet. OWASP Mobile Security (2024) klassificerar avsaknaden av Jailbreak Detection som sårbarhet M8. För App Store-appar förbjuder Apple inte blockering av funktionalitet på jailbreakade enheter, men rekommenderar att kombinera client-side- och server-side-kontroller för att inte enbart förlita sig på klientkod som kan modifieras.

Arkitekturen för Jailbreak Detection i iOS är mer komplex än Root Detection i Android på grund av sandlådemodellen. På Android kan en app läsa /proc för systemanalys. iOS-sandlådan blockerar direkt åtkomst till de flesta systemindikatorer. Utvecklare tvingas använda kringgåendetekniker som att kontrollera filers tillgänglighet i förbjudna zoner via canAccessFile-API:t eller starta barnprocesser via fork() med kontroll av utgångskod. Moderna kontroller bygger på att försöka utföra åtgärder som endast är möjliga vid jailbreak och analysera resultatet.

Filbaserade metoder för jailbreak-detektering

Det enklaste och historiskt första tillvägagångssättet — kontroll av förekomsten av filer och appar som endast installeras på jailbreakade enheter. Trots sin enkelhet förblir filkontroller ett grundläggande skyddslager, eftersom deras kringgående kräver aktiva åtgärder från användaren.

Kontroll av jailbreak-paket

På en jailbreakad enhet finns apparna Cydia, Sileo, Zebra eller Installer. Deras närvaro kontrolleras via NSFileManager: [[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]. Liknande kontroller görs för paket från unc0ver, checkra1n, Taurine och Chimera. Dessa kontroller kringgås via HideJB-tweaks som avlyssnar NSFileManager-anrop.

Kontroll av verktyg i /usr/bin

Jailbreak installerar UNIX-verktyg som inte är tillgängliga i stock iOS: apt, dpkg, ssh, rsync, sftp, dd, readlink och andra. Förekomsten av /usr/bin/ssh, /bin/bash, /bin/sh och /usr/libexec/sftp-server kontrolleras. Vid framgångsrik detektering av någon av dessa filer är sannolikheten för jailbreak hög. För iOS 13–17 är det också relevant att kontrollera förekomsten av /var/jb — rotkatalogen för bootstrap för unc0ver och Taurine.

Kontroll av dynamiska bibliotek

MobileSubstrate (CydiaSubstrate.dylib) och Substitute — bibliotek för kodinjicering i processer. Deras närvaro kontrolleras via dlopen() med flaggan RTLD_NOLOAD. Om biblioteket är laddat i adressutrymmet — körs processen i en jailbreak-miljö. Detta är en mer tillförlitlig kontroll eftersom HideJB inte kan avlasta ett redan laddat bibliotek från processen.

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

Dynamiska runtime-kontroller

Dynamiska kontroller utför åtgärder som är förbjudna i iOS-sandlådan och analyserar resultatet. Om åtgärden inte blockeras — har enheten med största sannolikhet jailbreak.

Kontroll av fork() och posix_spawn()

I stock iOS returnerar anropet fork() -1 med errno = EPERM. På en jailbreakad enhet kan fork() exekveras eftersom sandlådebegränsningarna har tagits bort. Denna kontroll är tillförlitlig men kan leda till falska positiva resultat på vissa iOS-versioner. fork() kan också ersättas med posix_spawn() för att kontrollera möjligheten att starta en barnprocess.

Kontroll av sandlådans system signatur

Försök att läsa filer i förbjudna zoner: /etc/master.passwd, /var/log/system.log, /private/var/cache. I stock iOS returnerar dessa läsningar ett fel. Om appen framgångsrikt läser dessa filer — är sandlådan inaktiverad. Dessutom kontrolleras möjligheten att skriva till /private/ — i sandlådan är alla systempartitioner monterade som skrivskyddade för vanliga appar.

Kontroll av system symboler

Jailbreak modifierar systembibliotek, inklusive dyld shared cache. Kontroll av hash för systemramverk eller enskilda symboler kan avslöja modifiering. För iOS 14+ kontrolleras förekomsten av symbolen jit_region_create eller andra tecken på Fugu14/checkra1n i kärnans adressutrymme via läsning av sysctl kern.version.

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

    // Kontroll av åtkomst till systemfiler
    FILE *f = fopen("/etc/master.passwd", "r");
    if (f) {
        fclose(f);
        return YES;
    }

    // Kontroll av 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 implementering i Objective-C

Swift-kod är lätt att disassemblera och kringgå via Substrate. Native implementering i Objective-C med direkta anrop till libobjc och C-systemfunktioner gör kontrollerna betydligt mer motståndskraftiga mot kringgående.

Användning av stat() istället för NSFileManager

Anropet stat() från libc kan inte avlyssnas på Objective-C-nivå. HideJB-tweaks som avlyssnar NSFileManager-metoder påverkar inte stat(). Native kontroll med stat() detekterar filindikatorer även på enheter med installerade HideJB-moduler. Kombinationen av stat() för filer och dlopen() med RTLD_NOLOAD för bibliotek ger två icke-överlappande detekteringskanaler.

Kontroll av kodsignaturens integritet

Den nativa funktionen SecStaticCodeCheckValidity kontrollerar appens kodsignatur för överensstämmelse med Apple-certifikatet. På en jailbreakad enhet kan denna kontroll ersättas via kernel-patch. För att undvika ersättning bör kontrollen utföras från native kod med anrop via dlopen() från Security.framework, inte via Swift Bridge.

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

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

    // dlopen för att kontrollera Substrate utan inladdning
    void *substrate = dlopen(
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        RTLD_NOLOAD
    );
    if (substrate) {
        dlclose(substrate);
        return YES;
    }

    return NO;
}

Metoder för att kringgå Jailbreak Detection

Förståelse av kringgåendetekniker är nödvändig för att bygga ett hållbart skydd. Moderna kringgåendeverktyg utvecklas aktivt och en statisk uppsättning kontroller blir ineffektiv inom några månader.

HideJB och Shadow

HideJB — en tweak som avlyssnar NSFileManager-, stat()-, dlopen()- och fork()-anrop och ersätter returvärden. HideJB fungerar på Cydia Substrate-nivå och avlyssnar därför både Objective-C- och C-funktioner. HideJB-versionen för iOS 15–16 (Shadow) använder kernel-level-hook-metodologi. Motåtgärd: utföra kontrollen i en separat process med överföring av resultatet via IPC, vilket bryter hook-kedjan.

Choicy och Liberty Lite

Choicy gör det möjligt att inaktivera Substrate för specifika processer. Användaren inaktiverar helt enkelt injicering för den skyddade appen — alla bibliotekskontroller returnerar false. Liberty Lite — omfattande kringgående som täcker de flesta kontroller från populära skyddsbibliotek. Motåtgärd: serververifiering via DeviceCheck och App Attest — på servern kontrolleras att enheten har ett giltigt Apple-certifikat som inte kan förfalskas på en jailbreakad enhet.

Kringgående via Fugu14 och KFD

Kärnexploater som Fugu14 och KFD exekverar kod i kärnutrymmet (kernel-space), vilket möjliggör avlyssning av systemanrop innan appen ser dem. På denna nivå blir stat()- och fork()-kontroller ineffektiva. Den enda tillförlitliga motåtgärden — serverattestering med kontroll att enheten har genomgått Apple Attestation-proceduren. Detta protokoll är baserat på kryptografiska nycklar inuti Secure Enclave, som inte är läsbara ens vid en kernel-level-exploit.

iOS säkerhetsarkitektur och jailbreakets roll

För att bygga ett effektivt Jailbreak Detection är det nödvändigt att förstå vilka säkerhetsmekanismer i iOS som inaktiveras vid jailbreak.

Secure Boot Chain

iOS startar genom en sekvens av signaturkontroller: Boot ROM → iBoot → iOS Kernel. Om jailbreaket använder en bootrom-exploit (checkra1n) är hela Secure Boot Chain komprometterad — kontroller på applikationsnivå är värdelösa. Om en software-only-exploit (unc0ver, Taurine, Fugu14) används är startkedjan inte bruten och Apple-tjänster som App Attest förblir pålitliga.

Kernel Patch Protection (KPP)

Från och med iOS 10 implementerade Apple KPP — ett hårdvaruskydd som kontrollerar kärnans integritet var 200:e ms. Alla moderna jailbreak (iOS 14–17) använder KTRR-kringgående via PAC eller APRR, men KPP lämnar spår i form av modifierade sysctl-systemtabeller. Kontroll av kern.version för förekomst av strängarna pwned, prod eller xnu med en icke-standard version kan avslöja förekomsten av en kernel-patch.

Sandlådeintegritet

iOS-sandlådan fungerar på TrustedBSD-nivå med entitlements. Jailbreak ersätter sandlådeprofilen med allow-all. En app kan kontrollera sandlådan genom att försöka läsa en fil utanför sin Documents-katalog. Om det lyckas — är sandlådan modifierad. Sandlådeintegritet — en av få indikatorer som inte kan förfalskas utan en kernel-level-exploit, eftersom behörighetskontrollen utförs i kärnan innan den kan avlyssnas.