Projet assisté par IA. Cette recherche, le développement de l'exploit et la documentation ont été produits avec l'assistance de l'IA en utilisant les modèles GLM-5.3 et DeepSeek V4.1 Flash.

amazon-mustang-hack

Recherche d'exploit root pour l'Amazon Fire 7 9e gén (mustang, MT8163, Mali-T720) sur le firmware final — Fire OS 7.3.3.1, PS7331.4463N, kernel 4.9.117 (compilé le 2025-05-03, SPL 2024-08-01).

Objectif : LineageOS. La voie du bootloader est morte sur cette unité (bootrom patchée — preloader uniquement via court-circuit CMD), donc la seule route restante est un exploit logiciel du kernel.

Démarrage rapide```

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

En cas de succès :```
/data/metrics/su id     # run a command as root
/data/metrics/su        # interactive root shell

Le reclaim réussit environ 1 démarrage sur 3 et un échec provoque un panic/redémarrage de la tablette ; run.sh attend simplement le redémarrage et réessaie. SELinux est forcé en Permissive dans le cadre de l'exploit, donc root est uniquement à l'exécution — un redémarrage restaure l'état d'origine et vous relancez run.sh.

Les binaires précompilés st3 et su (armv7 statique) sont inclus, donc aucune chaîne d'outils n'est nécessaire pour exécuter. ./run.sh --build les reconstruit à partir de poc/*.c si vous avez zig.

Tout ce qui suit n'est qu'un journal du travail effectué par le modèle, aucune intervention humaine ci-dessous.

CIBLE PRINCIPALE (depuis la session 5) : kbase CVE-2022-38181 — étape 2 PROUVÉE

GhostLock (ci-dessous) est en pause : la variante BUG_ON rtmutex de MTK + aucune divulgation d'adresse kernel depuis le shell = impasse architecturale sur cette build (sessions 2-4). L'UAF JIT de kbase a été re-diagnostiqué (le « panic inconditionnel » du destroy-worker était le déréférencement JIT_FREE, log perdu à cause de la mort d'adbd en plein panic) et l'étape 2 est désormais prouvée par oracle — voir la section SESSION 5.

EN PAUSE : GhostLock, CVE-2026-43499

UAF de pile futex-PI dans remove_waiter() de rtmutex (divulgation NebuSec 2026-07, correctif 3bfdc63936dd intégré 2026-04). Plage vulnérable 2.6.39–7.1 → notre 4.9.117 (mai 2025) est affecté.

Vérifié sur notre build exacte :

• CONFIG_FUTEX=y, rtmutex compilé en dur, bug présent mot pour mot : rtmutex.c:1108-1111 utilise current->pi_lock/current->pi_blocked_on (devrait être waiter->task) ; site d'appel bogué rtmutex.c:1723 (chemin d'erreur de rt_mutex_start_proxy_lock)
• Surface de déclenchement = purs appels système futex (WAIT_REQUEUE_PI/CMP_REQUEUE_PI), aucun nœud de périphérique, rien de contrôlé par SELinux — les obstacles fatals du chemin kbase n'existent pas ici
• Consommateur : sched_setattr → __sched_setscheduler → rt_mutex_adjust_pi(p) à sched/core.c:4706 — déréférence un pi_blocked_on obsolète ✓
• Le waiter proxy réside sur la pile du thread waiter lui-même (futex.c:1975 passe this->rt_waiter, déclaré dans futex_wait_requeue_pi à futex.c:2880) → le waiter marque sa propre frame libérée via les fd_sets de select (nr 142) arm32
• Climat d'exploitation : pas de KASLR (base fixe 0xc0008000), pas de PAN, DEBUG_RT_MUTEXES désactivé → rt_mutex_waiter compact de 48 octets (tree_entry@0, pi_tree_entry@0xc, task@0x18, lock@0x1c, prio@0x20, deadline@0x28)
• Chaîne minimale : 2 slots d'écriture → modprobe_path @ 0xc111488c (chaîne auto-localisée dans vmlinux ; KALLSYMS_ALL désactivé donc les symboles de données nécessitent cette astuce) → exec binfmt inconnu → script root (setenforce 0, désactiver OTA, su)
• Références dans refs/ : NebuSec/CyberMeowfia (original), GhostLock-5.10 (port Fire OS 8, déclencheur ARM 32 bits complet dans src/exp32/), ghostlock-...-4.19-k40 (port Android Qualcomm 4.19)

TODO (plan de portage)

1. Écrire le déclencheur (interblocage requeue-PI à 3 threads, cœurs 0-3) — portage de exp32/main.c
2. Géométrie du marquage : offset de la frame rt_waiter vs zone fd_set de do_sys_select — désassembler notre vmlinux (do_sys_select stack_fds vs frame futex_wait_requeue_pi), exposer STAMP_NFDS/STAMP_WAITER_OFF comme paramètres ajustables
3. Encodage fake-writer pour waiter arm32 de 48 octets → slots « écrire V à ADDR »
4. 2 slots → modprobe_path, déclencher, script root
5. Solutions de repli si le marquage select ne peut pas atteindre : marquage setsockopt(MCAST_JOIN_SOURCE_GROUP)

Statut

• Bootrom (méthode matérielle amonet) — corrigé sur cette unité, impasse
• mtk-su (CVE-2020-0069) — corrigé, Failed critical init step 3
• Étude de la surface d'attaque — /dev/mali0 world-RW + SELinux gpu_device, kbase r26p0-01rel0
• CVE-2022-38181 confirmé dans le source de la build exacte ; le déclencheur de l'étape 1 fonctionne
• CVE-2026-43499 (GhostLock) vérifié mais bloqué : variante BUG_ON rtmutex de MTK + aucune divulgation d'adresse kernel depuis le shell (sessions 2-4)
• CVE-2022-38181 étape 2 PROUVÉE (session 5) : le panic du destroy-worker était un mauvais diagnostic ; redirection UAF sur la région sprayée, vérifiée par oracle
• Étape 1 : déclencheur + marquage + consommateur (crash = chaîne active)
• Étape 2 (chemin kbase) : redirection UAF sur la région sprayée — PROUVÉE session 5
• Étape 2b : contrôle de slot octet brut (rotation de marquage xattr) → écriture unlink
• Étape 3 : appel de fonction kernel arbitraire → ROOT (session 10) — détournement du hook nf LOCAL_OUT, chaîne selroot à 2 paquets : mise à zéro de selinux_state.enforcing, réécriture de l'entrée fake vers commit_creds(&init_cred). uid=0, SELinux Permissive.
• [_] Étape 4 : script root (su, permissive, OTA désactivé) + persistance — root obtenu ; persistance bloquée (voir SESSION 11) : LK conditionne verity-off/SELinux-permissive à eng/unlocked, la ré-exploitation au démarrage n'a pas d'exécuteur viable. Suivant : reverse LK/amzn_verify_unlock.
• Étape 5 : chaîne de démarrage d'OS personnalisée

Constatations clés

Appareil / firmware

• Modèle KFMUWI, appareil mustang, Fire OS 7.3.3.1 PS7331.4463N/0031575863040
• Kernel 4.9.117-g08fe75b-dirty, compilé le sam. 3 mai 01:25:15 UTC 2025 (Linaro GCC 6.3-2017.05)
• Amazon a silencieusement réédité 7.3.3.1 en mai 2025 (nouvel incrémental, même chaîne de version)
• Révision Bootrom post-2020 : court-circuit vers GND sur eMMC CMD donne le préchargeur uniquement (corrigé)
• /dev/kb, /dev/dkb (partitions de sauvegarde kernel Amazon) root:drmrpc 0660 — verrouillés

Pourquoi CVE-2022-38181 s'applique

• Pilote : mali_kbase r26p0-01rel0 (Midgard, Mali-T720), dans la plage affectée NVD r4p0–r31p0
• La reconstruction d'Amazon de mai 2025 a livré le bug de 2018 mot pour mot — aucun backport
• Code vulnérable exact, vérifié dans le source :
  • mali_kbase_mem.c:2721 kbase_jit_destroy_worker libère la région, n'efface jamais kctx->jit_alloc[id]
  • mali_kbase_softjobs.c:1270 kbase_jit_free_finish déréférence le jit_alloc[ids[j]] obsolète
  • mali_kbase_mem.c:3138 kbase_jit_backing_lost → chemin de destruction (se déclenche pendant le reclaim)