artur9010/amazon-mustang-hackИсследование эксплойта ядра, достигающее временного root на Amazon Fire 7 (Fire OS 7.3.3.1) через use-after-free в JIT Mali kbase CVE-2022-38181, с цепочкой перезаписи modprobe_path.
Проект с использованием ИИ. Это исследование, разработка эксплойта и документация были выполнены с помощью ИИ с использованием моделей GLM-5.3 и DeepSeek V4.1 Flash.
Исследование 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), поэтому единственный оставшийся маршрут — программный эксплойт ядра.
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.
GhostLock (ниже) отложен: вариант MTK с BUG_ON rtmutex + отсутствие раскрытия адресов ядра из шелла = архитектурный тупик на этой сборке (сессии 2-4). kbase JIT UAF был передиагностирован (паника destroy-worker «безусловная паника» была разыменованием JIT_FREE, лог потерян из-за смерти adbd посреди паники), и этап 2 теперь доказан оракулом — см. раздел СЕССИЯ 5.
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)WAIT_REQUEUE_PI/CMP_REQUEUE_PI), без узла устройства,
ничего не ограничено SELinux — фатальных препятствий пути kbase здесь не существуетsched_setattr → __sched_setscheduler → rt_mutex_adjust_pi(p) в
sched/core.c:4706 — разыменовывает устаревший ✓exp32/main.crt_waiter относительно области fd_set do_sys_select — дизассемблировать
наш vmlinux (do_sys_select stack_fds против фрейма futex_wait_requeue_pi), выставить
STAMP_NFDS/STAMP_WAITER_OFF как настраиваемые параметрыFailed critical init step 3/dev/mali0 world-RW + SELinux gpu_device, kbase r26p0-01rel0mustang, Fire OS 7.3.3.1 PS7331.4463N/00315758630404.9.117-g08fe75b-dirty, собрано Sat May 3 01:25:15 UTC 2025 (Linaro GCC 6.3-2017.05)/dev/kb, /dev/dkb (разделы резервных копий ядра Amazon) root:drmrpc 0660 — заблокированыmali_kbase r26p0-01rel0 (Midgard, Mali-T720), внутри уязвимого диапазона NVD r4p0–r31p0mali_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)0xc0008000 / PA 0x40080000)ARM_SW_DOMAIN_PAN → ret2usr жизнеспособен; CONFIG_PANIC_ON_OOPS=y (неудачные попытки = перезагрузка)SLAB_FREELIST_RANDOM/HARDENED, нет CONFIG_USER_NS/USERFAULTFD/NF_TABLESCONFIG_MODULES=y, нет STATIC_USERMODEHELPER → перезапись modprobe_path = root_IOC_TYPE 0x80)MEM_ALLOC — 32 байта (in содержит 4 × u64, включая extent)BASE_MEM_PROT_GPU_RD|WR (биты 2|3), а не устаревшие R|Wmmap(fd, offset=3<<12, PROT_NONE)JOB_SUBMIT должен равняться sizeof(base_jd_atom_v2) = 48 (base_jd_prio/base_jd_dep_type — это typedef u8)MEM_JIT_INIT (nr 14, структура v2), alloc/free — это soft jobs через JOB_SUBMIT
(BASE_JD_REQ_SOFT_JIT_ALLOC=0x209, ...FREE=0x20a; =указатель пользователя, =количество)Паника возникает во время самого вытеснения (evictable_reclaim_scan_objects → backing_lost →
destroy worker) — висячие ссылки (jit_alloc[], список evict) обходятся ещё до того, как мы
отправим JIT_FREE. Этап 2 должен выиграть гонку: перераспределить освобождённый kbase_va_region нашим
собственным спреем MEM_ALLOC, пока давление всё ещё активно.
poc/stage2.c — эксплойт этапа 2 (режимы: step/uaf/spstep/spfree/spray/keys)
— spray 700 = полный прогон оракула; выживает и приостанавливается (kill для очистки)poc/mustang_jit_uaf.c — PoC этапа 1 (режимы: jit N / control N / pressure N)poc/build.sh — кросс-сборка zig (static musl armv7)kernel/vmlinux — символы, восстановленные из точной OTA-сборки (vmlinux-to-elf)nix-shell -p zig --run 'zig cc -target arm-linux-musleabihf -static -O2 -o juaf poc/mustang_jit_uaf.c' adb push juaf /data/local/tmp/juaf && adb shell chmod 755 /data/local/tmp/juaf adb shell /data/local/tmp/juaf jit 700 # full trigger (~reboots device) adb shell /data/local/tmp/juaf control 700 # no-JIT control adb shell /data/local/tmp/juaf pressure 700 # raw memory-pressure control
## Ссылки
- Рекомендация GHSL-2022-054: https://securitylab.github.com/advisories/GHSL-2022-054_Arm_Mali/
- Разбор эксплойта Mo для Pixel 6: https://github.blog/2023-01-23-pwning-the-all-google-phone-with-a-non-google-bug/
- Прецедент Fire HD 10 (trona), то же семейство багов: ericpardee.github.io/fire-hd-ownership
- Портал OSS Amazon: amazon.com gp/help/customer/display.html nodeId=200203720
- Тема разблокировки на XDA (мертва для этой ревизии железа): xdaforums.com/t/fire-7-2019-mustang-unbrick-downgrade-unlock-root.3944365/
## Дополнение к сессии 3 (глубокое исследование syscall-stamp)
Измеренные глубины копирования из источника (абсолютные относительно syscall-entry sp0; диапазон waiter -0x1d8..-0x1a8):
- sendto sockaddr @ -0xc4 | process_vm iov @ -0x104 | recvmsg iov @ -0x11c
- sendmsg iov @ -0x12c | recvmmsg iov @ -0x154 | select fds @ -0x174
- pselect6 fds @ -0x19c | **sendmmsg iov @ -0x1bc (ЛУЧШИЙ — 0x1c не дотягивает до waiter+0x00)**
- poll entries @ -0x3e0 (полностью ниже; не та сторона)
Исключено в этой сессии:
- цепочка io_submit слишком мелкая (~-0x130) | semtimedop: CONFIG_SYSVIPC=n (заглушка)
- configfs смонтирован, но зарегистрировано НОЛЬ подсистем (нет целей для mkdir)
- /sys/kernel/debug, /config: SELinux запрещает доступ для shell
- /proc/sys/kernel: getdents работает (перечислено 29 записей), открывается только pid_max;
чтение kptr_restrict/hotplug/hostname/domainname — всё запрещено
- Записываемое значение ВСЕГДА waiter+0 (адрес в стеке ядра, исполняемый, шелл-код по
+0x1c): rb_link_node *link = node, insert_color записывает parent-color — вариант с
контролируемым значением невозможен без штамповки полей дерева (разрыв -0x1d8..-0x1bc)
- Поля диспетчеризации с двойным разыменованием читают *(waiter+0)=1, *(waiter+4/+8)=0 — BLX 1/0
(nf_hooks, net_families, inet[6]_protos, seq_file->op — всё мертво)
- timer_list.function@+0xc и work_struct.func@+0xc прочитали бы *(waiter+0xc) =
self-ptr pi_tree = ИСПОЛНЯЕМЫЙ waiter+0xc — но ни один путь не ставит waiter+0 как
timer/work (повреждение link / нет источников косвенной постановки в очередь)
- Tree-root-nonzero (слот обработчика sysctl) = детерминированная погоня за указателями
через .text как rb-tree; завершается на нулевом слове — симулируемо офлайн, но попадание
в полезный записываемый слот неправдоподобно
Оставшиеся зацепки для сессии 4:
1. Глубокие пути ioctl: копирование dev_ioctl ifreq (40B пользовательских данных) — измерить
глубину цепочки SyS_ioctl→sock_ioctl→dev_ioctl относительно -0x1d8
2. Любое другое копирование на 0x1c глубже, чем sendmmsg (пока ничего не найдено)
3. Если охота за поверхностью штамповки провалится: пересмотреть walk-chained конструкции или
искать классы записываемых слотов с нулевым вызовом, ещё не перечисленные
## СЕССИЯ 4 — ДВА ПРОРЫВА
### 1. rtmutex_common.h от MTK — вот и вся загадка
MTK заменил апстримный NULL-безопасный rt_mutex_top_waiter на:```c
w = rb_entry(lock->waiters_leftmost, struct rt_mutex_waiter, tree_entry);
BUG_ON(w->lock != lock); // compiled to: ldr sb,[lock+8]; ldr r3,[sb+0x1c]; cmp; bne→udf#0x12
БЕЗ ПРОВЕРКИ НА NULL + BUG_ON. Каждый якорь из одних нулей умирает на *(NULL+0x1c); мусорные якоря умирают на udf. ОБХОД ТРЕБУЕТ: lock->waiters_leftmost (lock+8) должен указывать на поддельный waiter W (записываемый) с W->lock (+0x1c) == lock.
Поток обхода полностью отображён (rt_mutex_adjust_prio_chain @ 0xc0189a58):
/proc/self/task//stat поле 28 (kstkesp) возвращает РЕАЛЬНЫЙ SP ядра для потоков, заблокированных в syscall, из SHELL-контекста (проверено: наблюдались ненулевые значения).
Обход срабатывает детерминированно (проба дедлока: краш каждый раз, чистый код). Запись не может попасть из-за трёхстороннего совпадения усиления защиты ядра:
Окно штампа (waiter+0x1c..0x5b) — единственная контролируемая память с известным содержимым, но её АДРЕС — это неизвестное, которое нам нужно. Самореферентные конструкции все требуют заштамповать адрес ядра как константу — замкнутый круг без утечки.
Их ядро 5.4 имеет UPSTREAM rtmutex_top_waiter (NULL-безопасный: if (!leftmost) return NULL) — якоря пустого дерева выживают, их запись попала в null_fops
(записываемый на их ядре). Даже ОНИ застряли на диспетчеризации ("ioctl reboot").
Дерево MTK 4.9.117 у Mustang имеет вариант с BUG_ON — планшеты Fire OS 8
(GhostLock-5.10) преуспели, потому что их ядра 5.10 в upstream-стиле.
Проверено и мертво из домена shell:
ВЫВОД: GhostLock на mustang требует раскрытия адреса ядра, которое это ядро не предоставляет домену shell. Самореферентный поддельный lock не может быть построен без него.
(a) Детерминированная от загрузки зубрёжка: перезагрузка → калибровка адреса стека через краш- оракул (~20-30 перезагрузок), проверка воспроизводимости. Слабый шанс — выделение стека потока на поздней загрузке вряд ли стабильно. (b) ПОВОРОТ обратно к kbase CVE-2022-38181 с накопленными активами: vmlinux точной сборки + полный исходник + тулчейн + дисциплина трассировки O_SYNC + глубокое знание 4.9. Исходный блокер (паника destroy-worker во время вытеснения JIT) — это проблема тайминга спрея, теперь лучше понятая. (c) Остановиться на честных ~45%: триггер доказан, обход отображён до инструкции, запись заблокирована MTK BUG_ON + отсутствием утечки.
Рекомендуется: (b) — баг kbase подтверждён как присутствующий в этом точном исходнике, имел работающий триггер, и его блокер механический, а не архитектурный.
Режим step (alloc id=1 → DONT_NEED → давление 700MB → MEM_QUERY, БЕЗ free)
выживает: query=-1 (регион освобождён destroy-воркером, rbtree-чисто).
Путь воркера байт-в-байт идентичен легальному потоку JIT_FREE-под-давлением.
Краш сессии 1 всегда был разыменованием висящего указателя JIT_FREE; его строка лога была
потеряна, потому что паника убивает adbd в середине сброса. Проверено ещё дважды в режиме uaf
(голый free → паника, тот же обрыв лога). Поток GHSL-2022-054 полностью живой на этой сборке.
kbase_jit_free(kctx, reg) @ 0xc058495c с полностью контролируемым поддельным reg:
reg->cpu_alloc NULL → размер backed 0 → блок trim пропущен (0xc0584978)kctx+0x147dd (байт) + kctx+0x147de+bin_id (байт)mark_reclaim(reg->gpu_alloc) @ 0xc059b158: цепочка
K=*(gpu_alloc+0x38) → *(K+0x1429c)==0 пропускает mm-атомики →
atomic_sub nents@K+0x141c8, D=*(K+4) → atomic_sub nents@D+0x538.
При nents=0 все записи — no-op stores (strex того же значения).reg->flags |= 0x100000 (запись в поддельное, безвредно)list_add(gpu_alloc->evict_node, &kctx->evict_list): голова evict_list
@ kctx+0x1427c; записи в gpu_alloc+0x18/0x1c (должны быть записываемыми)r3=*(reg+0x3c) prev, r2=*(reg+0x38) next
→ *(next+4)=prev; *(prev+0)=next — две произвольные write-what-where,
затем relink reg+0x38 в jit_pool_head @ kctx+0x148e89 кандидатов; S=0xc118b7ec (данные xfrm, спящие на этом устройстве):
*(S+8)=0 (nents), *(S+0x18)=S+0x18 (пустой evict_node → нет WARN),
K=*(S+0x38)=0xc118b820 → *(K+0x1429c)=0, K/D+0x141c8/+0x538 всё в
записываемых данных. Цели оракула подготовлены: init_uts_ns.name.nodename=0xc110d561
("(none)", читается через uname), скретч P=0xc118bd58 (нули xfrm).
Избегать S=0xc111cba4 (рядом с tracepoint). CONFIG_DEBUG_RODATA=y → все цели записи
должны быть в .data/.bss (bss 0xc11d9000-0xc12d9000).
add_key (CONFIG_KEYS=y): запрещено SELinux для shell. Мёртво.setxattr: kvmalloc(96)+copy_from_user происходит ДО
проверки SELinux → танец аллокаций защищён от SELinux, даже когда вызов падает;
транзиентный (освобождается в конце syscall), байты сохраняются на +4..95 (указатель freelist
затирает +0..3 = rblink, не используется kbase_jit_free)Прогон spray 700 2026-09-11: 5895 регионов распылено во время давления, JIT_FREE
на висящем id=1 завершился на реклеймленном регионе, затем
JIT_ALLOC(0x40, bin 0) прошёл jit_pool_head и вернул VA распылённого региона
#4251 (0x142701000) — именно тот регион, который потребил висящий указатель.
Убийство процесса после: teardown kctx чистый, без краша. Этап 2 завершён:
детерминированное перенаправление UAF с контролируемым типом объекта + содержимым.
Реклейм типа региона даёт выживание легального танца, но jit_node ИНИЦИАЛИЗИРОВАН сам на себя → нет примитива unlink. Нужны сырые байты на +0x38/+0x3c:
*(N+4)=P с P=страница шеллкода юзерленда (нет PAN!) —
кандидаты: const fops в .rodata (DEBUG_RODATA) → цель не-const
fn ptr в .data, или голова списка binfmt formats, или sysctl proc_handler
(проверить записываемость таблицы). запасной вариант: modprobe_path через цепочку
байтовых записей (значения должны быть записываемыми адресами — использовать цели в форме указателей)poc/stage3.c):
kern_table[pid_max].proc_handler @ 0xc1113f40 (записываемый
.data, проверено через сканирование строк-указателей + handler == proc_dointvec_minmax)b +8; W2 пишет N по P = поле handler)read /proc/sys/kernel/pid_max
(читается из shell); выполняется в собственном контексте задачи → creds применяются к намinotify_handle_event делает kmalloc name_len+0x1d,
байты имени (полностью контролируемые, ограничение без NUL/слэша) на event+0x1c;
name_len=60 → kmalloc-96; в очереди → удерживается; 4 экземпляра → 4 события на
rename; SELinux-OK из shell. Поддельный переработан без NUL: cpu_alloc
указывает на S (nents@S+8 = 0 → та же семантика, что NULL)| вариант |
|---|
Рабочая гипотеза: гонка штормового мусора — между освобождением слота destroy-воркером (в середине шторма) и kill-child/тишиной остаточная активность реклейма занимает единственный свободный слот slab'а жертвы неполезными байтами. Спрей регионов (этап 2) побеждает, потому что аллоцирует непрерывно ВО ВРЕМЯ шторма; rename не могут.
iso): идентичный тайминг, хвост с
commit-0 РЕГИОНАМИ + оракул переиспользования пула этапа 2 → ПОПАДАНИЕ ОРАКУЛА
→ тайминг/достижимость В ПОРЯДКЕ; проблема в событияхcurrent->mm принадлежит потоку ядра → элегантный
дизайн "направить указатели поддельного в наш собственный userspace mmap" (нет PAN!)
СБОИТ недетерминированно. 5/5 крашей с иначе идеальным поддельным.K=*(S+0x38) читается, *(K+0x1429c)==0 в рантайме
(пропускает mm-атомики), K+0x141c8 записывается, D=*(K+4) → D+0x538
записывается, nents *(S+8) предпочтительно 0. 9 офлайн S-кандидатов были
провалидированы против байтов ФАЙЛА — дрейф рантайма (инициализация xfrm/tracepoint)
делает их непроверенными. Неверная цепочка = краш = перезагрузка (~3 мин цикл).A. Поддельный physmap-спрей (ret2dir, классический arm32 без PAN): распылить ~450MB пользовательских страниц, каждая содержит поддельный паттерн, запечённый под ОДИН угаданный адрес G (G&0xfff = 0x141 для байтов имени без NUL; S=G; K=G-0x141b4 так что K+4 попадает в страницу; K+0x141c8/+0x1429c → G+0x10/+0xd4 в странице; D=G+0x300; случайные sub-0 stores попадают в случайную отображённую RAM - безвредно при nents=0). Спрей служит также давлением вытеснения (грязный anon = невытесняемый → нужно только ~100-200MB дополнительно). Шансы ≈ 45% (попадание в страницу) × ~50% (чужое слово K+0x1429c равно нулю... если K+0x1429c удерживается в странице по раскладке выше, шансы = только попадание в страницу). Промах = краш = перезагрузка, повтор. B. Перебор 9 статических S-кандидатов (xfrm 0xc118b7ec первым, рядом с tracepoint 0xc111cba4 вторым...): 1 перезагрузка на кандидата, сначала безвредная полезная нагрузка оракула, оружие при попадании. C. точный G на основе pagemap (мертво: PFN замаскированы) — не возвращаться.
/tmp/opencode/ksrc2/kernel/mediatek/mt8163/4.9/ (arch/arm вкл.
mustang.dtsi, mm/, fs/eventpoll.c, fs/notify) из ksrc/platform.tar.
Находки:physmap_retouch() после kill (возвращает все страницы спрея
обратно до trailing/deref)Регионы reclaim: 3/3. События: 0/~12 попыток, включая 28K эксклюзивных аллокаций с форой и корректным по построению фейком. Если события reclaim с p_hit(G)≈0.35, пять промахов pmap ≈ 11.6% — возможно, но теперь маловероятно (~10-15%). Либо события структурно не могут занять этот слот (причина неизвестна — тот же кэш, тот же контекст, тот же тайминг), либо наши догадки G систематически промахиваются (смещение на границе highmem, размещение аллокатора).
vmalloc=496M slub_max_order=0 slub_debug=O loglevel=8 initcall_debug
Регионы занимают слот жертвы 3/3; события 0/13. Тот же кэш (доказано на уровне исходников + дизасма), тот же контекст процесса, те же закреплённые cpus, тот же тайминг после kill, тысячи аллокаций с эксклюзивной форой. Механизм неизвестен. Оставшиеся подозреваемые: корреляция скорости/частоты аллокаций с ротацией частичного списка (ioctl регионов ~1мс друг от друга против переименований событий ~100µs друг от друга — противоположные направления?), или детали упорядочивания SLUB freelist при slub_max_order=0, которые благоприятствуют... неясно.
[+] uname.nodename="X?lhost" (was "localhost") <<< ORACLE HIT
**Полная цепочка сырых байтов работает на живом устройстве**: событие освобождает
слот освобождённой области → kbase_jit_free разыменовывает нашу подделку (S=страница physmap из
спрея kbm, G=0xc154b2a4) → unlink выполняет наши две записи.
Многократно проверено с безобидной полезной нагрузкой (запись nodename).
### Цепочка открытий за сессию
1. Страницы kbm были GFP_HIGHUSER → HIGHMEM, невидимы для physmap
(mali_kbase_mem_pool.c:164!) — исправлено переполнением zonelist: спрей 260 × 2MB
> highmem-free → излишек попадает в ZONE_NORMAL (physmap)
2. Первые попытки оружия падали: цель W1 N+4 была USER-страницей —
unlink выполняется в контексте kworker (нет mm) → fault. Исправлено запеканием
shellcode ring-0 В шаблон physmap по адресу page+0x600 (direct map RWX на
arm32 non-LPAE) — код, резидентный в ядре, ret2usr не нужен
3. Баг смещения ctl_table: proc_handler находится по entry+0x14, а не +0x18 (в
исходном сканировании было верно; моё определение было неверным) — писали в extra1
4. Обнаружена и откачена регрессия перегрузки: бюджет kid 20×100MB +
завершающие 10s ломали reclaim; рабочая конфигурация — 2 kid/200MB +
5s/+3200 завершающих (безобидное попадание 1/1 после отката)
5. **diag2: W2 → глобал &pid_max (0xc1114d7c) → чтение возвращает наше значение
(-1055861411 = 0xc110d55d как int32) — запись + обратное чтение ДОКАЗАНЫ**
### Оставшаяся загадка (один эксперимент до закрытия)
diag1 с КОРРЕКТНЫМ адресом обработчика (0xc1113f3c): W1 срабатывает (nodename
меняется), W2 должен был выполниться (следующая инструкция) — однако чтения pid_max
по-прежнему возвращают чистые значения → поле обработчика, которое мы пишем, не то,
через которое диспетчеризует inode. diag3 (в очереди; нужен hit boot): W2 →
ПОЛЕ entry->data (0xc1113f2c), указывающее на nodename — если чтение тогда
покажет nodename-байты-как-int, наша entry ЖИВА и лишь смещение обработчика
почему-то неверно; если не затронуто, inode использует теневую копию таблицы
и мы ищем живую.
### Реальность hit-rate
Монетка на каждый boot (~25-40%), кластеризовано; несколько безопасных промахов/падений
подряд — это норма. Примерно 1 из 3-4 boot'ов — попадание. Держите рабочую
конфигурацию ТОЧНО (2 kid, 5s завершающих, 260-регионный kbm, G=0xc154b2a4).
### TODO сессии 9
1. Завершить diag3 на hit boot (перезагружаться до "W1 FIRED")
2. Если entry жива: эмпирически перепроверить смещение обработчика (записать
адрес proc_dostring как обработчик через... N должен равняться полезному
значению — использовать unlink, чтобы вместо этого записать entry->data и совершить pivot: например,
data=selinux_enforcing-соседний...)
3. Если теневая таблица: найти живую — в kallsyms нет символов данных;
кандидаты: сканировать поведение /proc/sys, или найти вторую область ctl_table
через шаблон списка заголовков в .data (записи с шагом 0x20
с handler=proc_dointvec_minmax и maxlen=4 — перечислить ВСЕ и
diag-записать каждую)
4. Альтернативный класс целей, полностью избегающий диспетчеризации: указатели на функции
в .data, вызываемые из путей, достижимых из shell (нужен аудит)
5. Сам примитив записи ГОТОВ — теперь достаточно любой надёжной цели
по адресу ядра для root
## СЕССИЯ 9 — nf-WEAPON: reclaim+unlink+G-hit ДОКАЗАНЫ В ОРУЖИИ; остаётся только обход хуков
### Новый дизайн триггера (полностью заменяет путь через sysctl-обработчик)
Идея пользователя, перенесённая в память ядра: никакого SUID-файла (система
dm-verity RO; примитив пишет в RAM ядра). Вместо этого: **поддельный netfilter
hook**. В этом ядре есть Android-common бэкпорт НОВОГО
API nf_hook_entries, но реализованный как СВЯЗАННЫЙ СПИСОК (проверено
дизассемблированием nf_hook_slow + вспомогательной функции 0xc09897d4):
- `__ip_local_out(net, sk, skb)` загружает ЯЧЕЙКУ entries из
**[net+0x58c]**, сохраняет в state+0x1c, вызывает nf_hook_slow
- обход: `entry = *cell`; while(entry){ if (state->[4] <= entry->[0x20])
call entry->[0xc](entry->[0x14], skb, state); entry = entry->[0]; }
— то есть **fn@entry+0x0c, priv@entry+0x14, priority@entry+0x20,
next@entry+0x00**; state+4 = порог INT_MIN (проходит всегда)
- init_net = **0xc1104548** (CONFIG_NET_NS=n → sock_net() инлайнит
константу; 6678 ссылок movw/movt, чемпион гистограммы; перекрёстно подтверждено
собственным литералом nf_hook_slow). ЦЕЛЬ: **[init_net+0x58c] = 0xc1104ad4**
- Хук LOCAL_OUT выполняется в контексте процесса ОТПРАВИТЕЛЯ → наш hookfn с
commit_creds(prepare_kernel_cred(0)) рутует процесс, отправивший
пакет. Триггер = sendto(127.0.0.1:9) UDP.
### Раскладка режима nf (poc/stage3.c, режим `nf 200`)
- страницы шаблона kbm (относительно страницы, единый источник истины — у старого
оружия было ТРИ бага, теперь исправленных: proc_handler@+0x14, а не +0x18; цель W1
должна быть памятью ЯДРА (контекст kworker, нет mm); запечённый код по
page+0x600 против несоответствия entry G+0x600=page+0x8a4):
- +0x2ac/+0x2bc/+0x2c0/+0x2dc/+0x3a8: поддельная цепочка phy-alloc (без изменений)
- +0x600: hookfn nf_code (сохранение маркера + prepare_kernel_cred +
commit_creds + return NF_ACCEPT(1))
- +0x700: поддельная entry {next=0, fn=PM_PAGE+0x600, priv=0, prio=0x100}
- +0x740: ячейка → PM_PAGE+0x700
- полезная нагрузка: N = PM_PAGE+0x740 (0xc154b740), P = 0xc1104ad4
→ W1: *(cell+4)=P (попадает в нашу страницу), W2: *(init_net+0x58c)=cell
### САМОДИАГНОСТИРУЮЩАЯ инструментация (kbm_scan_for)
CPU-отображения kbm сохраняются; после освобождения мы сканируем каждую заспреенную
страницу на известное слово:
- scan(HOOKS_PTR_ADDR) по page+0x744 → доказывает reclaim + unlink + показывает,
какая физическая страница лежит в основе догадки G
- scan(0x600d600d) по page+0x7f0 → доказывает, что hookfn ВЫПОЛНИЛСЯ
(nf_code записывает этот маркер как своё 2-е действие)
### ТОТ САМЫЙ ЗАПУСК, КОТОРЫЙ ВАЖЕН (2026-09-11, поздняя сессия 9)```
[+] W1 CONFIRMED: region 135 page+0x185000 <- 0xc1104ad4 (reclaim + G hit!)
[+] nf trigger done, uid=2000 euid=2000
Полная цепочка оружия сработала на живом запуске: событие вернуло слот, подделка выполнилась, unlink выполнился, страница G-guess (0xc154b000) была действительно нашей (регион 135 страница 389). W2 = *(0xc1104ad4)=cell — это соседняя инструкция — она должна была выполниться. Однако UDP sendto не дал нам root → сбой находится ВНУТРИ пути хука: семантика walk, проводка [state+0x1c], сравнение приоритетов или поля записи. (Эксперимент с маркером для различения hookfn-ran-vs-not был добавлен; только crash-boots до конца сессии — чистых данных пока нет.)
pmap 200) — это проверка здравомыслия окружения (4/4 попаданий когда
тепло; crash-miss когда холодно)nf 200 на загрузках с задержкой стабилизации, пока не появится строка W1-CONFIRMED,
затем прочитать строку MARKER:
a. маркер ПРИСУТСТВУЕТ, uid!=0 → shellcode's creds не сработали (проверить
адреса prepare_kernel_cred/commit_creds; кодировки blx)
b. маркер ОТСУТСТВУЕТ → walk так и не вызвал нас: проверить с ВТОРЫМ
маркером, записанным... следующая диагностика: hookfn, который ТОЛЬКО пишет
маркер и возвращает 1 (без creds) — если всё ещё отсутствует:
ls -la; оставить файлы-маркерыpoc/stage3.c: pin/root/drain{,2,3,4,5}/iso — полное оружие +
оракул + изоляционный стенд, O_SYNC криминалистика точки крахаinit_net: 0xc1104548 — это __stack_chk_guard (гистограмма
movw/movt была загрязнена загрузками stack-canary — 2025 построил весь nf-план на
этом). Настоящий init_net = 0xc1185040 (подтверждено: ip_send_skb(net,...) вызывается
с этим литералом; ~994 ссылки все в сетевом стеке). Ячейка IPv4 LOCAL_OUT =
init_net+0x58c = 0xc11855cc.nf_iterate трактует [init_net+0x58c] как сам
указатель nf_hook_ops — он читает fn@+0xc, priv@+0x14, prio@+0x20
напрямую из этого значения. Поддельная запись сессии-9 жила по адресу
PM_PAGE+0x700, а ячейка указывала на неё (неиспользуемые поля next/
в ячейке → → краш). Поддельная запись ДОЛЖНА жить
(0xc154b740). С этим исправлением вызов хука
был доказан (режим = SAFE_FN обрабатывает все 200 sendto чисто).commit_creds(prepare_kernel_cred(0)) / override_creds(&init_cred) даёт
uid 0, но попадает в SID SELinux kernel, которому эта политика Fire OS
не позволяет писать в /data или /sys/fs/selinux/enforce (проверено: EACCES).
Настоящий SID init (7) также запрещён (тест с поддельным struct cred). enforcing_setup
является __init (освобождён → краш). atomic_sub в mark_reclaim требует nents=1, что
ломает ранний выход shrink_cpu_mapping.
Победа: процесс эксплойта сохраняет CPU-маппинги kbm, поэтому поддельная nf- запись может быть перезаписана на месте между пакетами:
selroot: entry = {fn=0xc01d503c (mov r3,#0;str r3,[r0];bx lr), priv=0xc1213ea8 (selinux_state.enforcing)}.*(enforcing)=0 → SELinux Permissive.kbm_cpu[reg]+off на {fn=commit_creds, priv=&init_cred}.commit_creds(&init_cred) в задаче отправителя → uid 0 с
permissive SELinux → пригодный root, всё за один reclaim, цепочка не нужна.[+] W1 CONFIRMED: region 67 page+0xad000 <- 0xc11855cc (reclaim + G hit!) [*] sendto 0 -> -1 errno=1 uid=0 euid=0 [+] nf trigger done, uid=0 euid=0 <<< HOOK RAN - commit_creds OK [+] ROOT: uid=0 euid=0 [+] setenforce write=1 [+] su copied bytes=236220
- `getenforce` → **Permissive**; приостановленный st3 — это `Uid: 0 0 0 0`,
`CapEff: 3fffffffff`.
- `/data` смонтирован с **nosuid**, поэтому setuid `su` не может работать. Крошечный
`rootshell` (отправка UDP → `commit_creds` на себе → `execl sh`) даёт
интерактивную root-оболочку: `uid=0(root) context=u:r:kernel:s0`.
- Root может читать/писать `/dev/block/by-name/*` (`dd if=boot ...` OK).
### Состояние кода Stage-3 (`poc/stage3.c`)
- режимы: `nf <mb> [probe|uprobe|oc|chain|fc <sid>|notrig|selroot]`
- `selroot` — рабочее оружие. Ключевые статики: `init_net=0xc1185040`,
`HOOKS_PTR_ADDR=0xc11855cc`, `ENFORCING_ADDR=0xc1213ea8`,
`ZERO_GADGET=0xc01d503c`, `commit_creds=0xc014993c`,
`init_cred=0xc1114f54`.
- Постэксплуатация — прямые системные вызовы (без `system()`); держите kctx живым
(`pause()`), чтобы избежать краха при разрушении.
### Оставшееся (Stage 4/5)
- Персистентность после перезагрузки (verity / boot image / recovery), поскольку
перехват cell + permissive SELinux существуют только во время выполнения, а повторный
запуск эксплойта требует ~1/3 шанса на возврат памяти.
- `su` потребуется домашний каталог без nosuid (`/system`) или лаунчер, который
перезапускает триггер.
## SESSION 11 — PERSISTENCE RECON (Track B + Track A) и передача RE
Целью был персистентный root. Были намечены два направления:
- **Track B**: отключить verified boot (dm-verity / SELinux), чтобы можно было пропатчить `/system`.
- **Track A**: перезапускать эксплойт при загрузке.
Оба сводятся к одному блокеру: **заставить LK считать устройство `eng`/`unlocked`.**
### Факты о verified-boot (точная сборка)
- Загрузчик заблокирован, AVB `green`, `ro.boot.unlocked_kernel=false`, `ro.boot.secure_cpu=1`,
`rpmb_state=1`. Bootrom пропатчен (нет BROM); preloader только через CMD short.
- `/system` монтируется **Android dm-verity из командной строки ядра, собранной lk**:
`root=/dev/dm-0 dm="system none ro,0 1 android-verity PARTUUID=b6404ef3-… "`,
`veritykeyid=id:f3530e18f64d11fc25eb2dd762979f078de990bf`, `androidboot.veritymode=eio`,
`skip_initramfs` (system-as-root). `dm-0` = verity-устройство с именем `system`; `dm-1` = `/vendor`.
- LK: Amazon **UFBL**, `ro.boot.lk_version=0x0006`, сборка `0db73c9-20231025_030009`;
preloader `pl_version=0x000a`, сборка `80c6fcb-20230523_065640`. `/dev/block/by-name/lk` = mmcblk0p5 (1 MB).
- Полный GPT (16 разделов, без `persist`/`seccfg`/`nvram`/`protect`/`para`):
`proinfo` p0, `PMT` p1, `kb` p2, `dkb` p3, `lk` p4, `tee1` p5, `tee2` p6, `metadata` p7,
`MISC` p8, `reserved` p9, `boot` p10, `recovery` p11, `system` p12, `vendor` p13,
`cache` p14, `userdata` p15. eMMC boot0 (1 MB) = preloader (магия `EMMC_BOOT`);
boot1 (4 MB) = хранилище IDME.
### Статические находки в LK (UFBL)
Заголовок `lk.img`: `88 16 88 58 | 00052974 | "LK"`; таблица векторов ARM по 0x200, остальное Thumb-2,
позиционно-независимый/перемещаемый (литеральные пулы используют `ldr+add pc`, поэтому наивный дизасм относительно базы не работает).
Релевантные строки (смещения в файле): `amzn_image_verify`, `amzn_verify_unlock`, `amzn_verify_code_internal`,
`unlock_code`, `unlock code error`, `unlock failed`, `$Common Kernel Signing Engineering CA0`,
`seccfg`, `para`, `ENV_v1`, `LK_ENV`, `Kfos_flags`/`Kdev_flags`/`Kusr_flags`/`Kunlock_code`/`Kunlock_version`,
`FOS_FLAGS_{NONE,ADB_ON,ADB_ROOT,CONSOLE_ON,RAMDUMP_ON,VERBOSITY_ON,ADB_AUTH_DISABLE,FORCE_DM_VERITY,DM_VERITY_OFF,BOOT_DEXOPT}`,
`[DM-VERITY] verify for system(root) is enabled`, `[DM-VERITY] verify off by fos_flags`,
`[DM-VERITY] disabled by fos_flags on eng devices or unlocked device`,
`[SELINUX] set to permissive mode by dev_flags`, `androidboot.prod=1|0`, `androidboot.unlocked_kernel=%s`.
**Вывод: LK привязывает эффекты безопасности `fos_flags`/`dev_flags` к eng/unlocked.**
### Хранилище IDME (eMMC **boot1**) — записываемое, персистентное, читается LK и Android
- Магия `beefdeed` + `"2.1\0"` + count(0x19=25) по 0x0; элементы с 0x10.
- Формат элемента: `char name[16]; u32 size; u32 type(=1); u32 magic(=0x124); u8 data[size] (pad4)`.
- Смещения элементов (исходные): `board_id@0x10 serial@0x3c mac_addr@0x68 mac_sec@0x94 bt_mac_addr@0xd0
bt_mfg@0xfc product_name@0x198 productid@0x1d4 productid2@0x210 region@0x24c bootmode@0x26c
postmode@0x28c bootcount@0x2ac manufacturing@0x2d0 unlock_code@0x4ec sensorcal@0x908 alscal@0x9c4
KB@0xa00 DKB@0x1e1c device_type_id@0x2238 dev_flags@0x2274 fos_flags@0x2298 usr_flags@0x22bc
wifi_mfg@0x22e0 unlock_version@0x26fc`. Значения — ASCII (флаги — **hex-строки**).
- Чтение во время выполнения: `/proc/idme/<name>` (только чтение). Значения последней загрузки кэшируются; запись в boot1 вступает в силу
при следующей загрузке. Путь записи требует снятия `/sys/block/mmcblk0boot1/force_ro` (root).
- **Подтверждено, что LK читает boot1**: изменение `serial` изменило `ro.boot.serialno` при следующей загрузке.
Но LK **обрезает serial до 16 байт** и проигнорировал `fos_flags=0x80`, `dev_flags=0xff`,
all-ones и т. д. — verity/selinux/`prod` без изменений. Значит, инъекция в cmdline через serial не работает.
### Потребители флагов IDME на стороне Android
- `/init.fosflags.sh` (сервис `fosflags`, `u:r:fosflags:s0`): `FOS_FLAGS_ADB_ON=0x1`,
`CONSOLE_ON=0x4`, `RAMDUMP_ON=0x8`, `VERBOSITY_ON=0x10`, `ADB_AUTH_DISABLE=0x20`,
`BOOT_DEXOPT=0x100`. Проверено: установка флагов вступает в силу (`sys.usb=adb`, `noadbauth=1`).
- **adbd** (нестрипленный ARM ET_EXEC; `.text` VA 0x8160 / файл 0x160; fileoff = VA-0x8000):
- `amzn_is_root_allowed` @0x2d5b8 = `amzn_is_dev_unlocked() && (fos_flags & 0x2)`
- `amzn_is_adb_auth_disable_allowed` @0x2d5e8 = `fos_flags & 0x20` (без гейта)
- `amzn_is_dev_unlocked` @0x2d5fc = `/proc/cmdline` содержит `androidboot.prod=0` **или**
`androidboot.unlocked_kernel=true`
- `fos_read_debug_flags` @0x2d724 читает `/proc/idme/<name>` и парсит **hex**
- `restart_root_service` @0xcb74 / `restart_unroot_service` @0xcc64
- строки: `amzn_fos: ADB: Auto-root succeeded`, `… eng_device=%d`, `… unlocked_kernel=%d`,
`adbd cannot run as root in production builds`, `ro.debuggable`
- `adb root` → "cannot run as root in production builds" (`ro.debuggable=0`) — значит, даже при
выполненном условии auto-root проверка AOSP prod блокирует путь команды.
### Почему root из Session-10 не сохраняется
- SELinux permissive + перехват cell + root существуют только во время выполнения.
- `/data/metrics` — это **vpartition**: `/system/bin/vpartition.sh` монтирует `/data/vp/metrics.img`
(ext4, non-nosuid/noexec) в `/data/metrics` при каждой загрузке; `su`, записанный туда, **не**
выживает перезагрузку. (Также поэтому setuid `su` давал uid 0, но **нулевые capabilities**.)
### Track A (повторный эксплойт при загрузке) — заблокирован
- Ни один триггер init `.rc` не выполняет контролируемый код (все импорты проверены; триггеры `persist.*` запускают только
`start` фиксированных сервисов; скрипты в `/system`/`/vendor`).
- Root-сервисы читают конфиги из `/data`, но никогда не выполняют их (`perfmonitord`, `amazonfiled`,
`vpartition.sh`, `kisd`, …).
- Единственный исполнитель при загрузке = **приложение**, но приостановленный след эксплойта — **VmRSS 534 MB**
(спрей `kbm`) → lmkd убивает его; плюс потерянный reclaim вызывает панику (`PANIC_ON_OOPS`) → bootloop.
- **adbd auto-root** существует, но привязан к cmdline, собранной LK (`prod=0`/`unlocked_kernel=true`).
### Вывод / следующая цель (выбрано: Track B RE)
Всё зависит от того, чтобы заставить LK сообщать `eng`/`unlocked`. В пределах досягаемости:
`androidboot.prod=1|0` и `androidboot.unlocked_kernel=false` устанавливаются LK. Реверс LK, чтобы найти:
1. где он читает `fos_flags`/`dev_flags`/`usr_flags` (элементы `K*`) и точный гейт;
2. определение `prod`/`unlocked` (элемент IDME? buildvariant? результат `amzn_verify_unlock`?);
3. `amzn_verify_unlock` (проверка RSA libtomcrypt) для обхода или слабого пути unlock_code/version;
4. хранилище `seccfg`/`para`/`ENV_v1`(LK_ENV) (не в каком-либо дампленном разделе — возможно, защищено tee);
5. preloader (`boot0`, `EMMC_BOOT`) на предмет бага.
Если что-либо из этого позволит установить eng/unlocked (персистентно, через boot1 или запись в сырой раздел), тогда
`FOS_FLAGS_DM_VERITY_OFF` отключит verity для system(root) и `/system` можно будет пропатчить персистентно.
### Артефакты (из этой сессии)
`/tmp/opencode/mustang-dumps/` (может быть очищено при перезагрузке хоста): `lk.img`, `boot1.img` (исходный),
`boot.img`, `MISC.img`, `metadata*.img`, `pmt.img`, `mbr.img`, `kb.img`, `dkb.img`, `reserved.img`,
`cache.img`, `boot0.img`, `boot1.img`, `adbd.bin`, `perfmonitord.bin`, `amazonfiled.bin`.
Вспомогательные скрипты: `tools/findinitnet.py`, `findgadget*.py`, `findstores.py`, `adbd_sym.py` (в /tmp);
в репозитории есть `run.sh`, `poc/stage3.c` (`selroot`), `poc/su.c`, `rootcmd.sh`.
### Полезные команды```
# IDME read
/data/metrics/su sh -p -c 'for f in fos_flags dev_flags usr_flags serial region device_type_id unlock_version; do echo -n "$f="; cat /proc/idme/$f; echo; done'
# write boot1 (root; su lives only until reboot -> re-run run.sh first)
/data/metrics/su sh -p -c 'echo 0 > /sys/block/mmcblk0boot1/force_ro; dd if=/data/local/tmp/boot1.img of=/dev/block/mmcblk0boot1 bs=4096 count=4; sync; echo 1 > /sys/block/mmcblk0boot1/force_ro'
# dump a partition to host
adb exec-out '/data/metrics/su dd if=/dev/block/by-name/lk bs=4096 2>/dev/null' > lk.img
Цель: заставить LK рассматривать устройство как eng/unlocked, или найти баг в preloader/LK,
чтобы можно было постоянно отключить verity/SELinux. Результат: реверс соответствующего
пути кода LK от начала до конца; переключение недостижимо через доступные хранилища.
Ни одно устройство не было окирпичено; единственный эксперимент с boot1 был откачен до исходного состояния.
lk.img начинается с крошечной заглушки ARM (файл 0x200). Релокатор по адресу 0x224
копирует из 0x200 в литеральный адрес назначения и выполняет переход на литеральный адрес входа:
Таким образом, адрес во время выполнения = 0xFF400000 + смещение в файле для смещений >= 0x200.
Всё после заглушки — это Thumb-2, позиционно-независимый код. Строки строятся
с помощью ldr rT,[pc,#imm] (смещение T1 = imm8*4; смещение ldr.w = imm12) с последующим
add rT, pc; цель — (add+4) + *pool. Надёжный сканер, который выдерживает
заглушку ARM и литеральные пулы, был добавлен как tools/lk_xref.py (обрабатывает 16- и
32-битные формы, сканирует каждые 2 байта). Все смещения ниже — это смещения в файле;
добавьте 0xFF400000 для адресов во время выполнения.
0x20b4 читает элемент IDME unlock_code (0x400 байт, все нули на этом
устройстве) и запускает amzn_verify_unlock (0x222c -> 0x20f0). Эта функция задействует
libtomcrypt (десятки путей /features/libtomcrypt/src/pk/asn1/der/... и
проверку RSA), и образ содержит встроенный сертификатный материал:
Sunnyvale / Amazon Lab126 / "$Common Kernel Signing Engineering CA0" по адресу
0x317d9+, а также диагностические сообщения
Image FAILED AUTHENTICATION on PRODUCTION device (0x3166e),
Authentication failed on engineering device with production certificate (0x316a0),
Image FAILED AUTHENTICATION on ENGINEERING device (0x31703),
Image AUTHENTICATED with PRODUCTION certificate (0x31736).
Нет никакого сокращённого пути для пустого кода / длины / версии: , следовательно
(подтверждено в ). Переключение
или требует либо действительного
подписанного Amazon (закрытый ключ недоступен), либо бага выполнения кода в
верификаторе. Ничего эксплуатируемого (границы/размер) не было найдено статически в
0x20b4/0x222c/0x20f0. =>
Флаги безопасности читаются через геттер по адресу 0x57c. Эмпирический тест:```
dd if=/dev/block/mmcblk0boot1 ... ; reboot /proc/idme/fos_flags -> 00000080 (persisted, Android sees it) ro.boot.veritymode -> eio (unchanged!) root=/dev/dm-0 dm="system none ro,0 1 android-verity PARTUUID=..." (unchanged) androidboot.prod=1 / secure_cpu=1 / buildvariant=user (unchanged)
`fos_flags=0x80` — это `FOS_FLAGS_DM_VERITY_OFF`; декодированный шлюз отключил бы
verity, **если бы** геттер его вернул. Он этого не сделал. Шлюз является рабочим, а не
мёртвым кодом: его одноразовый кэшированный sentinel равен `-1` в образе
(`*(u32*)0x50c74 == 0xffffffff`), поэтому функция действительно выполнила
путь `check_flag("fos_flags",0x80)` и получила 0. Следовательно, геттер (по крайней
мере на момент защиты verity) **не** читает элементы IDME из boot1.
Другое возможное хранилище — это **LK env**, загружаемое из раздела, буквально
названного `"para"` (загрузчик 0x12fd4, магия `ENV_v1`, контрольная сумма @0x3ffc). Собственная
таблица разделов LK (0x4fcc0..0x50340) перечисляет preloader/proinfo/nvram/protect1/
protect2/persist/seccfg/secro/**para**/logo/custom/expdb/tee1/tee2/metadata/
system/cache/userdata — но фактический GPT планшета имеет **только 16 записей**, все
типа `af3dc60f838472478e793d69d8477de4`:```
#0 proinfo 0x400 #1 PMT 0x1c00 #2 kb 0x4000 #3 dkb 0x4800
#4 lk 0x5000 #5 tee1 0x5800 #6 tee2 0x8000 #7 metadata 0xa800
#8 MISC 0x1e400 #9 reserved 0x1e800 #10 boot 0x22800 #11 recovery 0x2a800
#12 system 0x34800 #13 vendor 0x644000 #14 cache 0x6b4800 #15 userdata 0x7ae800
На этом продукте нет разделов para, seccfg, nvram, protect или persist (а дампы PMT/pmt.img полностью нулевые). Поэтому окружение LK пусто, ключи Kfos_flags/Kdev_flags никогда не существуют, и все проверки fos_flags/dev_flags дают 0 — независимо от того, что содержат элементы IDME. Элементы IDME boot1 потребляются Android (/init.fosflags.sh, adbd, /proc/idme/*), но не защитными шлюзами LK.
unlocked_kernel требует подписанный Amazon unlock_code (RSA/libtomcrypt, встроенный CA). Не подделать офлайн; баг верификатора не найден. Жёсткая блокировка.DM_VERITY_OFF / selinux=permissive потребляются из окружения LK (para/ENV_v1), которого нет на этом GPT. IDME fos_flags эмпирически игнорируется LK (0x80 сохранился, verity остался eio). Жёсткая блокировка, если только не изменить таблицу разделов.fos_flags=0x80 лишь установил бы androidboot.veritymode=disabled и root= не dm-0; он не разблокировал бы, и SELinux всё ещё нуждался бы в dev_flags из того же отсутствующего окружения, чтобы перейти в permissive.para/ENV_v1: добавить запись GPT с именем para (первичный + резервный GPT должны быть обновлены) в свободном пространстве после userdata (userdata заканчивается на LBA 0x3a3dfde; диск = 30535680 секторов), затем создать env с fos_flags=0x80 и dev_flags=0x40 (контрольная сумма по +0x3ffc = побайтовая сумма по 0x3ffc). Это единственный оставшийся путь к verity-off. Риски: повреждение первичного/резервного GPT может превратить устройство в кирпич; и не доказано, что шлюз verity действительно читает para (только то, что это не boot1 IDME).boot0/EMMC_BOOT): не реверсился в этой сессии. Запись boot0 запрещена, пока не существует нетронутой копии и пути восстановления.tools/lk_xref.py — независимый от базы резолвер строковых xref в LK./tmp/opencode/mustang-dumps/lk.img, boot1.img (нетронутый), boot0.img, mbr.img (GPT), pmt.img (полностью нулевой)./tmp/opencode/s12/boot1_f80.img; устройство восстановлено до нетронутого boot1 (проверено /proc/idme/fos_flags -> 0)../run.sh)```./run.sh --no-build
/data/metrics/su /system/bin/sh -p -c 'cat /proc/cmdline'
for f in fos_flags dev_flags usr_flags unlock_version serial; do cat /proc/idme/$f; echo; done
## СЕССИЯ 13 — preloader всё-таки доступен (`1949:20ff` = MTK preloader, HID-транспорт)
В выключенном состоянии при подключении к USB планшет определяется как **`1949:20ff`**
(`Lab126`) — *не* Android и *не* `0e8d:0003` bootrom. Дескриптор:```
bInterfaceClass 3 (HID), iConfiguration "HID", iInterface "HID Interface"
HID report descriptor = 05 01 09 00 a1 01 c0 (empty collection!)
EP 0x81 IN interrupt 4 bytes, bInterval 4
EP 0x01 OUT interrupt 4 bytes, bInterval 4
iSerial = GCC0X90805310009 (the IDME serial)
Идентификация. 0x20FF указан как "MTK Preloader" в mtkclient
config/usb_ids.py (под MediaTek VID 0x0e8d: 0xe8d:{0x0003 Brom, 0x2000/0x2001/0x20ff/0x3000 Preloader}). Amazon сохранил PID прелоадера и
изменил VID на 0x1949, и представляет его как пару HID-эндпоинтов с фиктивным
дескриптором отчёта. Таким образом, это режим MediaTek preloader / USBDL, стадия
ниже LK — достигаемая здесь выключением питания + подключением, а не замыканием CMD.
Строки дескриптора "HID"/"HID Interface" отсутствуют в lk.img,
boot0.img, boot.img или других дампах, то есть режим создаётся
компонентом, который мы не дампировали (bootrom/TEE), или собирается во время выполнения.
Почему это важно. Прелоадер Amazon, используемый aftv2-tools, предоставляет
встроенные команды, не требующие Download-Agent, через этот самый байтовый поток:```
handshake : host A0 0A 50 05 -> dev 5F F5 AF FA
0xD1 read32 (addr, n_words) : echo cmd/addr/n, 00 00, nu32, 00 00
0xD4 write32(addr, words[]) : echo cmd/addr/n, 00 00, nu32, 00 00
`aftv2-tools/read_mmc.py` использует `read32`/`write32` для прямого доступа к контроллеру MSDC
(базовый адрес `0x11230000` на MT8173; проверьте для MT8163) и чтения/записи **сырых блоков eMMC**
без DA и, следовательно, без AVB/verity на пути. Если preloader mustang
принимает 0xD1/0xD4, это прямой путь к постоянной разблокировке (патч `boot` /
`lk`), независимо от кода разблокировки RSA и отсутствующего окружения LK.
### Добавленные инструменты (требуется root; сначала chmod на USB-узле)```
lsusb -d 1949:20ff # note Bus/Dev, e.g. Bus 001 Device 003
sudo chmod 666 /dev/bus/usb/001/003
# 1) does it answer the MTK handshake? (no DA, no flash access)
nix-shell -p python3Packages.pyusb --run \
'python3 tools/mtk_preloader_hid.py handshake'
# 2) read-only arbitrary memory read
nix-shell -p python3Packages.pyusb --run \
'python3 tools/mtk_preloader_hid.py read32 0x00100000 4'
tools/probe_preloader.py — минимальный пробник только для рукопожатия;
tools/mtk_preloader_hid.py — полный транспорт (handshake/read32/
write32; write32 защищён и не должен использоваться до подтверждения
карты регистров eMMC).
read_mmc), затем пропатчить boot.img/lk из preloader и
перезагрузиться.amzn_verify_unlock или шлюза окружения LK.pi_blocked_onfutex.c:1975 передаёт this->rt_waiter,
объявленный в futex_wait_requeue_pi в futex.c:2880) → ожидающий штампует свой собственный освобождённый фрейм
через arm32 select (nr 142) fd_setsDEBUG_RT_MUTEXES выключен
→ компактный 48-байтовый rt_mutex_waiter (tree_entry@0, pi_tree_entry@0xc, task@0x18,
lock@0x1c, prio@0x20, deadline@0x28)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)selrootselinux_state.enforcingcommit_creds(&init_cred)uid=0jcnr_extresinfo->gpu_alloc_addr (GPU VA, который вы должны
предварительно выделить и передать)| вытесняемый объект | давление | результат |
|---|
| нет | 900 МБ | выжило |
| нет | 1300 МБ | паника (системный баг lowmem — не связано) |
| обычный регион + DONT_NEED | 700 МБ | выжило |
| JIT-регион + DONT_NEED | 700 МБ | паника в пути reclaim |
kernel/config-* — дамп /proc/config.gz с работающего устройстваksrc/ — исходники Amazon OSS (platform.tar + распакованное дерево midgard-r26p0)/tmp/opencode/mustang_ota.bin (sha256 6068515a… совпадает с fireos-archive)
и 2.2 ГБ tarball исходников ядра хранятся в ~/Desktop/amazon-mustang/ksrc/kernel/mediatek/mt8163/4.9/drivers/misc/mediatek/gpu/gpu_mali/mali_midgard/midgard-r26p0/| результат |
|---|
| параллельные спрейеры rename во время шторма | rename застревают (journal/GFP_NOFS) → 128 всего → мусорное разыменование |
| предварительный слив 12K событий + давление + небольшой хвост | краш на разыменовании |
| + kill-child-при-вытеснении (опрос 10мс) | краш на разыменовании |
| + жизненный цикл, закреплённый на cpu0 (drain3) | краш на разыменовании |
| ступенчатое давление (drain4 v1) | дочерние процессы освободили память при выходе → нет вытеснения (провалидирован легальный путь) |
| запуск | результат |
|---|
| pmap G=c2a412a4 400MB | краш на deref |
| pmap G=c2f4b2a4 480MB | краш; +0 переименований после kill (480MB душит fs) |
| iso2 (спрей + регионы + оракул) | ПОПАДАНИЕ В РЕГИОН — спрей не ломает reclaim |
| mix v1 (конкурентные events+regions) | краш; смешанный (крутящиеся потоки событий) |
| pmap G=c2a7d2a4 350MB + retouch | краш; +4452 переименований OK |
| mix2 (последовательно: 2с events ЗАТЕМ regions) | краш; +7126 переименований (28K аллокаций событий), 2715 регионов |
fnfn=0PM_PAGE+NF_CELL_OFFprobekernel_x_end: arch/arm/mm/mmu.c
map_lowmem() отображает lowram ниже текста ядра как MT_MEMORY_RWX, но всё
выше kernel_x_end как MT_MEMORY_RW → PMD_SECT_XN (строка 509). Зашитый
shellcode по адресу 0xc154b600 вызывает prefetch-abort. Payload должен быть
указателем на реальную функцию ядра, а не кодом в physmap.| литерал (смещение в файле) | значение | значение |
|---|
| 0x270 | 0xFF4002F8 | str r4,[r6] scratch |
| 0x274 | 0xFF40027C | адрес назначения (base+0x27C) |
| 0x278 | 0xFF54A440 | конец копирования (вкл. BSS) |
| 0x27C | 0xFF400484 | точка входа |
| смещение | функция |
|---|
0xdf7c | is_secure_or_prod() -> byte[ [[g]+0 ] + 0x163 ]; g = глобальная переменная @0x52838. 1 на этом устройстве. |
0x20b4 | verify_stored_unlock() = memset(buf,0,0x100); чтение IDME/env unlock_code (0x100) через 0x57c; bl 0x222c; возврат (verify==0). |
0x222c / 0x20f0 | amzn_verify_unlock(code,len) — проверка libtomcrypt RSA/PKCS#1 (см. ниже). |
0xda3e | is_unlocked() = is_secure_or_prod() && verify_stored_unlock(). |
0x29a28 | is_verity_disabled() = (fos_flags & 0x80) && !(is_secure_or_prod() && verify_stored_unlock()); кэшируется в глобальной переменной @0x50c74. |
0x29974 | Построитель cmdline для SELinux: dev_flags & 0x20 -> androidboot.selinux=enforce, dev_flags & 0x40 -> ...=permissive (каждый управляется byte[+0x162]). |
0x118xx/0x11bxx | построитель cmdline ядра (unlocked_kernel, prod=1/0, verifiedbootstate, rpmb_state, secure_cpu, версии, root=). |
0x27af8 | Шлюз UART: fos_flags & 0x4 -> printk.disable_uart=0, иначе =1. |
0x12fd4 | Загрузчик окружения LK: раздел "para", 0x4000 байт, магия ENV_v1, контрольная сумма = сумма байтов по 0x3ffc, сравниваемая со словом @0x3ffc. |
0x1efd0 | поиск раздела по имени (используется для "para", "boot", ...). |
0x57c | диспетчер геттеров через слот обратного вызова @0x58218; слоты @0x58200..0x5821c регистрируются из таблицы по адресу 0x5a8-0x734. |
0x2a19c | fastboot oem unlock: bl 0x222c(code,len); при успехе записывает unlock_code (0x100) через 0x408. |
verify(zeros) != 0unlocked_kernel=false/proc/cmdlineandroidboot.unlocked_kernelandroidboot.produnlock_code