thiasap/oppo-pgem10-ghostlockOPPO Find X6 Pro GhostLock (CVE-2026-43499) تكييف الاستغلال
هذا المشروع يبحث في تكييف ثغرة CVE-2026-43499 (GhostLock) على جهاز OPPO Find X6 Pro (PGEM10).
بناءً على هيكل الاستغلال الأصلي NebuSec CyberMeowfia، مع الاستعانة بنهج التكييف من oppo-ghostlock.
| العنصر | القيمة |
|---|---|
| الجهاز | OPPO Find X6 Pro (PGEM10) |
| الشريحة | Snapdragon 8 Gen 2 (SM8550) |
| النواة | Linux 5.15.149-android13 #1 SMP PREEMPT |
| تاريخ التجميع | الخميس 13 فبراير 2025 |
| أندرويد | 15 (ColorOS 15.0) |
| إصدار ROM | PGEM10_15.0.0.600(CN01) |
| PAC | CONFIG_ARM64_PTR_AUTH_KERNEL=y |
| BTI | CONFIG_ARM64_BTI_KERNEL=y |
| KASLR | CONFIG_RANDOMIZE_BASE=y |
| VA_BITS | 39 |
| إزاحة VA | P0_PAGE_OFFSET = 0xffffff8000000000 |
| الوحدة | الحالة | الشرح |
|---|---|---|
| تجاوز KASLR عبر Perf | ✅ | اختراق رئيسي — عبر perf_event_open + أخذ عينات callchain، الحصول على شريحة KASLR الحالية في <1 ثانية |
| تصحيح MM_STRUCT_SZ | ✅ | تم التصحيح من 0x500 إلى 0x400 (1024B)، نجح KernelSnitch فورًا |
| التحقق الكامل من إزاحات IDA | ✅ | جميع الرموز/الهياكل/الدوال الرئيسية تم التحقق منها عبر IDA |
| FUTEX_CMP_REQUEUE_PI | ✅ | تم تشغيل GhostLock UAF بنجاح |
| التحقق من ashmem | ✅ | C ashmem متاح، مسار الخلط النوعي ممكن نظريًا |
| تحليل سلسلة الاستدعاءات | ✅ | تأكيد عدم وجود سلسلة استدعاءات بعمق ≥ 0x800 في النواة |
| مسح تكوين النواة | ✅ | تقييم كامل لسطح الهجوم |
| الوحدة | الحالة | السبب الجذري |
|---|---|---|
| تغطية مكدس SLIDE | ❌ | PAC يسبب تضخم إطار مكدس سلسلة futex إلى 0xA70، بينما pselect فقط 0x620 |
| تغطية fops | ❌ | يتطلب SLIDE، PAC يمنع |
| الخلط النوعي | ❌ | يعتمد على تغطية fops |
| Pipe physrw | ❌ | يعتمد على الخلط النوعي |
| الوصول الجذري (Root) | ❌ | يعتمد على السلسلة أعلاه |
oppo-pgem10-ghostlock/
├── README.md # هذا الملف
├── 问题描述.md # تحليل تفصيلي للمشكلة
├── docs/
│ ├── architecture.md # التصميم المعماري وسلسلة الاستدعاءات
│ └── adaptation-guide.md # دليل تكييف نواة PAC
├── reports/
│ ├── offsets.md # تقرير التحقق من إزاحات IDA
│ ├── kaslr.md # تقرير تحليل KASLR
│ └── summary.md # الخلاصة النهائية
├── src/
│ ├── kaslr_perf.h # وحدة Perf KASLR قابلة لإعادة الاستخدام
│ └── kaslr_perf.c # تنفيذ Perf KASLR
└── analysis/
└── chains/ # نصوص تحليل سلسلة الاستدعاءات
CONFIG_ARM64_PTR_AUTH_KERNEL=y # ← الفرق الجوهري: PAC يسبب تضخم الإطار مباشرة
CONFIG_ARM64_BTI_KERNEL=y # BTI يزيد العبء أكثر
CONFIG_SHADOW_CALL_STACK=y # SCS يزيد إطارات المكدس
CONFIG_VMAP_STACK=y # إعادة رسم خريطة المكدس ممكنة
CONFIG_KASAN_HW_TAGS=y # مفعل عند التجميع
CONFIG_ARM64_VA_BITS=39 # 39 بت VA (وليس 48 بت)
الدالة Pixel 10 (بدون PAC) PGEM10 (مع PAC)
__arm64_sys_futex 0x90 0x4C0
do_futex 0x70 0x420
futex_wait_requeue_pi 0x1A0 0x1B0
─────────────────────────────────────────────────
العمق الإجمالي لسلسلة futex 0x300 0xA70 ← 3.5 أضعاف
عمق مكدس pselect 0x620 0x620
إمكانية التغطية؟ ✅ نعم ❌ لا (0xA70 > 0x620)
تحليل سلسلة الاستدعاءات يؤكد: 0 سلسلة استدعاءات في النواة بعمق ≥ 0x800 (2048 بايت). أقصى إطار مفرد: 0x1F0 (496 بايت).