הגנה על אפליקציות מובייל מפני הנדסה הפוכה

הגנה על אפליקציות מובייל מפני הנדסה הפוכה

אנו מספקים שירותים להגנה על אפליקציות מובייל מפני הנדסה הפוכה. ללא ערפול (Obfuscation), תוקף המשתמש ב-apktool וב-jadx מקבל את מבנה ה-APK המלא: שמות מחלקות, לוגיקת אימות רישיון, כתובות endpoints. ב-iOS, class-dump משחזר כותרות Objective-C, ו-Ghidra מפרק קוד native. הניסיון שלנו מראה שאפילו הגנה מינימלית מפחיתה משמעותית את סיכוני דליפת המידע. אנו משלבים פתרונות מוכחים: מ-R8 המובנה ועד למעבדי ערפול מסחריים.

ערפול קוד

אנדרואיד. R8 (מובנה ב-Android Gradle Plugin) הוא נקודת הכניסה המינימלית. הפעל באמצעות minifyEnabled = true ב-build.gradle; הוא משנה שמות של מחלקות, מתודות ושדות ל-a, b, c. עם זאת, R8 אינו מצפין מחרוזות. הגנה רצינית על מחרוזות דורשת כלי נפרד.

יש לכתוב כללי ProGuard ידנית עבור כל ספרייה בשימוש—אחרת reflection, סריאליזציית Gson ו-Firebase עלולים להישבר. נקודת כאב אופיינית: @SerializedName על שדות מודל לא עוזרת אם המחלקה עצמה שונתה ל-a, ו-Gson לא יכול ליצור אותה באמצעות reflection. פתרון: השתמש ב-@Keep או בכללי -keep מפורשים עבור מחלקות נתונים המועברות דרך ה-API.

מעבדי ערפול מסחריים—DexGuard, iXGuard (מ-Guardsquare)—הולכים רחוק יותר: הצפנת מחרוזות, ערפול זרימת בקרה (הכנסת ענפים כוזבים ו-gotos), הגנה על משאבים ובדיקות אנטי-שיבוש. DexGuard משתלב כתוסף Gradle; התצורה שלו דומה ל-ProGuard אך מציעה יכולות רבות יותר. הוא נמצא בשימוש באפליקציות בנקאיות.

iOS. ערפול בינאריים של Swift/Objective-C קשה יותר—אין bytecode ביניים. אפשרויות: obfuscator-llvm (מעבר LLVM להחלקת זרימת בקרה) או iXGuard המסחרי. לא ניתן להסתיר שמות פונקציות Swift ב-API הציבורי מבלי לפגוע ב-ABI, אך ניתן לערפל לוגיקה פרטית.

Flutter. Dart מהדר לקוד מכונה, מה שמספק הגנה מסוימת מטבעו. reFlutter—כלי להנדסה הפוכה של אפליקציות Flutter—יכול לשחזר שמות מה-snapshot אם האפליקציה הודרה ללא strip symbols. כלול בבנייה: flutter build apk --obfuscate --split-debug-info=./symbols. סמלי debug עוברים לקובץ נפרד שאינו כלול בגרסת ה-release.

למה הצפנת מחרוזות חשובה

כתובות URL, מפתחות ושמות שרתים המקודדים בקוד הם המטרות הראשונות עבור strings על הבינארי. לכל הפחות, הימנע מאחסונם בקוד לחלוטין (משוך אותם לתצורה מרוחקת, למשל Firebase Remote Config). אם מחרוזת חייבת להישאר באפליקציה, הצפן ופענח בזמן ריצה באמצעות קוד native (JNI/NDK באנדרואיד) כך שטקסט פשוט לא יופיע ב-dex.

דפוס: מחרוזות המאוחסנות כמערכות בייטים מוצפנות XOR, עם מפתח XOR המפוצל בין פונקציות native שונות. לא חזק קריפטוגרפית, אך מעלה את רף הכניסה.

כיצד אנו מיישמים אנטי-דיבאגינג

