aniketlab/poco-m7-plus-jailbreakأبحاث الجذر المؤقت على Poco M7 Plus (SM6375) عبر استغلال Qualcomm GBL (CVE-2026-24088) + تحليل نواة GhostLock (CVE-2026-43499)
إخلاء المسؤولية: هذا المستند مكتوب purely لأغراض تعليمية وبحثية أمنية. تم إجراء جميع الاختبارات على جهازي الخاص. لست مسؤولاً عن الأجهزة المعطوبة، أو فقدان البيانات، أو إساءة استخدام هذه المعلومات. الثغرات التي تمت مناقشتها هنا تم الكشف عنها علنًا وترقيعها بالفعل. لا تحاول القيام بذلك على أجهزة لا تملكها.
| الملف | الوصف |
|---|---|
| GBL-AutoRoot.bat | أداة أتمتة الاستغلال بنقرة واحدة (Windows) |
كيفية الاستخدام:
GBL-AutoRoot.bat من الرابط أعلاهمتوافق مع أي جهاز Qualcomm ABL متأثر بـ CVE-2026-24088. إذا أعاد جهازك
OKAY، فسيتم منح صلاحيات الجذر تلقائيًا.
تستهدف هذه الأداة ثغرة Qualcomm ABL (CVE-2026-24088). إذا كان جهازك يحتوي على SoC عرضة للثغرة ولم يتلقَّ البرنامج الثابت المرقّع بعد، فستعمل هذه الأداة.
| الحالة | الجهاز / عائلة SoC | أمثلة على الأجهزة |
|---|---|---|
| 🟢 مؤكد | Snapdragon 695 (SM6375) | POCO M7 Plus 5G, Redmi 15 5G |
| 🟡 محتمل | Snapdragon 8 Gen 3 (SM8650) | Xiaomi 14 / Pro / Ultra, Redmi K70 Pro |
| 🟡 محتمل | Snapdragon 8 Gen 2 (SM8550) | Xiaomi 13 / Pro, POCO F5 Pro, Redmi K60 Pro |
| 🟡 محتمل | Snapdragon 8+ Gen 1 (SM8475) | Xiaomi 12T Pro, POCO F5 |
| 🟡 محتمل | Snapdragon 888 (SM8350) | Mi 11, Mi 11X Pro, POCO F3 |
| 🟡 محتمل | Snapdragon 7+ Gen 3 (SM7675) | POCO F6 |
| 🟡 محتمل | Snapdragon 7 Gen 3 (SM7550) | Xiaomi Civi 4 |
| 🟡 محتمل | Snapdragon 695 5G (SM6375) | POCO X4 Pro 5G, Redmi Note 11 Pro 5G |
| 🟡 محتمل | Snapdragon 680 (SM6225) | Redmi Note 11, Redmi 10C |
| 🟡 محتمل | Snapdragon 662 (SM6115) | POCO M3, Redmi 9T |
| 🔴 لا يوجد دعم | MediaTek (MTK) | POCO X6 Neo, Redmi Note 13 Pro+ |
| 🔴 لا يوجد دعم | برنامج ثابت مرقّع | HyperOS 3.0.304.0+ (تم تطبيق تصحيح الأمان) |
📝 مطلوب اختبار من المجتمع: لا تتوفر لدي جميع هذه الأجهزة للاختبار. إذا كان لديك أحد الأجهزة "المدعومة المحتملة"، فيرجى اختبار الأداة وإخباري بالنتائج. سيساعدني هذا في تأكيد وإضافة جهازك رسميًا إلى قائمة "المؤكدة العاملة"!
| الحقل | القيمة |
|---|---|
| الجهاز | Poco M7 Plus 5G (الاسم الرمزي: spring) |
| الشريحة | Qualcomm SM6375 (Snapdragon 6s Gen 3) |
| المعمارية | AArch64، KASLR مفعّل |
| SELinux | Enforcing (قبل الاستغلال) |
| Bootloader | LOCKED |
| منصة الاختبار | Windows 11، ADB Platform Tools |
| إصدار HyperOS | إصدار النواة | نتيجة GhostLock | نتيجة استغلال GBL |
|---|---|---|---|
| 2.0.202.0 | 6.1.118-android14-11-ga3b9c44908dd-ab13320413 | ❌ Kernel Panic | ✅ يعمل |
| 2.0.208.0 | 6.1.138-android14-11-g51f8c580613d-ab13911623 | ❌ Kernel Panic | ✅ يعمل |
ملاحظة بحثية: اختبرت في البداية على HyperOS 2.0.202.0 حيث تسبب GhostLock في Kernel Panic. ثم قمت بالتحديث إلى 2.0.208.0 للتحقق مما إذا كانت بنية النواة الأحدث (6.1.118 -> 6.1.138) ستحل عدم استقرار GhostLock. استمر الـ panic - كلا البنيتين تشتركان في نفس التخطيط الداخلي
pselect/fd_setالخاص بـ 6.1 الذي لا يستطيع GhostLock التعامل معه. عمل استغلال GBL على كلا الإصدارين.
خلال هذا البحث، اختبرت مسارين مستقلين للاستغلال لتحقيق جذر مؤقت على هذا الجهاز دون فتح الـ bootloader:
| النهج أ: استغلال GBL | النهج ب: GhostLock | |
|---|---|---|
| الطبقة | Bootloader (ABL/fastboot) | النواة (Linux 6.1) |
| CVE | CVE-2026-24088 | CVE-2026-43499 |
| النتيجة على هذا الجهاز | ✅ يعمل | ❌ Kernel Panic |
| نوع الجذر | مؤقت (مربوط) | مؤقت (مربوط) |
| يتطلب ADB؟ | نعم (وضع fastboot) | نعم (وصول shell) |
| حساس لإصدار النواة؟ | لا | نعم - مستقر فقط على 6.6-6.12 |
عمل استغلال GBL. فشل GhostLock مع Kernel Panic بسبب عدم تطابق إصدار النواة. تم توثيق كلا النتيجتين بالتفصيل أدناه.
تؤثر CVE-2026-24088 على Android Boot Loader (ABL) من Qualcomm عبر أجهزة متعددة.``` Jan 2026 -> Vulnerability discovered during ABL unpacking & analysis Feb 2026 -> Qualcomm patches: QcomModulePkg: Fix propagation of untrusted input into kernel cmdline Mar 2026 -> Public PoC released; Xiaomi begins rolling out HyperOS 3.0.304.0 (patched) Jun 2026 -> CVE-2026-24088 officially assigned in Qualcomm Security Bulletin
### شرح سلسلة الاستغلال
يعمل الاستغلال كـ **سلسلة من ثلاث مراحل** على مستوى محمّل الإقلاع:
#### المرحلة 1 - تنفيذ GBL غير الموقّع
في Android 16، يقوم ABL الخاص بـ Qualcomm بتحميل Generic Bootloader (GBL) من قسم `efisp`. الخلل الجوهري: **يتحقق ABL فقط مما إذا كان الملف الثنائي تطبيق UEFI صالحًا - ولا يتحقق من توقيعه التشفيري.** وهذا يعني أنه يمكن وضع تطبيق UEFI مخصص وغير موقّع في `efisp` وسيُنفَّذ في مرحلة محمّل الإقلاع بكامل الصلاحيات.
#### المرحلة 2 - حقن سطر أوامر النواة
يفتقر الأمر `fastboot oem set-gpu-preemption` إلى **تعقيم المدخلات**. يقوم ABL بدمج الوسيط المُقدَّم مباشرةً في سطر أوامر النواة دون تصفية.
من خلال تمرير `androidboot.selinux=permissive` كوسيط إضافي:```
fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive
...يكتب محمّل الإقلاع androidboot.selinux=permissive في سطر أوامر النواة (kernel cmdline)، وهي القيمة التي تقرأها عملية init في Android عند الإقلاع - مما يعطّل فعليًا تطبيق SELinux.
يمكن لتطبيق UEFI مخصص موضوع في efisp تعيين علمَي is_unlocked وis_unlocked_critical لفتح قفل محمّل الإقلاع بشكل دائم. (لم تُختبر هذه الخطوة - تحمل خطر تعطّل الجهاز بشكل دائم (hard brick).)
⚠️ توقف قبل المتابعة: شغّل فحص الترقيع (patch check) في القسم 7 أولًا. إذا كان جهازك مُرقّعًا، فلن يعمل أي من هذا.
المتطلبات الأساسية:
هل أحتاج إلى تمكين فتح قفل OEM في خيارات المطوّر؟ لا - وهذه واحدة من أهم جوانب هذه الثغرة. يعمل الأمر
fastboot oem set-gpu-preemptionعلى مستوى ABL - ويُعالَج قبل أن يتحقق نظام التشغيل من حالة فتح قفل OEM. الثغرة CVE-2026-24088 هي خلل في تعقيم المدخلات (input sanitization) داخل ABL نفسه، مما يتجاوز بوابة فتح قفل OEM بالكامل. يبقى محمّل الإقلاع الخاص بك مقفلًا طوال العملية. إذا رأيت دليلًا يقول "مكّن فتح قفل OEM أولًا" - فهذا ينطبق على طريقة فتح قفل مختلفة (قياسية)، وليس على هذه الثغرة.
الخطوة 1: الدخول إلى وضع Fastboot```bash adb reboot bootloader
**الخطوة 2: اختبار الثغرة**```bash
fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive
OKAY -> الجهاز معرّض للخطر ✅ تابعFAILED (remote: 'Set GPU HW Preemption: Invalid Argument') -> الجهاز مُرقّع ❌ توقف هنا