Jailbreak Detection در برنامه‌های iOS: ماهیت، روش‌های تشخیص و بررسی

Jailbreak Detection چیست؟

Jailbreak Detection — فرآیند شناسایی دستگاه‌های iOS که محدودیت‌های سیستم عامل از آن‌ها برداشته شده است. جیلبریک هسته iOS را تغییر می‌دهد، امضای کد را غیرفعال می‌کند، به سیستم فایل کامل دسترسی می‌دهد و امکان بارگذاری کتابخانه‌های غیرمجاز را فراهم می‌کند. برای برنامه‌ای که روی چنین دستگاهی اجرا می‌شود، هیچ تضمینی برای یکپارچگی محیط اجرا وجود ندارد: هر فرآیندی می‌تواند حافظه برنامه را بخواند، ترافیک SSL/TLS را از طریق نصب گواهی‌های خود در انبار سیستم رهگیری کند و از طریق Cydia Substrate یا Substitute کد تزریق کند.

برنامه‌های مالی در iOS طبق الزامات استاندارد PCI DSS ملزم به پیاده‌سازی Jailbreak Detection هستند — برای صدور گواهی، برنامه باید ثابت کند که روی دستگاه به خطر افتاده اجرا نمی‌شود. OWASP Mobile Security (2024) عدم وجود Jailbreak Detection را به عنوان آسیب‌پذیری M8 طبقه‌بندی می‌کند. برای برنامه‌های App Store، اپل مسدود کردن عملکرد در دستگاه‌های جیلبریک شده را ممنوع نمی‌کند، اما توصیه می‌کند بررسی‌های سمت کلاینت و سمت سرور را ترکیب کنید تا صرفاً به کد کلاینتی که ممکن است تغییر یافته باشد تکیه نکنید.

معماری Jailbreak Detection در iOS به دلیل مدل sandbox پیچیده‌تر از Root Detection در اندروید است. در اندروید، برنامه می‌تواند /proc را برای تحلیل سیستم بخواند. sandbox iOS دسترسی مستقیم به اکثر نشانگرهای سیستمی را مسدود می‌کند. توسعه‌دهندگان مجبور به استفاده از تکنیک‌های دور زدن مانند بررسی در دسترس بودن فایل‌ها در مناطق ممنوعه از طریق API canAccessFile یا اجرای فرآیندهای فرزند از طریق fork() با بررسی کد خروجی هستند. بررسی‌های مدرن بر اساس تلاش برای انجام اقداماتی که فقط در جیلبریک امکان‌پذیر است و تحلیل نتیجه ساخته می‌شوند.

روش‌های فایلی تشخیص جیلبریک

ساده‌ترین و اولین رویکرد تاریخی — بررسی وجود فایل‌ها و برنامه‌هایی که فقط روی دستگاه‌های جیلبریک شده نصب می‌شوند. با وجود سادگی، بررسی‌های فایلی لایه پایه محافظت باقی می‌مانند، زیرا دور زدن آن‌ها نیاز به اقدامات فعال از سوی کاربر دارد.

بررسی بسته‌های جیلبریک

در دستگاه جیلبریک شده برنامه‌های 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;
}

بررسی‌های پویای زمان اجرا

بررسی‌های پویا اقداماتی را انجام می‌دهند که در sandbox iOS ممنوع هستند و نتیجه را تحلیل می‌کنند. اگر اقدام مسدود نشود — دستگاه به احتمال زیاد جیلبریک شده است.

بررسی fork() و posix_spawn()

در stock iOS، فراخوانی fork() با errno = EPERM مقدار -1 را برمی‌گرداند. در دستگاه جیلبریک شده، fork() می‌تواند اجرا شود زیرا محدودیت‌های sandbox برداشته شده‌اند. این بررسی قابل اعتماد است اما ممکن است در برخی نسخه‌های iOS نتایج مثبت کاذب ایجاد کند. fork() همچنین می‌تواند با posix_spawn() برای بررسی امکان راه‌اندازی فرآیند فرزند جایگزین شود.

بررسی امضای سیستمی sandbox

تلاش برای خواندن فایل‌ها در مناطق ممنوعه: /etc/master.passwd، /var/log/system.log، /private/var/cache. در stock iOS این خواندن‌ها خطا برمی‌گردانند. اگر برنامه با موفقیت این فایل‌ها را بخواند — sandbox غیرفعال شده است. همچنین امکان نوشتن در /private/ بررسی می‌شود — در sandbox همه پارتیشن‌های سیستمی برای برنامه‌های معمولی فقط خواندنی نصب شده‌اند.

