KI-gestütztes Projekt. Diese Recherche, Exploit-Entwicklung und Dokumentation wurden mit KI-Unterstützung unter Verwendung der Modelle GLM-5.3 und DeepSeek V4.1 Flash erstellt.

amazon-mustang-hack

Root-Exploit-Recherche für das Amazon Fire 7 9. Gen (mustang, MT8163, Mali-T720) auf der finalen Firmware — Fire OS 7.3.3.1, PS7331.4463N, Kernel 4.9.117 (gebaut 2025-05-03, SPL 2024-08-01).

Ziel: LineageOS. Der Bootloader-Pfad ist auf diesem Gerät tot (gepatchtes Bootrom — nur Preloader via CMD-Kurzschluss), daher ist der einzige verbleibende Weg ein Software-Kernel-Exploit.

Schnellstart```

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

Bei Erfolg:```
/data/metrics/su id     # run a command as root
/data/metrics/su        # interactive root shell

Der Reclaim gewinnt ungefähr 1 Boot von 3 und ein Verlust führt zu einer Panik/Neustart des Tablets; run.sh wartet einfach auf den Neustart und versucht es erneut. SELinux wird als Teil des Exploits auf Permissive gezwungen, daher ist root nur zur Laufzeit — ein Neustart stellt den Auslieferungszustand wieder her und du führst run.sh erneut aus.

