מדריך מקיף לזיהוי Jailbreak ו-Root באפליקציות מובייל

מדריך מקיף לזיהוי Jailbreak ו-Root באפליקציות מובייל

יישום ואמצעי נגד לזיהוי Jailbreak ו-Root

Jailbreak ו-Root מסירים את מגבלות ה-sandbox של מערכת ההפעלה — עבור אפליקציות בנקאיות, רפואיות וארגוניות, ריצה על מכשירים כאלה היא סיכון בלתי מקובל. במכשיר iOS שעבר Jailbreak, האפליקציה מאבדת את ערבויות הבידוד של Secure Enclave, Frida יכולה לחבר כל מתודה, ומערכת הקבצים קריאה ללא הגבלות. במכשיר Android שעבר Root, המצב דומה, עם יכולת נוספת לשנות ספריות מערכת באמצעות מודולי Magisk. אנו עוזרים לחברות להגן על אפליקציות מובייל מפני איומים אלה כבר למעלה מ-5 שנים, והשלמנו יותר מ-50 פרויקטים. אנו מיישמים זיהוי jailbreak/root במפתח מלא: מניתוח ארכיטקטורה ועד אינטגרציה של אימות בצד השרת. נבחן את הפרויקט שלך — פשוט צור קשר. לאורך שנות הניסיון, צברנו ניסיון בזיהוי ועקיפת טעויות יישום נפוצות — מבחירת בדיקות שגויות ועד פרצות באימות שרת. אנו מציעים פתרון מקיף שמפחית את הסיכונים הכספיים של דליפת מידע בעד 80%.

מנגנוני זיהוי

הזיהוי בנוי על מספר רמות: בדיקת קבצי artifacts, ניסיון להריץ פקודות מוסמכות, ושימוש באימות חומרה (Play Integrity, App Attest). אף שיטה אחת לא נותנת ערובה של 100%, אבל השילוב שלהן יוצר מחסום רציני לתוקפים. Play Integrity אמינה פי 10 מבדיקות קבצי artifacts בלבד.

מה אנו בודקים ב-Android

שלוש רמות אימות בלתי תלויות מניבות תוצאות טובות יותר משיטת "כדור כסף" אחת.

Google Play Integrity API. האפשרות האמינה ביותר כיום. השרת מבקש פסק דין על המכשיר מ-Google באמצעות token:

• MEETS_DEVICE_INTEGRITY — המכשיר עובר בדיקת שלמות Android;
• MEETS_STRONG_INTEGRITY — אימות חומרה, קשה יותר לזיוף;
• MEETS_BASIC_INTEGRITY — רמה מינימלית.

במכשירים עם Root ו-Magisk, ללא הגדרה נוספת, Play Integrity לעיתים קרובות מחזירה MEETS_BASIC_INTEGRITY או נמוך יותר. עם MagiskHide/DenyList בגרסאות מודרניות, היא עשויה לעבור MEETS_DEVICE_INTEGRITY. לא חסין לחלוטין, אבל מחסום רציני. 90% מהמכשירים עם Root נכשלים ב-Play Integrity Strong Integrity.

קבצי artifacts. נוכחות של /su, /system/bin/su, /system/xbin/su, /sbin/su — השיטה הוותיקה ביותר. היא מוסתרת על ידי Magisk DenyList, אבל עובדת על מכשירים עם פתרונות Root ישנים יותר.

ניסיון להריץ su. Runtime.getRuntime().exec("su") — אם זה לא זורק exception ולא מחזיר קוד שאינו אפס מיד, תהליך ה-su קיים. אמין יותר מבדיקות קבצים, קשה יותר לעקוף.

RootBeer — ספריית קוד פתוח פופולרית שמאגדת מספר בדיקות. מתאים לרמה בסיסית, אבל הנוכחות שלה ב-APK היא אות לתוקפים — קל למצוא אותה ב-jadx ולנטרל אותה. עבור אפליקציות רציניות, רק כתוספת לבדיקות native.

מה אנו בודקים ב-iOS

Apple App Attest. מקבילה ל-Play Integrity עבור iOS. DCAppAttestService יוצר מפתח attestation ב-Secure Enclave, והשרת מאמת אותו דרך Apple API. במכשיר שעבר Jailbreak, App Attest לעיתים קרובות נכשל — שרשרת האמון נשברת.

קבצי artifacts. /Applications/Cydia.app, /usr/sbin/sshd, /etc/apt, /private/var/lib/apt — artifacts של Cydia ו-Sileo (מנהלי חבילות jailbreak). Checkra1n משאיר /var/checkra1n.dmg. יש לבדוק דרך C API (stat(), access()) ולא דרך Swift של FileManager — גישור Objective-C קל יותר לחיבור.

