مشروع بمساعدة الذكاء الاصطناعي. تم إنتاج هذا البحث وتطوير الاستغلال والتوثيق بمساعدة الذكاء الاصطناعي باستخدام النموذجين GLM-5.3 و DeepSeek V4.1 Flash.

amazon-mustang-hack

بحث استغلال الجذر (root exploit) لجهاز Amazon Fire 7 الجيل التاسع (mustang, MT8163, Mali-T720) على البرنامج الثابت النهائي — Fire OS 7.3.3.1, PS7331.4463N, kernel 4.9.117 (built 2025-05-03, SPL 2024-08-01).

الهدف: LineageOS. مسار الـ bootloader ميت على هذه الوحدة (bootrom مُرقّع — preloader فقط عبر CMD short)، لذا المسار الوحيد المتبقي هو استغلال برمجي للنواة (kernel exploit).

بداية سريعة```

one-shot: build, run the exploit (retries across the probabilistic reclaim),

install a setuid-root su and verify it as an unprivileged user

nix-shell -p android-tools --run './run.sh' # add -p zig too if no zig

عند النجاح:```
/data/metrics/su id     # run a command as root
/data/metrics/su        # interactive root shell

يفوز reclaim بنحو إقلاع واحد من كل 3، والخسارة تؤدي إلى panic/إعادة تشغيل الجهاز اللوحي؛ run.sh ينتظر فقط إعادة التشغيل ويعيد المحاولة. يتم فرض SELinux إلى Permissive كجزء من الاستغلال، لذا فإن root يعمل وقت التشغيل فقط — إعادة التشغيل تستعيد الوضع الأصلي وتعيد تشغيل run.sh.

