كشف الاختراق في تطبيقات iOS: الجوهر وطرق الكشف والتحقق

ما هو كشف الاختراق (Jailbreak Detection)؟

كشف الاختراق (Jailbreak Detection) هو عملية تحديد أجهزة iOS التي تمت إزالة قيود نظام التشغيل منها. يعدل الاختراق نواة iOS، ويعطل توقيع الكود، ويوفر الوصول إلى نظام الملفات الكامل، ويسمح بتحميل مكتبات غير مصرح بها. بالنسبة لتطبيق يعمل على مثل هذا الجهاز، لا توجد ضمانات لسلامة بيئة التشغيل: يمكن لأي عملية قراءة ذاكرة التطبيق، واعتراض حركة مرور SSL/TLS عن طريق تثبيت شهاداتها الخاصة في مخزن الثقة للنظام، وحقن الكود عبر Cydia Substrate أو Substitute.

التطبيقات المالية على iOS ملزمة بتنفيذ كشف الاختراق وفقًا لمتطلبات معيار PCI DSS — للحصول على الشهادة، يجب على التطبيق إثبات أنه لا يعمل على جهاز مخترق. يصنف OWASP Mobile Security (2024) غياب كشف الاختراق كثغرة M8. بالنسبة لتطبيقات App Store، لا تحظر Apple حظر الوظائف على الأجهزة المخترقة، لكنها توصي بالجمع بين فحوصات جانب العميل وجانب الخادم لتجنب الاعتماد فقط على كود العميل الذي قد يتم تعديله.

هندسة كشف الاختراق على iOS أكثر تعقيدًا من كشف الجذر (Root Detection) على Android بسبب نموذج وضع الحماية (sandbox). على Android، يمكن للتطبيق قراءة /proc لتحليل النظام. يمنع وضع حماية iOS (sandbox) الوصول المباشر إلى معظم مؤشرات النظام. يضطر المطورون إلى استخدام تقنيات بديلة مثل التحقق من توفر الملفات في المناطق المحظورة عبر API canAccessFile أو تشغيل العمليات التابعة عبر fork() مع التحقق من رمز الخروج. تُبنى الفحوصات الحديثة على محاولة تنفيذ إجراءات متاحة فقط تحت الاختراق وتحليل النتيجة.

طرق الكشف المعتمدة على الملفات

النهج الأبسط والأول تاريخيًا هو التحقق من وجود ملفات وتطبيقات يتم تثبيتها فقط على الأجهزة المخترقة. على الرغم من بساطتها، تظل فحوصات الملفات طبقة أساسية من الدفاع، حيث أن تجاوزها يتطلب إجراءً نشطًا من المستخدم.

التحقق من حزم الاختراق

