CVE-2026-43499 · Honor WIN RT (AAK-AN00) временный Root — исследовательские заметки

(всё написано deepseek, я сам ничего не понимаю) (провозился ещё несколько дней, прогресс нулевой, сдался) (на данный момент root получить можно, но крайне нестабильно: после root пропадает сеть, при отключении кабеля — перезагрузка) (все выводы в этом репозитории применимы только к Honor WIN RT, уязвимости CVE-2026-43499, ядру 6.6.118-android15-8-gf17133276a57-abogki518694926-4k; не распространяйте выводы на временный root — временный root может работать непрерывно и относительно стабильно)

Загрузчик устройства навсегда заблокирован (ro.oem_unlock.supported пуст), нет fastboot, нет постоянного su, нет Magisk. Единственный оставшийся путь — уязвимость ядра. Этот репозиторий фиксирует полный процесс от «можно ли вообще пробить» до «насколько стабильно после пробития».

Характер: временный root, после перезагрузки перестаёт действовать.

---

Отказ от ответственности

Этот репозиторий фиксирует процесс исследования безопасности на собственном устройстве автора с целью понять причины возникновения гонки PI в ядре и границы её стабильности.

• Не содержит ни одного exploit-бинарника или готового к запуску полезного payload — payload и фреймворк взяты из публичных upstream-проектов; репозиторий только ссылается, но не распространяет их.
• Не предоставляет инструкций по обходу защитных механизмов конкретных производителей и не поощряет использование на неавторизованных устройствах.
• Смещения и адреса символов в репозитории действительны только для той единственной сборки ядра, что указана в этой статье; при смене ядра всё становится недействительным.
• Соответствующие дефекты уже исправлены в upstream (см. ниже). Долгосрочная ценность этой статьи — в «самой этой записи» — реальный разбор эксплуатации гонки в неидеальных условиях, включая все её неприятные побочные эффекты.

---

0. Вывод в одну строку

Единственный пройденный путь:

CVE-2026-43499 (гонка futex PI, write-what-where) + несущая rt_sigreturn
  → инъекция через LD_PRELOAD в процесс домена shell
  → двухэтапно: сначала перевести SELinux в Permissive, затем заменить task->real_cred / cred на init_cred
  → uid=0(root) context=u:r:kernel:s0, и внедрить демон su

Но по-настоящему стоит записать не «как получить root» — а то, что происходит после его получения.

Получен не стабильный root, а «состояние, готовое взорваться в любой момент».

Примитив записи exploit'а вставляет поддельный rt_mutex_waiter в реальную цепочку futex PI, а носителем этого waiter'а служит стек ядра / страницы спрея, которые будут переиспользованы последующими системными вызовами. Поэтому с момента закрепления root любое системное планирование или изменение приоритета может задеть его и вызвать прямой kernel panic с перезагрузкой. Это не баг, а неотъемлемая цена данного метода эксплуатации — подробности в docs/03.

---

1. Границы применимости (при несоответствии весь план недействителен)

Пункт	Значение	Пояснение
Модель	Honor WIN RT, модель AAK-AN00	Маркетинговое название «Honor WIN RT»
SoC	Snapdragon 8 Elite SM8750-AB	С Honor WIN (AAP-AN00, SM8850-AC) прошивки несовместимы
Система	Android 16 / MagicOS 10	—
Ядро	6.6.118-android15-8-gf17133276a57-abogki518694926-4k	★ жёсткое условие, посимвольное совпадение
Конфигурация ядра	4K pages, VA_BITS=39, CONFIG_FUTEX_PI=y	Предпосылка геометрии несущей
Пакет прошивки	.170	.160 / .175 не проверялись
Загрузчик	Навсегда заблокирован	Нет fastboot / нет постоянного su

Почему необходимо жёстко привязываться к версии ядра: дефект исправлен в 6.6.140, на этом устройстве 6.6.118 < 6.6.140, поэтому он ещё присутствует; к тому же все адреса символов ядра в exploit'е и «геометрия несущей» привязаны именно к этой сборке; после смены ядра таблица смещений сразу становится недействительной, и откат, как правило, невозможен.

---

2. Общая картина пути повышения привилегий

┌─ Материалы ───────────────────────────────────────────┐
│ boot.img + xbl_config.elf (извлечены из прошивки устройства) │
│        ↓ разрешение символов                            │
│ target.h (адреса символов ядра, сверены с kallsyms побайтово) │
│        ↓ сборка                                         │
│ preload.so ──► на устройстве /data/local/tmp/*.so       │
└────────────────────────────────────────────────────────┘
                 ↓  инъекция LD_PRELOAD
     ┌──────────── двухэтапно (обязательно два независимых процесса) ────────────┐
     │ Этап A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ Этап B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred (выполняется процессом-"предустановленным писателем") │
     │         → setresuid(0,0,0) нормализация                     │
     │         → внедрение встроенного su + daemon                  │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Три вещи, которые обязательно нужно сделать правильно (иначе зависание или прямой panic):

1. Железный порядок: сначала real_cred, потом cred. Обратный порядок мгновенно даёт полные права и выход потоков из-под контроля.
2. Между двумя «ударами» неизбежно существует переходное состояние cred ≠ real_cred. В этот момент любой sched_setaffinity даст EPERM → весь цикл зависнет. Правильное решение — форкнуть процесс-«предустановленный писатель» ещё до первого удара (с чистыми учётными данными); родительский процесс делает первый удар, писатель — второй, и никто не выполняет syscall в переходном состоянии.
3. Модель адресов не зависит от KASLR. Вся эксплуатация идёт только через псевдоним линейного отображения alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), стабильный между перезагрузками; реальная ценность так называемой «фазы slide» — самопроверка примитива записи, а не обход KASLR.

Upstream-фреймворк: Linuxoid-cn/CVE-2026-43499-Poc-Analysis. Обратите внимание: это не GhostLock — GhostLock идёт по пути pselect и не соответствует геометрии точки падения waiter'а в этой сборке, подробности в docs/06.

---

3. Содержание