Progetto assistito dall'IA. Questa ricerca, lo sviluppo dell'exploit e la documentazione sono stati prodotti con l'assistenza dell'IA utilizzando i modelli GLM-5.3 e DeepSeek V4.1 Flash.

amazon-mustang-hack

Ricerca di exploit root per l'Amazon Fire 7 9ª gen (mustang, MT8163, Mali-T720) sull'ultimo firmware — Fire OS 7.3.3.1, PS7331.4463N, kernel 4.9.117 (compilato il 2025-05-03, SPL 2024-08-01).

Obiettivo: LineageOS. Il percorso del bootloader è morto su questa unità (bootrom patchata — solo preloader tramite cortocircuito CMD), quindi l'unica via rimasta è un exploit software del kernel.

Avvio rapido```

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

In caso di successo:```
/data/metrics/su id     # run a command as root
/data/metrics/su        # interactive root shell

Il reclaim riesce all'incirca 1 avvio su 3 e una perdita manda in panic/riavvia il tablet; run.sh si limita ad attendere il riavvio e riprovare. SELinux viene forzato in Permissive come parte dell'exploit, quindi root è solo a runtime — un riavvio ripristina lo stock e si riesegue run.sh.

st3 e su precompilati (armv7 static) sono inclusi nel repository, quindi non serve alcun toolchain per eseguire. ./run.sh --build li ricompila da poc/*.c se si dispone di zig.

Tutto ciò che segue è solo un log del lavoro svolto dal modello, nessun input umano sotto.

TARGET PRIMARIO (dalla sessione 5): kbase CVE-2022-38181 — stage 2 DIMOSTRATO

GhostLock (sotto) è parcheggiato: la variante rtmutex BUG_ON di MTK + nessuna divulgazione di indirizzi kernel dalla shell = vicolo cieco architetturale su questa build (sessioni 2-4). La UAF del JIT di kbase è stata ridiagnosticata (il "panic incondizionato" del destroy-worker era il deref di JIT_FREE, log perso per la morte di adbd a metà panic) e lo stage 2 è ora dimostrato dall'oracolo — vedi la sezione SESSIONE 5.

PARCHEGGIATO: GhostLock, CVE-2026-43499

UAF sullo stack futex-PI di remove_waiter() in rtmutex (divulgazione NebuSec 2026-07, fix 3bfdc63936dd integrato 2026-04). Intervallo vulnerabile 2.6.39–7.1 → il nostro 4.9.117 (maggio 2025) è affetto.

Verificato sulla nostra build esatta:

• CONFIG_FUTEX=y, rtmutex compilato, bug presente alla lettera: rtmutex.c:1108-1111 usa current->pi_lock/current->pi_blocked_on (dovrebbe essere waiter->task); sito di chiamata difettoso rtmutex.c:1723 (percorso d'errore di rt_mutex_start_proxy_lock)
• Superficie di trigger = pure syscall futex (WAIT_REQUEUE_PI/CMP_REQUEUE_PI), nessun device node, nulla controllato da SELinux — gli ostacoli fatali del percorso kbase qui non esistono
• Consumer: sched_setattr → __sched_setscheduler → rt_mutex_adjust_pi(p) a sched/core.c:4706 — dereferenzia pi_blocked_on obsoleto ✓
• Il proxy waiter risiede sullo stack del thread waiter stesso (futex.c:1975 passa this->rt_waiter, dichiarato in futex_wait_requeue_pi a futex.c:2880) → il waiter marca il proprio frame liberato tramite i fd_set di select (nr 142) su arm32
• Clima di sfruttamento: nessun KASLR (base fissa 0xc0008000), nessun PAN, DEBUG_RT_MUTEXES disattivato → rt_mutex_waiter compatto da 48 byte (tree_entry@0, pi_tree_entry@0xc, task@0x18, lock@0x1c, prio@0x20, deadline@0x28)
• Catena minimale: 2 write-slot → modprobe_path @ 0xc111488c (stringa auto-localizzata in vmlinux; KALLSYMS_ALL disattivato quindi i simboli dati richiedono questo trucco) → exec di binfmt sconosciuto → script root (setenforce 0, disabilita OTA, su)
• Riferimenti in refs/: NebuSec/CyberMeowfia (originale), GhostLock-5.10 (port per Fire OS 8, trigger ARM 32-bit completo in src/exp32/), ghostlock-...-4.19-k40 (port Android Qualcomm 4.19)

TODO (piano di porting)

1. Scrivere il trigger (deadlock requeue-PI a 3 thread, core 0-3) — port di exp32/main.c
2. Geometria dello stamp: offset del frame rt_waiter rispetto all'area fd_set di do_sys_select — disassemblare il nostro vmlinux (do_sys_select stack_fds vs frame di futex_wait_requeue_pi), esporre STAMP_NFDS/STAMP_WAITER_OFF come parametri
3. Codifica fake-writer per waiter arm32 da 48 byte → slot "scrivi V in ADDR"
4. 2 slot → modprobe_path, fire, script root
5. Fallback se lo stamp via select non riesce a raggiungere: stamp via setsockopt(MCAST_JOIN_SOURCE_GROUP)

Stato

• Bootrom (metodo hardware amonet) — patchato su questa unità, vicolo cieco
• mtk-su (CVE-2020-0069) — patchato, Failed critical init step 3
• Ricognizione della superficie d'attacco — /dev/mali0 world-RW + SELinux gpu_device, kbase r26p0-01rel0
• CVE-2022-38181 confermato nel sorgente della build esatta; il trigger dello stage 1 funziona
• CVE-2026-43499 (GhostLock) verificato ma bloccato: variante rtmutex BUG_ON di MTK + nessuna divulgazione di indirizzi kernel dalla shell (sessioni 2-4)
• CVE-2022-38181 stage 2 DIMOSTRATO (sessione 5): il panic del destroy-worker era una diagnosi errata; redirect della UAF sulla regione spruzzata, verificato dall'oracolo
• Stage 1: trigger + stamp + consumer (crash = catena attiva)
• Stage 2 (percorso kbase): redirect della UAF sulla regione spruzzata — DIMOSTRATO sessione 5
• Stage 2b: controllo degli slot byte-grezzi (churn dello stamp xattr) → scrittura unlink
• Stage 3: chiamata arbitraria a funzione kernel → ROOT (sessione 10) — hijack dell'hook nf LOCAL_OUT, catena selroot a 2 pacchetti: azzera selinux_state.enforcing, riscrive la fake entry in commit_creds(&init_cred). uid=0, SELinux Permissive.
• [_] Stage 4: script root (su, permissive, OTA off) + persistenza — root ottenuto; persistenza bloccata (vedi SESSIONE 11): LK vincola verity-off/SELinux-permissive a eng/unlocked, il re-exploit all'avvio non ha un esecutore praticabile. Prossimo: reverse di LK/amzn_verify_unlock.
• Stage 5: catena di avvio di un OS personalizzato

Risultati chiave

Dispositivo / firmware

• Modello KFMUWI, device mustang, Fire OS 7.3.3.1 PS7331.4463N/0031575863040
• Kernel 4.9.117-g08fe75b-dirty, compilato Sat May 3 01:25:15 UTC 2025 (Linaro GCC 6.3-2017.05)
• Amazon ha silenziosamente riemesso la 7.3.3.1 a maggio 2025 (nuovo incrementale, stessa stringa di versione)
• Revisione del Bootrom post-2020: corto verso GND su eMMC CMD dà solo il preloader (patchato)
• /dev/kb, /dev/dkb (partizioni di kernel-backup Amazon) root:drmrpc 0660 — bloccati

Perché CVE-2022-38181 si applica

• Driver: mali_kbase r26p0-01rel0 (Midgard, Mali-T720), all'interno dell'intervallo affetto NVD r4p0–r31p0
• La ricompilazione di maggio 2025 di Amazon ha incluso il bug del 2018 alla lettera — nessun backport
• Codice vulnerabile esatto, verificato dal sorgente:
  • mali_kbase_mem.c:2721 kbase_jit_destroy_worker libera la regione, non azzera mai kctx->jit_alloc[id]
  • mali_kbase_softjobs.c:1270 kbase_jit_free_finish dereferenzia il jit_alloc[ids[j]] obsoleto
  • mali_kbase_mem.c:3138 kbase_jit_backing_lost → percorso di destroy (si attiva durante il reclaim)