Proyecto asistido por IA. Esta investigación, el desarrollo del exploit y la documentación fueron producidos con asistencia de IA utilizando los modelos GLM-5.3 y DeepSeek V4.1 Flash.

amazon-mustang-hack

Investigación de exploit de root para el Amazon Fire 7 9.ª gen (mustang, MT8163, Mali-T720) en el firmware final — Fire OS 7.3.3.1, PS7331.4463N, kernel 4.9.117 (compilado 2025-05-03, SPL 2024-08-01).

Objetivo: LineageOS. La ruta del bootloader está muerta en esta unidad (bootrom parcheada — solo preloader vía cortocircuito CMD), por lo que la única ruta restante es un exploit de kernel por software.

Inicio rápido```

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

Si tiene éxito:```
/data/metrics/su id     # run a command as root
/data/metrics/su        # interactive root shell

El reclaim gana aproximadamente 1 arranque de cada 3 y una pérdida provoca un panic/reinicio de la tablet; run.sh simplemente espera al reinicio y reintenta. SELinux se fuerza a Permissive como parte del exploit, por lo que root es solo en tiempo de ejecución — un reinicio restaura el estado original y vuelves a ejecutar run.sh.

Los binarios precompilados st3 y su (armv7 estáticos) están incluidos, así que no se necesita toolchain para ejecutar. ./run.sh --build los recompila desde poc/*.c si tienes zig.

Todo lo que hay debajo es solo un registro del trabajo realizado por el modelo, no hay intervención humana a continuación.

OBJETIVO PRINCIPAL (desde la sesión 5): kbase CVE-2022-38181 — etapa 2 PROBADA

GhostLock (abajo) está aparcado: la variante BUG_ON rtmutex de MTK + la ausencia de divulgación de direcciones del kernel desde el shell = callejón sin salida arquitectónico en esta compilación (sesiones 2-4). El UAF del JIT de kbase fue re-diagnosticado (el "panic incondicional" del destroy-worker era la desreferencia de JIT_FREE, registro perdido por la muerte de adbd a mitad del panic) y la etapa 2 ahora está probada por oráculo — ver la sección SESIÓN 5.

APARCADO: GhostLock, CVE-2026-43499

UAF de pila futex-PI en remove_waiter() de rtmutex (divulgación de NebuSec 2026-07, corrección 3bfdc63936dd aplicada 2026-04). Rango vulnerable 2.6.39–7.1 → nuestro 4.9.117 (mayo 2025) está afectado.

Verificado en nuestra compilación exacta:

• CONFIG_FUTEX=y, rtmutex compilado, bug presente textualmente: rtmutex.c:1108-1111 usa current->pi_lock/current->pi_blocked_on (debería ser waiter->task); sitio de llamada con bug rtmutex.c:1723 (ruta de error de rt_mutex_start_proxy_lock)
• Superficie de activación = syscalls futex puras (WAIT_REQUEUE_PI/CMP_REQUEUE_PI), sin nodo de dispositivo, nada restringido por SELinux — los obstáculos fatales de la ruta kbase no existen aquí
• Consumidor: sched_setattr → __sched_setscheduler → rt_mutex_adjust_pi(p) en sched/core.c:4706 — desreferencia pi_blocked_on obsoleto ✓
• El proxy waiter vive en la propia pila del hilo waiter (futex.c:1975 pasa this->rt_waiter, declarado en futex_wait_requeue_pi en futex.c:2880) → el waiter marca su propio frame liberado mediante select de arm32 (nr 142) fd_sets
• Clima de explotación: sin KASLR (base fija 0xc0008000), sin PAN, DEBUG_RT_MUTEXES desactivado → rt_mutex_waiter compacto de 48 bytes (tree_entry@0, pi_tree_entry@0xc, task@0x18, lock@0x1c, prio@0x20, deadline@0x28)
• Cadena mínima: 2 write-slots → modprobe_path @ 0xc111488c (cadena auto-localizada en vmlinux; KALLSYMS_ALL desactivado, así que los símbolos de datos necesitan este truco) → exec de binfmt desconocido → script root (setenforce 0, desactivar OTA, su)
• Referencias en refs/: NebuSec/CyberMeowfia (original), GhostLock-5.10 (port a Fire OS 8, trigger completo de ARM de 32 bits en src/exp32/), ghostlock-...-4.19-k40 (port a Android Qualcomm 4.19)

TODO (plan de port)

1. Escribir el trigger (interbloqueo requeue-PI de 3 hilos, núcleos 0-3) — port de exp32/main.c
2. Geometría del stamp: offset del frame rt_waiter vs área fd_set de do_sys_select — desensamblar nuestro vmlinux (do_sys_select stack_fds vs frame de futex_wait_requeue_pi), exponer STAMP_NFDS/STAMP_WAITER_OFF como parámetros ajustables
3. Codificación del fake-writer para waiter de 48 bytes en arm32 → slots "escribir V en ADDR"
4. 2 slots → modprobe_path, disparar, script root
5. Alternativas si el select-stamp no alcanza: stamp con setsockopt(MCAST_JOIN_SOURCE_GROUP)

Estado

• Bootrom (método hardware amonet) — parcheado en esta unidad, callejón sin salida
• mtk-su (CVE-2020-0069) — parcheado, Failed critical init step 3
• Reconocimiento de superficie de ataque — /dev/mali0 world-RW + SELinux gpu_device, kbase r26p0-01rel0
• CVE-2022-38181 confirmado en el código fuente de la compilación exacta; el trigger de etapa 1 funciona
• CVE-2026-43499 (GhostLock) verificado pero bloqueado: variante BUG_ON rtmutex de MTK + sin divulgación de direcciones del kernel desde el shell (sesiones 2-4)
• CVE-2022-38181 etapa 2 PROBADA (sesión 5): el panic del destroy-worker fue un diagnóstico erróneo; redirección del UAF sobre la región rociada, verificada por oráculo
• Etapa 1: trigger + stamp + consumidor (crash = cadena activa)
• Etapa 2 (ruta kbase): redirección del UAF sobre la región rociada — PROBADA sesión 5
• Etapa 2b: control de slot byte a byte (rotación de stamp por xattr) → escritura unlink
• Etapa 3: llamada arbitraria a función del kernel → ROOT (sesión 10) — secuestro del hook nf LOCAL_OUT, cadena de 2 paquetes selroot: poner a cero selinux_state.enforcing, reescribir la entrada falsa a commit_creds(&init_cred). uid=0, SELinux Permissive.
• [_] Etapa 4: script root (su, permissive, OTA off) + persistencia — root obtenido; persistencia bloqueada (ver SESIÓN 11): LK condiciona verity-off/SELinux-permissive a eng/unlocked, el re-exploit en tiempo de arranque no tiene ejecutor viable. Siguiente: revertir LK/amzn_verify_unlock.
• Etapa 5: cadena de arranque de SO personalizada

Hallazgos clave

Dispositivo / firmware

• Modelo KFMUWI, dispositivo mustang, Fire OS 7.3.3.1 PS7331.4463N/0031575863040
• Kernel 4.9.117-g08fe75b-dirty, compilado Sat May 3 01:25:15 UTC 2025 (Linaro GCC 6.3-2017.05)
• Amazon reeditó silenciosamente 7.3.3.1 en mayo de 2025 (nuevo incremental, misma cadena de versión)
• Revisión de Bootrom posterior a 2020: cortocircuito a GND en eMMC CMD da solo preloader (parcheado)
• /dev/kb, /dev/dkb (particiones de respaldo del kernel de Amazon) root:drmrpc 0660 — bloqueadas

Por qué aplica CVE-2022-38181

• Driver: mali_kbase r26p0-01rel0 (Midgard, Mali-T720), dentro del rango afectado de NVD r4p0–r31p0
• La recompilación de Amazon de mayo de 2025 incluyó el bug de 2018 textualmente — sin backport
• Código vulnerable exacto, verificado en el código fuente:
  • mali_kbase_mem.c:2721 kbase_jit_destroy_worker libera la región, nunca limpia kctx->jit_alloc[id]
  • mali_kbase_softjobs.c:1270 kbase_jit_free_finish desreferencia el jit_alloc[ids[j]] obsoleto
  • mali_kbase_mem.c:3138 kbase_jit_backing_lost → ruta de destrucción (se dispara durante el reclaim)