Vorkompiliertes st3 und su (armv7 static) sind eingecheckt, daher wird keine Toolchain zum Ausführen benötigt. ./run.sh --build baut sie aus poc/*.c neu, wenn du zig hast.

Alles unterhalb ist nur ein Protokoll der vom Modell geleisteten Arbeit, kein menschlicher Input unterhalb.

PRIMÄRES ZIEL (seit Session 5): kbase CVE-2022-38181 — Stufe 2 BEWIESEN

GhostLock (unten) ist geparkt: MTKs BUG_ON-rtmutex-Variante + keine Kernel-Adress-Offenlegung aus der Shell = architektonische Sackgasse in diesem Build (Sessions 2-4). Der kbase JIT UAF wurde neu diagnostiziert (die Destroy-Worker-„bedingungslose Panik" war die JIT_FREE-Dereferenzierung, Log verloren durch adbd-Tod mitten in der Panik) und Stufe 2 ist nun orakel-bewiesen — siehe SESSION 5 Abschnitt.

GEPARKT: GhostLock, CVE-2026-43499

rtmutex remove_waiter() futex-PI Stack-UAF (NebuSec-Offenlegung 2026-07, Fix 3bfdc63936dd gelandet 2026-04). Verwundbarer Bereich 2.6.39–7.1 → unser 4.9.117 (Mai 2025) ist betroffen.

Verifiziert auf unserem exakten Build:

• CONFIG_FUTEX=y, rtmutex einkompiliert, Bug wörtlich vorhanden: rtmutex.c:1108-1111 verwendet current->pi_lock/current->pi_blocked_on (sollte waiter->task sein); fehlerhafte Aufrufstelle rtmutex.c:1723 (rt_mutex_start_proxy_lock Fehlerpfad)
• Trigger-Oberfläche = reine futex-Syscalls (WAIT_REQUEUE_PI/CMP_REQUEUE_PI), kein Device-Node, nichts SELinux-geschützt — die fatalen Hindernisse des kbase-Pfads existieren hier nicht
• Konsument: sched_setattr → __sched_setscheduler → rt_mutex_adjust_pi(p) bei sched/core.c:4706 — dereferenziert veraltetes pi_blocked_on ✓
• Proxy-Waiter lebt auf dem eigenen Stack des Waiter-Threads (futex.c:1975 übergibt this->rt_waiter, deklariert in futex_wait_requeue_pi bei futex.c:2880) → Waiter stempelt seinen eigenen freigegebenen Frame via arm32 select (nr 142) fd_sets
• Ausbeutungsklima: kein KASLR (feste Basis 0xc0008000), kein PAN, DEBUG_RT_MUTEXES aus → kompakter 48-Byte rt_mutex_waiter (tree_entry@0, pi_tree_entry@0xc, task@0x18, lock@0x1c, prio@0x20, deadline@0x28)
• Minimale Kette: 2 Write-Slots → modprobe_path @ 0xc111488c (String selbst-lokalisiert in vmlinux; KALLSYMS_ALL aus, daher brauchen Datensymbole diesen Trick) → unknown-binfmt exec → root script (setenforce 0, OTA deaktivieren, su)
• Referenzen in refs/: NebuSec/CyberMeowfia (Original), GhostLock-5.10 (Fire OS 8 Port, vollständiger 32-Bit-ARM-Trigger in src/exp32/), ghostlock-...-4.19-k40 (Qualcomm 4.19 Android Port)

TODO (Port-Plan)

1. Trigger schreiben (3-Thread requeue-PI Deadlock, Cores 0-3) — Port von exp32/main.c
2. Stamp-Geometrie: rt_waiter Frame-Offset vs do_sys_select fd_set-Bereich — unser vmlinux disassemblieren (do_sys_select stack_fds vs futex_wait_requeue_pi Frame), STAMP_NFDS/STAMP_WAITER_OFF als Tunables offenlegen
3. Fake-Writer-Encoding für arm32 48-Byte Waiter → „write V to ADDR"-Slots
4. 2 Slots → modprobe_path, feuern, root script
5. Fallbacks falls select-Stamp nicht erreicht: setsockopt(MCAST_JOIN_SOURCE_GROUP) Stamp

Status

• Bootrom (amonet Hardware-Methode) — auf diesem Gerät gepatcht, Sackgasse
• mtk-su (CVE-2020-0069) — gepatcht, Failed critical init step 3
• Angriffsflächen-Untersuchung — /dev/mali0 world-RW + SELinux gpu_device, kbase r26p0-01rel0
• CVE-2022-38181 im exakten Build-Quellcode bestätigt; Stufe-1-Trigger funktioniert
• CVE-2026-43499 (GhostLock) verifiziert, aber blockiert: MTK BUG_ON rtmutex Variante + keine Kernel-Adress-Offenlegung aus der Shell (Sessions 2-4)
• CVE-2022-38181 Stufe 2 BEWIESEN (Session 5): Destroy-Worker-Panik war eine Fehldiagnose; UAF-Umleitung auf gesprayte Region, orakel-verifiziert
• Stufe 1: Trigger + Stamp + Konsument (Crash = Kette live)
• Stufe 2 (kbase-Pfad): UAF-Umleitung auf gesprayte Region — BEWIESEN Session 5
• Stufe 2b: Raw-Byte-Slot-Kontrolle (xattr-Stamp-Churn) → unlink Write
• Stufe 3: beliebiger Kernel-Funktionsaufruf → ROOT (Session 10) — nf LOCAL_OUT Hook-Hijack, selroot 2-Paket-Kette: selinux_state.enforcing nullen, Fake-Eintrag auf commit_creds(&init_cred) umschreiben. uid=0, SELinux Permissive.
• [_] Stufe 4: Root-Script (su, permissive, OTA aus) + Persistenz — root erlangt; Persistenz blockiert (siehe SESSION 11): LK gated verity-off/SELinux-permissive auf eng/unlocked, Boot-Zeit-Re-Exploit hat keinen gangbaren Executor. Nächstes: LK/amzn_verify_unlock reversen.
• Stufe 5: eigene OS-Boot-Kette

Wichtige Erkenntnisse

Gerät / Firmware

• Modell KFMUWI, Gerät mustang, Fire OS 7.3.3.1 PS7331.4463N/0031575863040
• Kernel 4.9.117-g08fe75b-dirty, gebaut Sat May 3 01:25:15 UTC 2025 (Linaro GCC 6.3-2017.05)
• Amazon hat 7.3.3.1 im Mai 2025 stillschweigend neu herausgegeben (neues Incremental, gleicher Versionsstring)
• Bootrom-Revision nach 2020: Kurzschluss-zu-GND auf eMMC CMD liefert nur Preloader (gepatcht)
• /dev/kb, /dev/dkb (Amazon Kernel-Backup-Partitionen) root:drmrpc 0660 — gesperrt

Warum CVE-2022-38181 zutrifft

• Treiber: mali_kbase r26p0-01rel0 (Midgard, Mali-T720), innerhalb des NVD-betroffenen Bereichs r4p0–r31p0
• Amazons Mai-2025-Rebuild lieferte den Bug von 2018 wörtlich aus — kein Backport
• Exakter verwundbarer Code, quellcode-verifiziert:
  • mali_kbase_mem.c:2721 kbase_jit_destroy_worker gibt Region frei, löscht nie kctx->jit_alloc[id]
  • mali_kbase_softjobs.c:1270 kbase_jit_free_finish dereferenziert das veraltete jit_alloc[ids[j]]
  • mali_kbase_mem.c:3138 kbase_jit_backing_lost → Destroy-Pfad (feuert während Reclaim)

Ausbeutungsklima (alles verifiziert aus Live-Config-Dump + OTA vmlinux)

• armv7 32-Bit, non-LPAE → kein KASLR (Kernel bei fester 0xc0008000 VA / 0x40080000 PA)
• Kein ARM_SW_DOMAIN_PAN → ret2usr gangbar; CONFIG_PANIC_ON_OOPS=y (fehlgeschlagene Versuche = Neustart)
• Kein SLAB_FREELIST_RANDOM/HARDENED, kein CONFIG_USER_NS/USERFAULTFD/NF_TABLES
• CONFIG_MODULES=y, kein STATIC_USERMODEHELPER → modprobe_path-Überschreiben = root
• 1 GB RAM → direkter Reclaim (nötig für Eviction) trivial erreichbar; Druck >~1 GB panikt den Kernel von selbst (unabhängiger lowmem/OOM-Bug) — Spray ≤ 900 MB halten, ~700 MB verwenden