على الجهاز المخترق، توجد تطبيقات مثل Cydia و Sileo و Zebra أو Installer. يتم التحقق من وجودها عبر NSFileManager: [[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]. يتم التحقق من حزم unc0ver و checkra1n و Taurine و Chimera بالمثل. يمكن تجاوز هذه الفحوصات من خلال إضافات HideJB التي تعترض استدعاءات NSFileManager.

التحقق من الأدوات في /usr/bin

يثبت الاختراق أدوات UNIX غير متوفرة في 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()

في iOS الأصلي، يعيد استدعاء fork() -1 مع errno = EPERM. على الجهاز المخترق، قد ينجح fork() نظرًا لإزالة قيود وضع الحماية. هذا الفحص موثوق ولكنه قد يؤدي إلى نتائج إيجابية خاطئة في بعض إصدارات iOS. يمكن أيضًا استبدال fork() بـ posix_spawn() للتحقق من القدرة على تشغيل عملية تابعة.

التحقق من توقيع نظام وضع الحماية

محاولة قراءة الملفات في المناطق المحظورة: /etc/master.passwd، /var/log/system.log، /private/var/cache. في iOS الأصلي، تعيد هذه القراءات خطأ. إذا قرأ التطبيق هذه الملفات بنجاح — فإن وضع الحماية معطل. بالإضافة إلى ذلك، يتم التحقق من القدرة على الكتابة في /private/ — في وضع الحماية، جميع أقسام النظام مثبتة للقراءة فقط للتطبيقات العادية.

التحقق من رموز النظام

يعدل الاختراق مكتبات النظام، بما في ذلك ذاكرة التخزين المؤقت المشتركة dyld. يمكن أن يكشف التحقق من تجزئة أطر العمل النظامية أو الرموز الفردية عن التعديل. بالنسبة لنظام 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. لتجنب التزوير، يجب إجراء الفحص من الكود الأصلي مع استدعاء عبر dlopen() من Security.framework، وليس عبر Swift Bridge.

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

- (BOOL)nativeCheckForJailbreak {
    // stat() يتجاوز خطاف 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;
}

طرق تجاوز كشف الاختراق

فهم تقنيات التجاوز ضروري لبناء حماية قوية. أدوات التجاوز الحديثة تتطور بنشاط، والمجموعة الثابتة من الفحوصات تصبح غير فعالة في غضون أشهر.

HideJB و Shadow

HideJB هي إضافة تعترض استدعاءات NSFileManager و stat() و dlopen() و fork()، وتستبدل القيم المُعادة. يعمل HideJB على مستوى Cydia Substrate، حيث يعترض كل من وظائف Objective-C و C. تستخدم إصدارات HideJB لنظام iOS 15–16 (Shadow) منهجية خطافات (hooks) على مستوى kernel. الإجراء المضاد: إجراء الفحص في عملية منفصلة مع تسليم النتيجة عبر IPC، مما يكسر سلسلة الخطافات.

Choicy و Liberty Lite

يسمح Choicy بتعطيل Substrate لعمليات محددة. يقوم المستخدم ببساطة بتعطيل الحقن للتطبيق المحمي — جميع فحوصات المكتبات تعيد false. Liberty Lite هو تجاوز شامل يغطي معظم الفحوصات من مكتبات الحماية الشائعة. الإجراء المضاد: التحقق من جانب الخادم عبر DeviceCheck و App Attest — يتحقق الخادم من أن الجهاز لديه شهادة Apple صالحة لا يمكن تزويرها على جهاز مخترق.

التجاوز عبر Fugu14 و KFD

استغلالات ثغرات kernel، مثل Fugu14 و KFD، تنفذ كودًا في مساحة kernel، مما يسمح باعتراض استدعاءات النظام قبل أن يراها التطبيق. على هذا المستوى، تصبح فحوصات stat() و fork() غير فعالة. الإجراء المضاد الوحيد الموثوق به هو التوثيق من جانب الخادم مع التحقق من أن الجهاز قد اجتاز إجراء توثيق Apple (Apple Attestation). يعتمد هذا البروتوكول على مفاتيح تشفير داخل Secure Enclave، والتي لا يمكن قراءتها حتى مع استغلال على مستوى kernel.

هندسة أمان iOS ودور الاختراق

لبناء كشف اختراق فعال، من الضروري فهم آليات أمان iOS التي يتم تعطيلها أثناء الاختراق.

سلسلة الإقلاع الآمن (Secure Boot Chain)

يقلع iOS من خلال سلسلة من فحوصات التوقيع: Boot ROM → iBoot → iOS Kernel. إذا استخدم الاختراق استغلال bootrom (checkra1n)، يتم اختراق سلسلة الإقلاع الآمن بأكملها — الفحوصات على مستوى التطبيق غير مجدية. إذا تم استخدام استغلال برمجي فقط (unc0ver، Taurine، Fugu14)، لا يتم كسر سلسلة الإقلاع، وتبقى خدمات Apple مثل App Attest موثوقة.

حماية تصحيح Kernel (KPP)

بدءًا من iOS 10، قدمت Apple KPP — حماية أجهزة تعيد التحقق من سلامة kernel كل 200 مللي ثانية. تستخدم جميع الاختراقات الحديثة (iOS 14–17) تجاوز KTRR عبر PAC أو APRR، لكن KPP تترك آثارًا في شكل جداول sysctl معدلة. يمكن أن يكشف التحقق من kern.version عن وجود سلاسل مثل pwned أو prod أو xnu بإصدار غير قياسي عن وجود تصحيح kernel.

سلامة وضع الحماية (Sandbox Integrity)

يعمل وضع حماية iOS على مستوى TrustedBSD باستخدام الصلاحيات (entitlements). يستبدل الاختراق ملف تعريف وضع الحماية بـ allow-all. يمكن للتطبيق التحقق من وضع الحماية بمحاولة قراءة أي ملف خارج دليل Documents الخاص به. إذا نجح — فقد تم تعديل وضع الحماية. سلامة وضع الحماية هي واحدة من المؤشرات القليلة التي لا يمكن تزويرها دون استغلال على مستوى kernel، حيث يتم التحقق من الأذونات في kernel قبل أن يمكن اعتراضها.