كيف قدرت اخترق تطبيق جوال +35 مليون مستخدم من خلال رسالة وحدة؟
مساكم الله بالخير جميعا
اليوم بتكلم عن احد تطبيقات الجوال وسلسلة ثغرات قدرت استغلهم مع بعض لتحقيق اثر عالي وقدرة على اختراق اكثر من 35 مليون حساب والأخطر بدون اي تفاعل من المستخدم
خلال المقالة بتطرق لعدة اشياء بداية من تخطي حماية الابلكيشن على مستوى الـ App Protection ومن ثم الثغرات على مستوى الـ Network
اذا تبغى تسكب شرح تخطي الحماية وتدخل بالثغرات بشكل مباشر يمديك تبدا من قسم Deep Link Execution
فنسمي بالله ونبدا
---
فالبداية خل نعرف كيف بنية الابلكيشن كان عبارة عن
split APK architecture
```java
base.apk ← core application
split_component_lingdong.apk ← stupid crypto stuff
split_config.arm64_v8a.apk ← native libraries
split_resource.apk ← resources
```الجزء اللي كان يهمني أكثر هنا هو
الـ Native Libraries
لأن التطبيق كان يستخدم عدة طبقات حماية مثل
SSL Pinning & Root Detection
الـ Native Libraries
لأن التطبيق كان يستخدم عدة طبقات حماية مثل
SSL Pinning & Root Detection
---
## #2 تخطي حماية التطبيق (SSL Pinning & Root detection)
بعد مافهمنا بنية التطبيق الحين جاء وقته نبدا بالفحص التطبيق بال runtime
كان فيه (ssl pinning & root detection)
وبطبيعة الحال قبل لاتدخل بقروشة ال static anlyisys
جربت حلول بسيطة مثل Java based hoking scripts
و Shamiko and lsposed stuff
وشيء متوقع انه ولا وحدة منهم ضبطت
والواضح انه protection stack was custom engineered
كان فيه (ssl pinning & root detection)
وبطبيعة الحال قبل لاتدخل بقروشة ال static anlyisys
جربت حلول بسيطة مثل Java based hoking scripts
و Shamiko and lsposed stuff
وشيء متوقع انه ولا وحدة منهم ضبطت
والواضح انه protection stack was custom engineered
---
بعد محاولات مع الحلول الاعتيادية والي ولا وحدة منهم ضبطت وهنا كان لازم نتدخل
بديت بتحليل الابلكيشن ولقيت احد
ال native library
باسم "libintegrity(dot)so"
والواضح ان ال Detection stack كان من خلاله وفعلا بعد تحليل
ال libintegrity native library
اتضح لي انه تمر على أربع مراحل وكلها تكون بال Run time
وعشان تكون الصورة واضحة خل نقسمة الى اربع مراحل, وكانت المراحل بالطريقة هذي
بديت بتحليل الابلكيشن ولقيت احد
ال native library
باسم "libintegrity(dot)so"
والواضح ان ال Detection stack كان من خلاله وفعلا بعد تحليل
ال libintegrity native library
اتضح لي انه تمر على أربع مراحل وكلها تكون بال Run time
وعشان تكون الصورة واضحة خل نقسمة الى اربع مراحل, وكانت المراحل بالطريقة هذي
```
Phase 1 Static Environment Scan (Java thread) → Trust level: JVM
Phase 2 Native Runtime Scan (native thread) → Trust level: kernel
Phase 3 Anti-Instrumentation (watchdog thread) → Trust level: kernel + self
Phase 4 Hardware Binding Attestation (API call) → Trust level: server + TEE
```نبدا بالحماية الأولى وكانت عبارة
عن Static Environment Scan والي كانت بسيطة
```
Filesystem: /su /system/xbin/su /sbin/su /system/app/SuperSU.apk
Packages: com.topjohnwu.magisk eu.chainfire.supersu
Build props: ro.build.tags=test-keys ro.debuggable=1 ro.secure=0
Mount table: /proc/mounts → rw entries on /system or /vendor
```ومثل مانلاحظ ال detection هنا جدا تافهة بسبب انه static checks
وهذي امره بسيط ممكن نقدر نتخطاه بأكثر من طريقة
لكن Shamiko via Zygisk لحاله تهندلنا اياه
صحيح ان المرحلة الاولى بسيطة لكن تخطيه لحالة غير كافي بسبب انه لأن المرحلة الثانية تشتغل على native thread مستقل بيستخدم direct syscalls للكيرنل مباشرة
يعني حتى لو Shamiko مشت كل الـ Java layer والـ libc
المرحلة الثانية ما تمر من الـ libc ابد مثل ماراح نعرف الحين
وهذي امره بسيط ممكن نقدر نتخطاه بأكثر من طريقة
لكن Shamiko via Zygisk لحاله تهندلنا اياه
صحيح ان المرحلة الاولى بسيطة لكن تخطيه لحالة غير كافي بسبب انه لأن المرحلة الثانية تشتغل على native thread مستقل بيستخدم direct syscalls للكيرنل مباشرة
يعني حتى لو Shamiko مشت كل الـ Java layer والـ libc
المرحلة الثانية ما تمر من الـ libc ابد مثل ماراح نعرف الحين
---
Generated by Thread Navigator
Press ⌘ + S to quick-export