Jailbreak Detection ในแอปพลิเคชัน iOS: แก่นแท้ วิธีการตรวจจับ และการตรวจสอบ

Jailbreak Detection คืออะไร?

Jailbreak Detection คือกระบวนการระบุอุปกรณ์ iOS ที่ถูกลบข้อจำกัดของระบบปฏิบัติการออกไป เจลเบรกปรับเปลี่ยนเคอร์เนล iOS ปิดการใช้งานการเซ็นชื่อโค้ด ให้การเข้าถึงระบบไฟล์ทั้งหมด และอนุญาตให้โหลดไลบรารีที่ไม่ได้รับอนุญาต สำหรับแอปพลิเคชันที่ทำงานบนอุปกรณ์ดังกล่าว ไม่มีการรับประกันความสมบูรณ์ของสภาพแวดล้อมรันไทม์: โปรเซสใดๆ ก็สามารถอ่านหน่วยความจำของแอปพลิเคชัน ดักจับการรับส่งข้อมูล SSL/TLS โดยการติดตั้งใบรับรองของตัวเองในที่เก็บความน่าเชื่อถือของระบบ และฉีดโค้ดผ่าน Cydia Substrate หรือ Substitute

แอปพลิเคชันทางการเงินบน iOS จำเป็นต้องใช้ Jailbreak Detection ตามมาตรฐาน PCI DSS — สำหรับการรับรอง แอปพลิเคชันต้องพิสูจน์ว่าไม่ได้ทำงานบนอุปกรณ์ที่ถูกบุกรุก OWASP Mobile Security (2024) จัดประเภทการไม่มี Jailbreak Detection เป็นช่องโหว่ M8 สำหรับแอปพลิเคชัน App Store Apple ไม่ได้ห้ามการบล็อกฟังก์ชันการทำงานบนอุปกรณ์ที่เจลเบรกแล้ว แต่แนะนำให้รวมการตรวจสอบฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์เพื่อไม่ให้พึ่งพาเฉพาะโค้ดฝั่งไคลเอ็นต์ที่อาจถูกแก้ไข

สถาปัตยกรรมของ Jailbreak Detection บน iOS ซับซ้อนกว่า Root Detection บน Android เนื่องจากโมเดลแซนด์บ็อกซ์ บน Android แอปพลิเคชันสามารถอ่าน /proc เพื่อวิเคราะห์ระบบ แซนด์บ็อกซ์ของ iOS ปิดกั้นการเข้าถึงโดยตรงไปยังตัวบ่งชี้ระบบส่วนใหญ่ นักพัฒนาถูกบังคับให้ใช้เทคนิคทางเลือก เช่น การตรวจสอบความพร้อมใช้งานของไฟล์ในโซนที่ถูกห้ามผ่าน API canAccessFile หรือการเริ่มโปรเซสย่อยผ่าน fork() พร้อมการตรวจสอบรหัสออก การตรวจสอบสมัยใหม่สร้างขึ้นจากการพยายามดำเนินการที่ทำได้เฉพาะภายใต้เจลเบรกและวิเคราะห์ผลลัพธ์

วิธีการตรวจจับตามไฟล์

วิธีที่ง่ายที่สุดและเป็นวิธีแรกในประวัติศาสตร์คือการตรวจสอบการมีอยู่ของไฟล์และแอปพลิเคชันที่ติดตั้งบนอุปกรณ์ที่เจลเบรกแล้วเท่านั้น แม้จะเรียบง่าย การตรวจสอบไฟล์ยังคงเป็นชั้นการป้องกันพื้นฐาน เนื่องจากการเลี่ยงต้องอาศัยการดำเนินการที่ active จากผู้ใช้

การตรวจสอบแพ็กเกจเจลเบรก

บนอุปกรณ์ที่เจลเบรกแล้ว จะมีแอปพลิเคชันเช่น 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 ก็มีความเกี่ยวข้องเช่นกัน — ไดเรกทอรีรากบูตสแตรปสำหรับ 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 บนอุปกรณ์ที่เจลเบรกแล้ว การตรวจสอบนี้อาจถูกปลอมแปลงผ่านแพตช์เคอร์เนล เพื่อหลีกเลี่ยงการปลอมแปลง การตรวจสอบควรดำเนินการจากโค้ดเนทีฟด้วยการเรียกผ่าน 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;
}

วิธีการเลี่ยง Jailbreak Detection

การเข้าใจเทคนิคการเลี่ยงเป็นสิ่งจำเป็นสำหรับการสร้างการป้องกันที่แข็งแกร่ง เครื่องมือเลี่ยงสมัยใหม่กำลังพัฒนาอย่างต่อเนื่อง และชุดการตรวจสอบแบบคงที่ไม่มีประสิทธิภาพภายในไม่กี่เดือน

HideJB และ Shadow

HideJB เป็นทวิกที่ดักจับการเรียกไปยัง NSFileManager, stat(), dlopen() และ fork() และแทนที่ค่าที่ส่งคืน HideJB ทำงานในระดับ Cydia Substrate โดยดักจับทั้งฟังก์ชัน Objective-C และ C เวอร์ชันของ HideJB สำหรับ iOS 15–16 (Shadow) ใช้วิธีการฮุกระดับเคอร์เนล มาตรการตอบโต้: ดำเนินการตรวจสอบในโปรเซสแยกต่างหากพร้อมการส่งผลลัพธ์ผ่าน IPC ซึ่งจะทำลายห่วงโซ่ฮุค

