Projeto assistido por IA. Esta pesquisa, desenvolvimento de exploit e documentação foram produzidos com assistência de IA usando os modelos GLM-5.3 e DeepSeek V4.1 Flash.

amazon-mustang-hack

Pesquisa de exploit de root para o Amazon Fire 7 9ª geração (mustang, MT8163, Mali-T720) no firmware final — Fire OS 7.3.3.1, PS7331.4463N, kernel 4.9.117 (compilado em 2025-05-03, SPL 2024-08-01).

Objetivo: LineageOS. O caminho do bootloader está morto nesta unidade (bootrom corrigida — apenas preloader via curto de CMD), então a única rota restante é um exploit de kernel por software.

Início 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

Em caso de sucesso:```
/data/metrics/su id     # run a command as root
/data/metrics/su        # interactive root shell

O reclaim ganha aproximadamente 1 boot em 3 e uma perda entra em pânico/reinicia o tablet; run.sh apenas aguarda o reboot e tenta novamente. O SELinux é forçado para Permissive como parte do exploit, então o root é apenas em tempo de execução — um reboot restaura o estado original e você executa run.sh novamente.

Os binários pré-compilados st3 e su (armv7 estático) estão commitados, então nenhum toolchain é necessário para executar. ./run.sh --build os recompila a partir de poc/*.c se você tiver zig.

Qualquer coisa abaixo é apenas um log do trabalho feito pelo modelo, nenhuma entrada humana abaixo.

ALVO PRIMÁRIO (desde a sessão 5): kbase CVE-2022-38181 — estágio 2 PROVADO

O GhostLock (abaixo) está arquivado: a variante BUG_ON rtmutex da MTK + nenhuma divulgação de endereço de kernel a partir do shell = beco sem saída arquitetural nesta build (sessões 2-4). O UAF do JIT do kbase foi rediagnosticado (o "pânico incondicional" do destroy-worker era o deref do JIT_FREE, log perdido pela morte do adbd no meio do pânico) e o estágio 2 agora está provado por oráculo — veja a seção SESSÃO 5.

ARQUIVADO: GhostLock, CVE-2026-43499

UAF de pilha do futex-PI em remove_waiter() do rtmutex (divulgação NebuSec 2026-07, correção 3bfdc63936dd aplicada em 2026-04). Faixa vulnerável 2.6.39–7.1 → nosso 4.9.117 (maio de 2025) é afetado.

Verificado na nossa build exata:

• CONFIG_FUTEX=y, rtmutex compilado, bug presente literalmente: rtmutex.c:1108-1111 usa current->pi_lock/current->pi_blocked_on (deveria ser waiter->task); local de chamada com bug rtmutex.c:1723 (caminho de erro de rt_mutex_start_proxy_lock)
• Superfície de disparo = syscalls futex puras (WAIT_REQUEUE_PI/CMP_REQUEUE_PI), sem nó de dispositivo, nada controlado pelo SELinux — os obstáculos fatais do caminho kbase não existem aqui
• Consumidor: sched_setattr → __sched_setscheduler → rt_mutex_adjust_pi(p) em sched/core.c:4706 — desreferencia pi_blocked_on obsoleto ✓
• O proxy waiter vive na própria pilha da thread waiter (futex.c:1975 passa this->rt_waiter, declarado em futex_wait_requeue_pi em futex.c:2880) → o waiter marca seu próprio frame liberado via select do arm32 (nr 142) fd_sets
• Clima de exploração: sem KASLR (base fixa 0xc0008000), sem PAN, DEBUG_RT_MUTEXES desligado → rt_mutex_waiter compacto de 48 bytes (tree_entry@0, pi_tree_entry@0xc, task@0x18, lock@0x1c, prio@0x20, deadline@0x28)
• Cadeia mínima: 2 write-slots → modprobe_path @ 0xc111488c (string auto-localizada em vmlinux; KALLSYMS_ALL desligado, então símbolos de dados precisam deste truque) → exec de binfmt desconhecido → script root (setenforce 0, desabilitar OTA, su)
• Referências em refs/: NebuSec/CyberMeowfia (original), GhostLock-5.10 (porta para Fire OS 8, trigger ARM 32-bit completo em src/exp32/), ghostlock-...-4.19-k40 (porta Android Qualcomm 4.19)

TODO (plano de porta)

1. Escrever o trigger (deadlock requeue-PI de 3 threads, cores 0-3) — porta de exp32/main.c
2. Geometria do stamp: offset do frame rt_waiter vs área fd_set de do_sys_select — desmontar nosso vmlinux (do_sys_select stack_fds vs frame de futex_wait_requeue_pi), expor STAMP_NFDS/STAMP_WAITER_OFF como ajustáveis
3. Codificação de fake-writer para waiter de 48 bytes do arm32 → slots "escrever V em ADDR"
4. 2 slots → modprobe_path, disparar, script root
5. Alternativas caso o select-stamp não alcance: stamp via setsockopt(MCAST_JOIN_SOURCE_GROUP)

Status

• Bootrom (método de hardware amonet) — corrigido nesta unidade, beco sem saída
• mtk-su (CVE-2020-0069) — corrigido, Failed critical init step 3
• Levantamento de superfície de ataque — /dev/mali0 world-RW + SELinux gpu_device, kbase r26p0-01rel0
• CVE-2022-38181 confirmado no código-fonte da build exata; trigger do estágio 1 funciona
• CVE-2026-43499 (GhostLock) verificado mas bloqueado: variante BUG_ON rtmutex da MTK + nenhuma divulgação de endereço de kernel a partir do shell (sessões 2-4)
• CVE-2022-38181 estágio 2 PROVADO (sessão 5): o pânico do destroy-worker foi um diagnóstico equivocado; redirecionamento de UAF para região sprayada, verificado por oráculo
• Estágio 1: trigger + stamp + consumidor (crash = cadeia ativa)
• Estágio 2 (caminho kbase): redirecionamento de UAF para região sprayada — PROVADO sessão 5
• Estágio 2b: controle de slot por byte bruto (churn de stamp via xattr) → escrita de unlink
• Estágio 3: chamada arbitrária de função do kernel → ROOT (sessão 10) — sequestro de hook nf LOCAL_OUT, cadeia de 2 pacotes selroot: zerar selinux_state.enforcing, reescrever entrada falsa para commit_creds(&init_cred). uid=0, SELinux Permissive.
• [_] Estágio 4: script root (su, permissive, OTA desligado) + persistência — root obtido; persistência bloqueada (veja SESSÃO 11): o LK condiciona verity-off/SELinux-permissive a eng/unlocked, o re-exploit no boot não tem executor viável. Próximo: reverter LK/amzn_verify_unlock.
• Estágio 5: cadeia de boot de SO customizado

Principais descobertas

Dispositivo / firmware

• Modelo KFMUWI, dispositivo mustang, Fire OS 7.3.3.1 PS7331.4463N/0031575863040
• Kernel 4.9.117-g08fe75b-dirty, compilado em Sat May 3 01:25:15 UTC 2025 (Linaro GCC 6.3-2017.05)
• A Amazon reemitiu silenciosamente o 7.3.3.1 em maio de 2025 (novo incremental, mesma string de versão)
• Revisão de Bootrom pós-2020: curto para GND no CMD do eMMC fornece apenas preloader (corrigido)
• /dev/kb, /dev/dkb (partições de backup de kernel da Amazon) root:drmrpc 0660 — bloqueados

Por que o CVE-2022-38181 se aplica

• Driver: mali_kbase r26p0-01rel0 (Midgard, Mali-T720), dentro da faixa afetada do NVD r4p0–r31p0
• A recompilação da Amazon de maio de 2025 enviou o bug de 2018 literalmente — sem backport
• Código vulnerável exato, verificado no código-fonte:
  • mali_kbase_mem.c:2721 kbase_jit_destroy_worker libera a região, nunca limpa kctx->jit_alloc[id]
  • mali_kbase_softjobs.c:1270 kbase_jit_free_finish desreferencia o jit_alloc[ids[j]] obsoleto
  • mali_kbase_mem.c:3138 kbase_jit_backing_lost → caminho de destroy (dispara durante o reclaim)

Clima de exploração (tudo verificado a partir do dump de config ao vivo + vmlinux da OTA)

• armv7 32-bit, não-LPAE → sem KASLR (kernel em VA fixo 0xc0008000 / PA 0x40080000)
• Sem ARM_SW_DOMAIN_PAN → ret2usr viável; CONFIG_PANIC_ON_OOPS=y (tentativas falhas = reboot)
• Sem SLAB_FREELIST_RANDOM/HARDENED, sem CONFIG_USER_NS/USERFAULTFD/NF_TABLES
• CONFIG_MODULES=y, sem STATIC_USERMODEHELPER → sobrescrita de modprobe_path = root
• 1 GB de RAM → reclaim direto (necessário para eviction) trivialmente alcançável; pressão >~1 GB entra em pânico no kernel por conta própria (bug de lowmem/OOM não relacionado) — mantenha o spray ≤ 900 MB, use ~700 MB