ptrace(PTRACE_TRACEME, 0, 0, 0) באנדרואיד/לינוקס—התהליך הופך עצמו ל-tracee; חיבור ptrace שני מדיבאגר מחזיר שגיאה. ב-iOS, המקבילה היא PT_DENY_ATTACH. Frida עוקף זאת (באמצעות task_for_pid במקום ptrace), אך זה מוסיף מורכבות.

בדוק באמצעות /proc/self/status באנדרואיד: TracerPid != 0 פירושו שמחובר דיבאגר. מסגרת appdome מוסיפה בדיקות כאלה אוטומטית ללא שינויי קוד.

אנטי-Frida: Frida מזריק frida-agent לתהליך באמצעות frida-gadget. זהה על ידי בדיקת ספריות טעונות (/proc/self/maps), נוכחות פורט frida-server (27042), או שמות קבצים ב-/proc/self/fd. עם זאת, זיהוי ב-userspace נעקף על ידי Frida—מרוץ חימוש.

אימות שלמות

באנדרואיד, אמת את חתימת ה-APK בזמן ריצה: PackageManager.getPackageInfo() מחזיר רשימה של signatures. גזור מהם hash והשווה לערך קבוע. אם החתימה השתנתה, האפליקציה נארזה מחדש. הבדיקה עצמה חייבת להיות מוסתרת בקוד native; אחרת, ניתן לתקן אותה בקלות ב-smali.

Google Play Integrity API (תחליף ל-SafetyNet Attestation) אמין יותר: השרת מקבל token חתום על ידי Google עם פסקי דין MEETS_DEVICE_INTEGRITY, MEETS_STRONG_INTEGRITY. לא ניתן לזייף אותו ללא שרתי Google. חיסרון: דורש בקשת רשת ומכסות API.

ב-iOS—DCAppAttestService (App Attest). מנגנון דומה: המכשיר מקבל אישור מ-Apple, השרת מאמת באמצעות Apple API.

השוואת כלי ערפול

למהנדסים שלנו ניסיון של 5+ שנים ויישמו הגנה עבור 50+ אפליקציות מסחריות. אנו בוחרים את הכלי בהתאם לתקציב ולדרישות שלך.

קוד Native ו-React Native

לוגיקה עסקית שאין לחשוף מועברת ל-NDK (אנדרואיד) או למסגרת native (iOS). קוד Native קשה יותר להנדסה הפוכה מאשר Kotlin/Java או חבילות JavaScript.

React Native מאחסן את כל ה-JavaScript ב-index.android.bundle—קובץ פשוט בתוך ה-APK, קריא על ידי כל מעצב JS. הגנה: Hermes bytecode (הידור עם --hermes), הצפנת ה-bundle באמצעות מודול native שמפענח אותו בזיכרון לפני טעינה למנוע. Metro Bundler תומך בסריאלייזר מותאם אישית לכך.

השוואה: R8 מול DexGuard

DexGuard מספק הגנה גבוהה פי שלושה בשל הצפנת מחרוזות וערפול זרימת בקרה. עם זאת, עבור פרויקטים עם דרישות אבטחה נמוכות, R8 מספיק—חוסך בעלויות רישוי. הלקוחות שלנו שבחרו ב-DexGuard מדווחים על הפחתה של 40% בזמן הנדרש לתיקון פרצות.

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

• ביקורת של הבנייה הנוכחית וזיהוי נקודות חולשה
• תצורת R8/ProGuard עם כללי keep
• אינטגרציה של הצפנת מחרוזות באמצעות NDK (במידת הצורך)
• פיתוח והטמעה של בדיקות אנטי-דיבאגינג
• אינטגרציה של Play Integrity או App Attest
• בדיקות חדירה עם דוח
• תיעוד תצורה והדרכת צוות

לוחות זמנים

הגדרה בסיסית של R8/ProGuard עם הצפנת מחרוזות ובדיקות אנטי-שיבוש: 3–5 ימים. אינטגרציה של DexGuard/iXGuard עם כוונון עדין: עד שבועיים (איטרציות רבות כדי למנוע שבירת ריצה). העברה ל-native של לוגיקה קריטית: הערכה נפרדת לפי היקף.

לייעוץ בנושא הגנה על האפליקציה שלך, צור קשר. הזמן ביקורת פרצות וקבל דוח מפורט עם המלצות.