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

(كل شيء كتبه deepseek، وأنا لا أفهم شيئًا) (قضيت بضعة أيام أخرى في المحاولة، والتقدم صفر، فاستسلمت) (حاليًا يمكن الحصول على الروت، لكنه غير مستقر للغاية، بعد الروت ينقطع الاتصال بالشبكة، وسحب الكابل يؤدي إلى إعادة التشغيل) (جميع الاستنتاجات في هذا المستودع تنطبق فقط على هونر WIN RT، وثغرة CVE-2026-43499، ونواة 6.6.118-android15-8-gf17133276a57-abogki518694926-4k، لا تنشر الاستنتاجات إلى الروت المؤقت، فالروت المؤقت يمكن أن يستمر ويعمل بشكل مستقر نسبيًا)

أداة الإقلاع للجهاز مقفلة بشكل دائم (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 في النواة وإعادة تشغيل. هذا ليس bug، بل هو الثمن المتأصل لهذه الطريقة في الاستغلال —— التفاصيل في docs/03.

---

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

البند	القيمة	ملاحظات
الطراز	هونر WIN RT، الطراز AAK-AN00	الاسم التسويقي «هونر WIN RT»
SoC	سنابدراغون 8 إيليت SM8750-AB	البرنامج الثابت غير متوافق مع هونر WIN (AAP-AN00، SM8850-AC)
النظام	Android 16 / MagicOS 10	—
النواة	6.6.118-android15-8-gf17133276a57-abogki518694926-4k	★ شرط صارم، مطابقة حرف بحرف
إعدادات النواة	صفحات 4K، VA_BITS=39، CONFIG_FUTEX_PI=y	شرط أساسي لهندسة الحامل
حزمة البرنامج الثابت	.170	.160 / .175 لم تُختبر
أداة الإقلاع	مقفلة بشكل دائم	لا fastboot / لا su دائم

لماذا يجب تثبيت إصدار النواة بدقة: العيب أُصلح في 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 → تجمد الدورة بأكملها. الحل الصحيح هو إنشاء عملية «الكاتب المُعدّ مسبقًا» قبل الضربة الأولى (ببيانات اعتماد نظيفة)، الأب ينفذ الضربة الأولى والكاتب ينفذ الثانية، فلا يُجري أي منهما استدعاء نظام أثناء الحالة العابرة.
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. الفهرس