Проект с использованием ИИ. Это исследование, разработка эксплойта и документация были выполнены с помощью ИИ с использованием моделей GLM-5.3 и DeepSeek V4.1 Flash.

amazon-mustang-hack

Исследование root-эксплойта для Amazon Fire 7 9-го поколения (mustang, MT8163, Mali-T720) на финальной прошивке — Fire OS 7.3.3.1, PS7331.4463N, ядро 4.9.117 (сборка 2025-05-03, SPL 2024-08-01).

Цель: LineageOS. Путь через загрузчик на этом устройстве мёртв (пропатченный bootrom — только preloader через замыкание CMD), поэтому единственный оставшийся маршрут — программный эксплойт ядра.

Быстрый старт```

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

При успехе:```
/data/metrics/su id     # run a command as root
/data/metrics/su        # interactive root shell

Победа в reclaim происходит примерно 1 загрузка из 3, а проигрыш приводит к панике/перезагрузке планшета; run.sh просто ждёт перезагрузки и повторяет попытку. SELinux принудительно переводится в Permissive в рамках эксплойта, поэтому root доступен только во время выполнения — перезагрузка восстанавливает стоковое состояние, и вы снова запускаете run.sh.

Предсобранные st3 и su (armv7 static) закоммичены, поэтому для запуска тулчейн не нужен. ./run.sh --build пересобирает их из poc/*.c, если у вас есть zig.

Всё ниже — просто лог работы, выполненной моделью, ниже нет ввода человека.

ОСНОВНАЯ ЦЕЛЬ (начиная с сессии 5): kbase CVE-2022-38181 — этап 2 ДОКАЗАН

GhostLock (ниже) отложен: вариант MTK с BUG_ON rtmutex + отсутствие раскрытия адресов ядра из шелла = архитектурный тупик на этой сборке (сессии 2-4). kbase JIT UAF был передиагностирован (паника destroy-worker «безусловная паника» была разыменованием JIT_FREE, лог потерян из-за смерти adbd посреди паники), и этап 2 теперь доказан оракулом — см. раздел СЕССИЯ 5.

ОТЛОЖЕНО: GhostLock, CVE-2026-43499

rtmutex remove_waiter() futex-PI stack-UAF (раскрытие NebuSec 2026-07, исправление 3bfdc63936dd вошло 2026-04). Уязвимый диапазон 2.6.39–7.1 → наша 4.9.117 (май 2025) затронута.

Проверено на нашей точной сборке:

• CONFIG_FUTEX=y, rtmutex скомпилирован, баг присутствует дословно: rtmutex.c:1108-1111 использует current->pi_lock/current->pi_blocked_on (должно быть waiter->task); баговое место вызова rtmutex.c:1723 (путь ошибки rt_mutex_start_proxy_lock)
• Поверхность триггера = чистые futex-сисколлы (WAIT_REQUEUE_PI/CMP_REQUEUE_PI), без узла устройства, ничего не ограничено SELinux — фатальных препятствий пути kbase здесь не существует
• Потребитель: sched_setattr → __sched_setscheduler → rt_mutex_adjust_pi(p) в sched/core.c:4706 — разыменовывает устаревший pi_blocked_on ✓
• Прокси-ожидающий живёт на собственном стеке потока-ожидающего (futex.c:1975 передаёт this->rt_waiter, объявленный в futex_wait_requeue_pi в futex.c:2880) → ожидающий штампует свой собственный освобождённый фрейм через arm32 select (nr 142) fd_sets
• Условия эксплуатации: нет KASLR (фиксированная база 0xc0008000), нет PAN, DEBUG_RT_MUTEXES выключен → компактный 48-байтовый rt_mutex_waiter (tree_entry@0, pi_tree_entry@0xc, task@0x18, lock@0x1c, prio@0x20, deadline@0x28)
• Минимальная цепочка: 2 write-слота → modprobe_path @ 0xc111488c (строка самоопределяется в vmlinux; KALLSYMS_ALL выключен, поэтому символы данных требуют этого трюка) → exec неизвестного binfmt → root-скрипт (setenforce 0, отключение OTA, su)
• Ссылки в refs/: NebuSec/CyberMeowfia (оригинал), GhostLock-5.10 (порт для Fire OS 8, полный 32-битный ARM-триггер в src/exp32/), ghostlock-...-4.19-k40 (порт для Qualcomm 4.19 Android)

TODO (план портирования)

1. Написать триггер (3-поточный requeue-PI дедлок, ядра 0-3) — порт exp32/main.c
2. Геометрия штампа: смещение фрейма rt_waiter относительно области fd_set do_sys_select — дизассемблировать наш vmlinux (do_sys_select stack_fds против фрейма futex_wait_requeue_pi), выставить STAMP_NFDS/STAMP_WAITER_OFF как настраиваемые параметры
3. Кодирование fake-writer для arm32 48-байтового waiter → слоты «записать V в ADDR»
4. 2 слота → modprobe_path, запуск, root-скрипт
5. Запасные варианты, если select-штамп не достаёт: штамп через setsockopt(MCAST_JOIN_SOURCE_GROUP)

Статус

• Bootrom (аппаратный метод amonet) — пропатчен на этом устройстве, тупик
• mtk-su (CVE-2020-0069) — пропатчен, Failed critical init step 3
• Обзор поверхности атаки — /dev/mali0 world-RW + SELinux gpu_device, kbase r26p0-01rel0
• CVE-2022-38181 подтверждён в исходниках точной сборки; триггер этапа 1 работает
• CVE-2026-43499 (GhostLock) проверен, но заблокирован: вариант MTK с BUG_ON rtmutex + отсутствие раскрытия адресов ядра из шелла (сессии 2-4)
• CVE-2022-38181 этап 2 ДОКАЗАН (сессия 5): паника destroy-worker была ошибочным диагнозом; UAF-редирект на заспреенную область, проверено оракулом
• Этап 1: триггер + штамп + потребитель (краш = цепочка жива)
• Этап 2 (путь kbase): UAF-редирект на заспреенную область — ДОКАЗАН в сессии 5
• Этап 2b: управление слотами на уровне сырых байтов (чередование штампов xattr) → unlink-запись
• Этап 3: произвольный вызов функции ядра → ROOT (сессия 10) — перехват хука nf LOCAL_OUT, цепочка selroot из 2 пакетов: обнуление selinux_state.enforcing, перезапись фейковой записи на commit_creds(&init_cred). uid=0, SELinux Permissive.
• [_] Этап 4: root-скрипт (su, permissive, OTA off) + персистентность — root получен; персистентность заблокирована (см. СЕССИЯ 11): LK ограничивает verity-off/SELinux-permissive условиями eng/unlocked, у повторной эксплуатации при загрузке нет жизнеспособного исполнителя. Далее: реверс LK/amzn_verify_unlock.
• Этап 5: собственная цепочка загрузки ОС

Ключевые находки

Устройство / прошивка

• Модель KFMUWI, устройство mustang, Fire OS 7.3.3.1 PS7331.4463N/0031575863040
• Ядро 4.9.117-g08fe75b-dirty, собрано Sat May 3 01:25:15 UTC 2025 (Linaro GCC 6.3-2017.05)
• Amazon молча перевыпустила 7.3.3.1 в мае 2025 (новый incremental, та же строка версии)
• Ревизия Bootrom после 2020: короткое замыкание на GND на eMMC CMD даёт только preloader (пропатчено)
• /dev/kb, /dev/dkb (разделы резервных копий ядра Amazon) root:drmrpc 0660 — заблокированы

Почему применим CVE-2022-38181

• Драйвер: mali_kbase r26p0-01rel0 (Midgard, Mali-T720), внутри уязвимого диапазона NVD r4p0–r31p0
• Пересборка Amazon от мая 2025 поставила баг 2018 года дословно — без бэкпорта
• Точный уязвимый код, проверено по исходникам:
  • mali_kbase_mem.c:2721 kbase_jit_destroy_worker освобождает регион, никогда не очищая kctx->jit_alloc[id]
  • mali_kbase_softjobs.c:1270 kbase_jit_free_finish разыменовывает устаревший jit_alloc[ids[j]]
  • mali_kbase_mem.c:3138 kbase_jit_backing_lost → путь destroy (срабатывает во время reclaim)

Условия эксплуатации (всё проверено по дампу живой конфигурации + OTA vmlinux)

• armv7 32-бит, non-LPAE → нет KASLR (ядро по фиксированному VA 0xc0008000 / PA 0x40080000)
• Нет ARM_SW_DOMAIN_PAN → ret2usr жизнеспособен; CONFIG_PANIC_ON_OOPS=y (неудачные попытки = перезагрузка)
• Нет SLAB_FREELIST_RANDOM/HARDENED, нет CONFIG_USER_NS/USERFAULTFD/NF_TABLES
• CONFIG_MODULES=y, нет STATIC_USERMODEHELPER → перезапись modprobe_path = root
• 1 ГБ RAM → прямой reclaim (нужен для вытеснения) легко достижим; давление >~1 ГБ само по себе вызывает панику ядра (несвязанный баг lowmem/OOM) — держите спрей ≤ 900 МБ, используйте ~700 МБ