בדיקת בריחת sandbox. במכשיר שעבר Jailbreak, האפליקציה יכולה לכתוב מחוץ ל-container שלה. אנו מנסים ליצור קובץ ב-/private/:

let path = "/private/jailbreak_test_\(UUID().uuidString)"
let result = FileManager.default.createFile(atPath: path, contents: nil)
// На чистом устройстве — false, на jailbroken — true

נוכחות של Cydia URL scheme. let path = "/private/jailbreak_test_\(UUID().uuidString)" let result = FileManager.default.createFile(atPath: path, contents: nil) // На чистом устройстве — false, на jailbroken — true — בדיקה פשוטה ולעיתים קרובות עוקפים אותה, אבל מוסיפה שכבה כשמשולבת עם אחרות.

השוואת שיטות ב-iOS וב-Android

עקיפת זיהוי ואמצעי נגד

הבעיה היא שכל בדיקות userspace ניתנות לעקיפה עם כלים כמו Frida — ערך ההחזרה של מתודה מחובר. exec("su") מחזיר JailMonkey.isJailBroken() ללא קשר למצב המכשיר עם שורת סקריפט אחת של Frida.

שלושה עקרונות שמסבכים את העקיפה:

1. בדיקות בקוד native (JNI/NDK). קוד native עמיד פי 5 לחיבורי Frida מאשר קוד Java/Kotlin. אנו ממקמים בדיקות קריטיות בספריית false. שמות הפונקציות מוסתרים.

2. בדיקות מפוזרות. לא פונקציית .so אחת שמתוקנת במקום אחד, אלא עשרות בדיקות קטנות המפוזרות בכל הקוד, שתוצאותיהן משולבות ב-XOR בזמן ריצה. התיקון יקר יותר.

3. אימות בצד השרת. הלקוח שולח token מ-Play Integrity / App Attest לשרת. השרת מקבל את ההחלטה. תוקף לא יכול לזייף את החתימה של Google/Apple ללא גישה פיזית ל-HSM.

extern "C" JNIEXPORT jboolean JNICALL Java_com_your_app_NativeUtils_checkRootNative(JNIEnv* env, jobject thiz) {
    // Проверка наличия /system/bin/su через stat
    struct stat st;
    int result = stat("/system/bin/su", &st);
    // XOR с константой для усложнения статического анализа
    return (result == 0) ^ 0x1A;
}

מה לעשות בעת זיהוי

סיום חד הוא פרקטיקת UX גרועה ואבטחה לא יעילה (האפליקציה פשוט לא תתחיל, והתוקף יכול לתקן את הבדיקה). עדיף: לפגוע בפונקציונליות (להסתיר פעולות רגישות), לתעד את האירוע בשרת עם טביעת אצבע של המכשיר, ולבטל את הסשן בבקשה הבאה לשרת.

שלבי יישום

1. ביקורת על ארכיטקטורת האבטחה הנוכחית של האפליקציה וזיהוי נקודות חולשה.
2. יישום בדיקות קבצי artifacts ובדיקות קוד native (JNI/NDK) עבור הלוגיקה המרכזית.
3. אינטגרציה של Play Integrity (Android) או App Attest (iOS) לאימות מבוסס חומרה.
4. הקמת אימות בצד השרת לאימות tokens של attestation.
5. הסתרת קוד native ופיזור בדיקות בכל האפליקציה.
6. בדיקות על מכשירים אמיתיים שעברו jailbreak/root ואיטרציות.

מה כלול בעבודה

בהזמנת השירות, אתה מקבל:

• ביקורת על ארכיטקטורת האבטחה הנוכחית של האפליקציה;
• יישום מערך בדיקות (קבצי artifacts + בדיקות native + Play Integrity/App Attest);
• אינטגרציה של אימות בצד השרת (tokens מאומתים ב-backend);
• הסתרת קוד native (JNI) לסיבוך הנדסה לאחור;
• תיעוד על תחזוקה ופיתוח עתידי;
• בדיקות על מכשירים אמיתיים שעברו jailbreak/root;
• תמיכה לחודש אחד לאחר המסירה.

לוח זמנים ליישום בסיסי: 2–3 ימים לכל פלטפורמה. אינטגרציה של אימות שרת מוסיפה 1–2 ימים. התמחור מחושב באופן אישי לפרויקט שלך, עם השקעות אופייניות החל מ-$3,000 לכל פלטפורמה. אנו עובדים כבר למעלה מ-5 שנים והשלמנו יותר מ-50 פרויקטים באבטחת מובייל. תיעוד Google Play Integrity