CVE-2026-43499 · Honor WIN RT (AAK-AN00) ملاحظات بحثية عن الروت المؤقت

(كله مكتوب بواسطة deepseek، أنا لا أفهم شيئًا)

أداة Bootloader الجهاز مقفلة بشكل دائم (ro.oem_unlock.supported فارغ)، لا يوجد fastboot، لا يوجد su دائم، لا يوجد Magisk. المسار الوحيد المتبقي هو ثغرة النواة. هذا المستودع يوثق العملية الكاملة من "هل يمكن تنفيذها" إلى "ما مدى استقرارها بعد التنفيذ".

الطبيعة: روت مؤقت، يزول عند إعادة التشغيل.

إخلاء المسؤولية

هذا المستودع يوثق عملية بحث أمني أُجريت على جهازي الشخصي، بهدف فهم أسباب سباق PI في النواة وحدود استقراره.

• لا يحتوي على أي ملفات exploit ثنائية أو حمولات استغلال قابلة للتشغيل المباشر —— الحمولات والأطر تأتي من مشاريع مفتوحة المصدر في المنبع، وهذا المستودع يستشهد بها فقط ولا يعيد نشرها.
• لا يقدم دروسًا لأي وسيلة تجاوز خاصة بأي شركة مصنعة، ولا يشجع على الاستخدام على أجهزة غير مصرح بها.
• الإزاحات وعناوين الرموز داخل المستودع صالحة فقط لبناء النواة الواحد المذكور في هذه الوثيقة، وتصبح كلها لاغية عند تغيير النواة.
• العيوب ذات الصلة تم إصلاحها في upstream (انظر أدناه). القيمة طويلة المدى لهذه الوثيقة تكمن في "هذا السجل نفسه" —— مراجعة واقعية لثغرة سباق في ظروف غير مثالية، بما في ذلك كل آثارها الجانبية المزعجة.

0. الخلاصة في جملة واحدة

المسار الوحيد الذي نجح هو:

CVE-2026-43499 (سباق futex PI write-what-where) + ناقل rt_sigreturn
  → حقن LD_PRELOAD في عملية نطاق shell
  → على مرحلتين: أولاً ضرب SELinux Permissive، ثم تغيير task->real_cred / cred إلى init_cred
  → uid=0(root) context=u:r:kernel:s0، وزرع عملية su خفية

لكن ما يستحق التدوين حقًا ليس "كيف حصلنا على root" —— بل ما حدث بعد الحصول عليه.

ما حصلنا عليه ليس root مستقرًا، بل "حالة قابلة للانفجار في أي لحظة".

الكتابة البدائية في exploit تُدخل rt_mutex_waiter مزيفًا في سلسلة futex PI الحقيقية، وحامل هذا waiter هو مكدس النواة / صفحات الرش التي ستُعاد استخدامها بواسطة استدعاءات نظام لاحقة. لذا من لحظة استقرار root، أي جدولة على مستوى النظام أو تغيير في الأولوية قد يدوس عليه، مما يؤدي مباشرة إلى panic في النواة وإعادة تشغيل. هذا ليس خطأً برمجيًا، بل هو الثمن المتأصل لهذه الطريقة في الاستغلال —— التفاصيل في docs/03.

1. حدود التطبيق (إذا لم تنطبق يصبح الحل كله لاغيًا)

لماذا يجب تثبيت إصدار النواة بدقة: العيب تم إصلاحه في 6.6.140، وجهازنا 6.6.118 < 6.6.140 لذا لا يزال موجودًا؛ كما أن جميع عناوين رموز النواة و"هندسة الناقل" في exploit مثبتة على هذا البناء الواحد، وبعد تغيير النواة يصبح جدول الإزاحات لاغيًا فورًا، وعادةً لا يمكن التراجع.

2. نظرة شاملة على مسار رفع الصلاحيات

┌─ المواد ────────────────────────────────────────────────┐
│ boot.img + xbl_config.elf (مستخرجة من برامج الجهاز الثابتة)            │
│        ↓ تحليل الرموز                                       │
│ target.h (عناوين رموز النواة، تم التحقق منها بايت ببايت مع kallsyms)      │
│        ↓ البناء                                           │
│ preload.so ──► على الجهاز /data/local/tmp/*.so             │
└────────────────────────────────────────────────────────┘
                 ↓  حقن LD_PRELOAD
     ┌──────────── على مرحلتين (يجب عمليتان مستقلتان)────────────┐
     │ المرحلة A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ المرحلة B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred (تُنفذ بواسطة عملية "الكاتب المُعدّ مسبقًا")│
     │         → setresuid(0,0,0) تطبيع                           │
     │         → زرع su مدمج + daemon                              │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

ثلاثة أمور يجب إتقانها (الخطأ فيها يؤدي إلى الجمود أو panic مباشرة):

1. قاعدة الترتيب الصارمة: أولاً real_cred، ثم cred. العكس يؤدي إلى صلاحيات كاملة فورية وفقدان السيطرة على الخيوط.
2. بين الضربتين توجد حتمًا حالة عابرة cred ≠ real_cred. في هذه اللحظة أي sched_setaffinity سيعطي EPERM → جمود كامل للدورة. الحل الصحيح هو fork لعملية "الكاتب المُعدّ مسبقًا" قبل الضربة الأولى (بيانات اعتماد نظيفة)، العملية الأب تنفذ الضربة الأولى، والكاتب ينفذ الثانية، ولا أحد منهما يستدعي syscall أثناء الحالة العابرة.
3. نموذج العناوين مستقل عن KASLR. الاستغلال كله يسير فقط عبر اسم بديل للتعيين الخطي alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ)، مستقر عبر إعادات التشغيل؛ القيمة الحقيقية لما يسمى "مرحلة slide" هي التحقق الذاتي من الكتابة البدائية، وليس تجاوز KASLR.

الإطار في المنبع: Linuxoid-cn/CVE-2026-43499-Poc-Analysis. ملاحظة: هذا ليس GhostLock —— GhostLock يسير عبر مسار pselect، وهندسة نقطة سقوط waiter لا تتوافق مع هذا البناء، التفاصيل في docs/06.

3. الفهرس

4. الجدول الزمني

5. جملة واحدة للقادمين

إذا كنت أيضًا تعمل على طراز مقفل الـ BL، فكّر أولاً بوضوح فيما تريد فعله بـ root، لأن root على هذه الطرازات غالبًا ما يكون نافذة لا تدوم سوى بضع دقائق. ضع قائمة بالعمليات التي "تحتاج root ويمكن أن تبقى عبر إعادة التشغيل"، ونفّذها دفعة واحدة، ثم reboot للعودة إلى الحالة النظيفة. لا تحاول "إزالة الآثار الجانبية" —— فهذا هو ثمن الطريقة نفسها.