يتم تضمين st3 و su المبنيين مسبقًا (armv7 static)، لذا لا حاجة إلى toolchain للتشغيل. ./run.sh --build يعيد بناءهما من poc/*.c إذا كان لديك zig.

كل ما هو أدناه مجرد سجل للعمل الذي قام به النموذج، لا يوجد إدخال بشري أدناه.

الهدف الأساسي (منذ الجلسة 5): kbase CVE-2022-38181 — المرحلة 2 مُثبتة

GhostLock (أدناه) متوقف مؤقتًا: متغير rtmutex BUG_ON الخاص بـ MTK + عدم الكشف عن عنوان kernel من shell = طريق مسدود معماري على هذا البناء (الجلسات 2-4). تمت إعادة تشخيص kbase JIT UAF (كان "panic غير المشروط" في destroy-worker هو JIT_FREE deref، وفُقد السجل بسبب موت adbd في منتصف الـ panic) والمرحلة 2 الآن مُثبتة بالأوراكل — انظر قسم الجلسة 5.

متوقف مؤقتًا: GhostLock، CVE-2026-43499

rtmutex remove_waiter() futex-PI stack-UAF (إفصاح NebuSec 2026-07، الإصلاح 3bfdc63936dd وصل 2026-04). النطاق المعرّض 2.6.39–7.1 → إصدارنا 4.9.117 (مايو 2025) متأثر.

تم التحقق على بنائنا الدقيق:

• CONFIG_FUTEX=y، rtmutex مُجمّع، الخلل موجود حرفيًا: rtmutex.c:1108-1111 يستخدم current->pi_lock/current->pi_blocked_on (يجب أن يكون waiter->task)؛ موقع الاستدعاء المعطوب rtmutex.c:1723 (مسار خطأ rt_mutex_start_proxy_lock)
• سطح التشغيل = استدعاءات futex خالصة (WAIT_REQUEUE_PI/CMP_REQUEUE_PI)، لا device node، لا شيء محمي بـ SELinux — العوائق القاتلة في مسار kbase غير موجودة هنا
• المستهلك: sched_setattr → __sched_setscheduler → rt_mutex_adjust_pi(p) عند sched/core.c:4706 — يعمل deref لـ pi_blocked_on القديم ✓
• proxy waiter يعيش على stack خيط waiter نفسه (futex.c:1975 يمرر this->rt_waiter، المُعرّف في futex_wait_requeue_pi عند futex.c:2880) → waiter يطبع إطاره المحرر عبر arm32 select (nr 142) fd_sets
• مناخ الاستغلال: لا KASLR (قاعدة ثابتة 0xc0008000)، لا PAN، DEBUG_RT_MUTEXES معطّل → rt_mutex_waiter مضغوط بحجم 48 بايت (tree_entry@0، pi_tree_entry@0xc، task@0x18، lock@0x1c، prio@0x20، deadline@0x28)
• سلسلة مختصرة: 2 write-slots → modprobe_path @ 0xc111488c (السلسلة موجودة ذاتيًا في vmlinux؛ KALLSYMS_ALL معطّل لذا رموز البيانات تحتاج هذه الحيلة) → exec binfmt غير معروف → root script (setenforce 0، تعطيل OTA، su)
• المراجع في refs/: NebuSec/CyberMeowfia (الأصلي)، GhostLock-5.10 (منفذ Fire OS 8، trigger كامل لـ 32-bit ARM في src/exp32/)، ghostlock-...-4.19-k40 (منفذ Qualcomm 4.19 Android)

TODO (خطة المنفذ)

1. كتابة trigger (3-thread requeue-PI deadlock، الأنوية 0-3) — منفذ من exp32/main.c
2. هندسة الطبع: إزاحة إطار rt_waiter مقابل منطقة do_sys_select fd_set — فك تجميع vmlinux الخاص بنا (do_sys_select stack_fds مقابل إطار futex_wait_requeue_pi)، كشف STAMP_NFDS/STAMP_WAITER_OFF كمعاملات قابلة للضبط
3. ترميز fake-writer لـ arm32 48-byte waiter → فتحات "write V to ADDR"
4. 2 slots → modprobe_path، تشغيل، root script
5. بدائل إذا لم يصل select-stamp: setsockopt(MCAST_JOIN_SOURCE_GROUP) stamp

الحالة

• Bootrom (طريقة amonet العتادية) — مُرقّع على هذه الوحدة، طريق مسدود
• mtk-su (CVE-2020-0069) — مُرقّع، Failed critical init step 3
• مسح سطح الهجوم — /dev/mali0 world-RW + SELinux gpu_device، kbase r26p0-01rel0
• CVE-2022-38181 مؤكد في مصدر البناء الدقيق؛ trigger المرحلة 1 يعمل
• CVE-2026-43499 (GhostLock) تم التحقق منه لكنه محظور: متغير rtmutex BUG_ON الخاص بـ MTK + عدم الكشف عن عنوان kernel من shell (الجلسات 2-4)
• CVE-2022-38181 المرحلة 2 مُثبتة (الجلسة 5): panic في destroy-worker كان تشخيصًا خاطئًا؛ إعادة توجيه UAF إلى المنطقة المرشوشة، مُتحقق بالأوراكل
• المرحلة 1: trigger + stamp + consumer (crash = السلسلة حية)
• المرحلة 2 (مسار kbase): إعادة توجيه UAF إلى المنطقة المرشوشة — مُثبتة الجلسة 5
• المرحلة 2b: تحكم raw-byte slot (تقلب xattr stamp) → unlink write
• المرحلة 3: استدعاء دالة kernel عشوائية → ROOT (الجلسة 10) — اختطاف nf LOCAL_OUT hook، سلسلة selroot المكونة من حزمتين: تصفير selinux_state.enforcing، إعادة كتابة fake entry إلى commit_creds(&init_cred). uid=0، SELinux Permissive.
• [_] المرحلة 4: root script (su، permissive، OTA off) + الاستمرارية — تم الحصول على root؛ الاستمرارية محظورة (انظر الجلسة 11): LK يقيّد verity-off/SELinux-permissive على eng/unlocked، إعادة الاستغلال عند الإقلاع ليس لديها منفذ قابل للتطبيق. التالي: عكس LK/amzn_verify_unlock.
• المرحلة 5: سلسلة إقلاع نظام تشغيل مخصص

النتائج الرئيسية

الجهاز / البرنامج الثابت

• الطراز KFMUWI، الجهاز mustang، Fire OS 7.3.3.1 PS7331.4463N/0031575863040
• Kernel 4.9.117-g08fe75b-dirty، بُني السبت 3 مايو 01:25:15 UTC 2025 (Linaro GCC 6.3-2017.05)
• أعادت Amazon بصمت إصدار 7.3.3.1 في مايو 2025 (incremental جديد، نفس سلسلة الإصدار)
• مراجعة Bootrom بعد 2020: قصر إلى GND على eMMC CMD يعطي preloader فقط (مُرقّع)
• /dev/kb، /dev/dkb (أقسام النسخ الاحتياطي لنواة Amazon) root:drmrpc 0660 — مقفلة

لماذا ينطبق CVE-2022-38181

• Driver: mali_kbase r26p0-01rel0 (Midgard، Mali-T720)، داخل نطاق NVD المتأثر r4p0–r31p0
• إعادة بناء Amazon في مايو 2025 شحنت خلل 2018 حرفيًا — لا backport
• الكود المعرّض الدقيق، مُتحقق من المصدر:
  • mali_kbase_mem.c:2721 kbase_jit_destroy_worker يحرر المنطقة، لا يمسح kctx->jit_alloc[id] أبدًا
  • mali_kbase_softjobs.c:1270 kbase_jit_free_finish يعمل deref لـ jit_alloc[ids[j]] القديم
  • mali_kbase_mem.c:3138 kbase_jit_backing_lost → مسار destroy (يُفعّل أثناء reclaim)

مناخ الاستغلال (كل شيء مُتحقق من config dump الحي + OTA vmlinux)

• armv7 32-bit، غير LPAE → لا KASLR (kernel عند 0xc0008000 VA ثابت / 0x40080000 PA)
• لا ARM_SW_DOMAIN_PAN → ret2usr قابل للتطبيق؛ CONFIG_PANIC_ON_OOPS=y (المحاولات الفاشلة = إعادة تشغيل)
• لا SLAB_FREELIST_RANDOM/HARDENED، لا CONFIG_USER_NS/USERFAULTFD/NF_TABLES
• CONFIG_MODULES=y، لا STATIC_USERMODEHELPER → الكتابة فوق modprobe_path = root
• 1 GB RAM → direct reclaim (المطلوب للإخلاء) يمكن الوصول إليه بسهولة؛ الضغط >~1 GB يؤدي إلى panic في kernel من تلقاء نفسه (خلل lowmem/OOM غير ذي صلة) — أبقِ spray ≤ 900 MB، استخدم ~700 MB

غرائب UAPI التي واجهناها أثناء تطوير PoC (r26p0، _IOC_TYPE 0x80)

• اتحاد MEM_ALLOC بحجم 32 بايت (in يحتوي على 4 × u64 بما في ذلك extent)
• يجب أن تتضمن flags BASE_MEM_PROT_GPU_RD|WR (بتات 2|3)، وليس R|W القديمة
• mmap لصفحة التتبع مطلوب قبل أي alloc: mmap(fd, offset=3<<12, PROT_NONE)
• يجب أن تساوي stride في JOB_SUBMIT قيمة sizeof(base_jd_atom_v2) = 48 (base_jd_prio/base_jd_dep_type هي typedefs من نوع u8)
• JIT: MEM_JIT_INIT (nr 14، بنية v2)، alloc/free هي soft jobs عبر JOB_SUBMIT (BASE_JD_REQ_SOFT_JIT_ALLOC=0x209، ...FREE=0x20a؛ jc=مؤشر مستخدم، nr_extres=العدد)
• نتيجة JIT alloc يكتبها kernel عبر info->gpu_alloc_addr (GPU VA يجب أن تخصصه مسبقًا وتمرره)