Thread Truncated (Cap Enforced)
Only the first 20 tweets are unrolled into slides to ensure reliable PDF exporting and high server performance.
Canvas & Ratio
Choose your destination platform format
Layout Template
Choose a content structure for your slides
Preset Themes
Typography & Sizing
Brand Kit Customization
AGENCYConfigure brand assets for headers & footers
Outro Slide CTA
Customize your closing call-to-action slide
Background Pattern
Build Your Carousel
Drag and drop any post card below onto a slide, or use the quick buttons to insert content/images instantly!
كيف قدرت اخترق تطبيق جوال +35 مليون مستخدم من خلال رسالة وحدة؟
مساكم الله بالخير جميعا
اليوم بتكلم عن احد تطبيقات الجوال وسلسلة ثغرات قدرت استغلهم مع بعض لتحقيق اثر عالي وقدرة على اختراق اكثر من 35 مليون حساب والأخطر بدون اي تفاعل من المستخدم
خلال المقالة بتطرق لعدة اشياء بداية من تخطي حماية الابلكيشن على مستوى الـ App Protection ومن ثم الثغرات على مستوى الـ Network
اذا تبغى تسكب شرح تخطي الحماية وتدخل بالثغرات بشكل مباشر يمديك تبدا من قسم Deep Link Execution
فنسمي بالله ونبدا
---
فالبداية خل نعرف كيف بنية الابلكيشن كان عبارة عن split APK architecture
<pre><code>```java base.apk ← core application split_component_lingdong.apk ← stupid crypto stuff split_config.arm64_v8a.apk ← native libraries split_resource.apk ← resources ```</code></pre>
الجزء اللي كان يهمني أكثر هنا هو الـ Native Libraries لأن التطبيق كان يستخدم عدة طبقات حماية مثل SSL Pinning & Root Detection
---
## #2 تخطي حماية التطبيق (SSL Pinning & Root detection)
بعد مافهمنا بنية التطبيق الحين جاء وقته نبدا بالفحص التطبيق بال runtime كان فيه <b>(ssl pinning & root detection) </b>وبطبيعة الحال قبل لاتدخل بقروشة ال 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 وعشان تكون الصورة واضحة خل نقسمة الى اربع مراحل, وكانت المراحل بالطريقة هذي
<pre><code>``` 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 ```</code></pre>
نبدا بالحماية الأولى وكانت عبارة عن Static Environment Scan والي كانت بسيطة
<pre><code>``` 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 ```</code></pre>
ومثل مانلاحظ ال detection هنا جدا تافهة بسبب انه static checks وهذي امره بسيط ممكن نقدر نتخطاه بأكثر من طريقة لكن Shamiko via Zygisk لحاله تهندلنا اياه صحيح ان المرحلة الاولى بسيطة لكن تخطيه لحالة غير كافي بسبب انه لأن المرحلة الثانية تشتغل على native thread مستقل بيستخدم direct syscalls للكيرنل مباشرة يعني حتى لو Shamiko مشت كل الـ Java layer والـ libc المرحلة الثانية ما تمر من الـ libc ابد مثل ماراح نعرف الحين
---