بررسی نمادهای سیستمی

جیلبریک کتابخانه‌های سیستمی از جمله 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 امضای کد برنامه را از نظر مطابقت با گواهی اپل بررسی می‌کند. در دستگاه جیلبریک شده این بررسی می‌تواند از طریق kernel-patch جایگزین شود. برای جلوگیری از جایگزینی، باید بررسی را از کد بومی با فراخوانی از طریق dlopen() از Security.framework انجام داد، نه از طریق Swift Bridge.

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

- (BOOL)nativeCheckForJailbreak {
    // stat() عبور از hook NSFileManager
    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) از روش‌شناسی hooks در سطح هسته استفاده می‌کند. اقدام متقابل: انجام بررسی در یک فرآیند جداگانه با ارسال نتیجه از طریق IPC که زنجیره hook را قطع می‌کند.

Choicy و Liberty Lite

Choicy امکان غیرفعال کردن Substrate برای فرآیندهای خاص را فراهم می‌کند. کاربر به سادگی تزریق را برای برنامه محافظت شده غیرفعال می‌کند — همه بررسی‌های کتابخانه false برمی‌گردانند. Liberty Lite — دور زدن جامع که بیشتر بررسی‌های کتابخانه‌های محافظتی محبوب را پوشش می‌دهد. اقدام متقابل: تأیید سمت سرور از طریق DeviceCheck و App Attest — در سرور بررسی می‌شود که دستگاه دارای گواهی معتبر اپل است که در دستگاه جیلبریک شده قابل جعل نیست.

دور زدن از طریق Fugu14 و KFD

اکسپلویت‌های هسته مانند Fugu14 و KFD کد را در فضای هسته (kernel-space) اجرا می‌کنند که امکان رهگیری فراخوانی‌های سیستمی را قبل از دیدن آن‌ها توسط برنامه فراهم می‌کند. در این سطح، بررسی‌های stat() و fork() ناکارآمد می‌شوند. تنها اقدام متقابل قابل اعتماد — تأیید سمت سرور با بررسی اینکه دستگاه مراحل Apple Attestation را گذرانده است. این پروتکل بر اساس کلیدهای رمزنگاری داخل Secure Enclave است که حتی در اکسپلویت سطح هسته نیز قابل خواندن نیستند.

معماری امنیتی iOS و نقش جیلبریک

برای ایجاد یک Jailbreak Detection مؤثر، باید درک کرد که کدام مکانیزم‌های امنیتی iOS در هنگام جیلبریک غیرفعال می‌شوند.

Secure Boot Chain

iOS از طریق دنباله‌ای از بررسی‌های امضا بارگذاری می‌شود: Boot ROM → iBoot → iOS Kernel. اگر جیلبریک از اکسپلویت bootrom (checkra1n) استفاده کند، کل Secure Boot Chain به خطر افتاده است — بررسی‌ها در سطح برنامه بی‌فایده هستند. اگر از اکسپلویت software-only (unc0ver، Taurine، Fugu14) استفاده شود، زنجیره راه‌اندازی نقض نشده و سرویس‌های اپل مانند App Attest قابل اعتماد باقی می‌مانند.

Kernel Patch Protection (KPP)

از iOS 10 به بعد، اپل KPP — حفاظت سخت‌افزاری که یکپارچگی هسته را هر ۲۰۰ میلی‌ثانیه بررسی می‌کند — را پیاده‌سازی کرد. همه جیلبریک‌های مدرن (iOS 14–17) از دور زدن KTRR از طریق PAC یا APRR استفاده می‌کنند، اما KPP ردپاهایی به شکل جداول سیستمی sysctl تغییر یافته برجای می‌گذارد. بررسی kern.version برای وجود رشته‌های pwned، prod یا xnu با نسخه غیراستاندارد می‌تواند وجود patch هسته را آشکار کند.

یکپارچگی Sandbox

Sandbox iOS در سطح TrustedBSD با استفاده از entitlements کار می‌کند. جیلبریک پروفایل sandbox را به allow-all تغییر می‌دهد. برنامه می‌تواند sandbox را از طریق تلاش برای خواندن هر فایلی خارج از دایرکتوری Documents خود بررسی کند. اگر موفقیت‌آمیز باشد — sandbox تغییر یافته است. یکپارچگی Sandbox — یکی از معدود نشانگرهایی که بدون اکسپلویت سطح هسته قابل جعل نیست، زیرا بررسی مجوزها در هسته قبل از اینکه بتواند رهگیری شود انجام می‌شود.