Choicy และ Liberty Lite

Choicy อนุญาตให้ปิดการใช้งาน Substrate สำหรับโปรเซสเฉพาะ ผู้ใช้เพียงปิดการฉีดสำหรับแอปพลิเคชันที่ป้องกัน — การตรวจสอบไลบรารีทั้งหมดจะส่งคืน false Liberty Lite เป็นการเลี่ยงที่ครอบคลุมซึ่งครอบคลุมการตรวจสอบส่วนใหญ่จากไลบรารีการป้องกันยอดนิยม มาตรการตอบโต้: การตรวจสอบฝั่งเซิร์ฟเวอร์ผ่าน DeviceCheck และ App Attest — เซิร์ฟเวอร์ตรวจสอบว่าอุปกรณ์มีใบรับรอง Apple ที่ถูกต้องซึ่งไม่สามารถปลอมแปลงบนอุปกรณ์ที่เจลเบรกแล้วได้

การเลี่ยงผ่าน Fugu14 และ KFD

การหาประโยชน์จากเคอร์เนล เช่น Fugu14 และ KFD ดำเนินการโค้ดในสเปซเคอร์เนล ทำให้สามารถดักจับการเรียกของระบบก่อนที่แอปพลิเคชันจะเห็นได้ ในระดับนี้ การตรวจสอบ stat() และ fork() จะไม่มีประสิทธิภาพ มาตรการตอบโต้ที่เชื่อถือได้เพียงอย่างเดียวคือ การรับรองฝั่งเซิร์ฟเวอร์ พร้อมการตรวจสอบว่าอุปกรณ์ผ่านขั้นตอน Apple Attestation แล้ว โปรโตคอลนี้ขึ้นอยู่กับคีย์การเข้ารหัสภายใน Secure Enclave ซึ่งไม่สามารถอ่านได้แม้จะมีการหาประโยชน์ระดับเคอร์เนล

สถาปัตยกรรมความปลอดภัย iOS และบทบาทของเจลเบรก

เพื่อสร้าง Jailbreak Detection ที่มีประสิทธิภาพ จำเป็นต้องเข้าใจว่ากลไกความปลอดภัย iOS ใดบ้างที่ถูกปิดใช้งานระหว่างเจลเบรก

ห่วงโซ่การบูตอย่างปลอดภัย (Secure Boot Chain)

iOS บูตผ่านลำดับการตรวจสอบลายเซ็น: Boot ROM → iBoot → iOS Kernel หากเจลเบรกใช้การหาประโยชน์จาก bootrom (checkra1n) ห่วงโซ่การบูตอย่างปลอดภัยทั้งหมดจะถูกบุกรุก — การตรวจสอบในระดับแอปพลิเคชันไร้ประโยชน์ หากใช้การหาประโยชน์จากซอฟต์แวร์เท่านั้น (unc0ver, Taurine, Fugu14) ห่วงโซ่การบูตจะไม่ถูกทำลาย และบริการของ Apple เช่น App Attest ยังคงเชื่อถือได้

การป้องกันแพตช์เคอร์เนล (KPP)

เริ่มจาก iOS 10 Apple ได้นำ KPP มาใช้ — การป้องกันฮาร์ดแวร์ที่ตรวจสอบความสมบูรณ์ของเคอร์เนลอีกครั้งทุก 200 ms เจลเบรกสมัยใหม่ทั้งหมด (iOS 14–17) ใช้การเลี่ยง KTRR ผ่าน PAC หรือ APRR แต่ KPP ทิ้งร่องรอยในรูปแบบของตารางระบบ sysctl ที่ถูกแก้ไข การตรวจสอบ kern.version สำหรับการมีอยู่ของสตริงเช่น pwned, prod หรือ xnu พร้อมเวอร์ชันที่ไม่ได้มาตรฐานสามารถเปิดเผยแพตช์เคอร์เนลได้

ความสมบูรณ์ของแซนด์บ็อกซ์

แซนด์บ็อกซ์ iOS ทำงานในระดับ TrustedBSD โดยใช้สิทธิ์ (entitlements) เจลเบรกแทนที่โปรไฟล์แซนด์บ็อกซ์ด้วย allow-all แอปพลิเคชันสามารถตรวจสอบแซนด์บ็อกซ์โดยพยายามอ่านไฟล์ใดๆ นอกไดเรกทอรี Documents ของมัน หากสำเร็จ — แซนด์บ็อกซ์ถูกแก้ไขแล้ว ความสมบูรณ์ของแซนด์บ็อกซ์ เป็นหนึ่งในตัวบ่งชี้ไม่กี่ตัวที่ไม่สามารถปลอมแปลงได้หากไม่มีการหาประโยชน์ระดับเคอร์เนล เนื่องจากการตรวจสอบสิทธิ์จะดำเนินการในเคอร์เนลก่อนที่จะถูกดักจับ