Что было сделано

1. Анализ исходников → извлечение смещений структур

Извлечено из arch/arm64/include/asm/memory.h + include/linux/fs.h + android/abi_gki_aarch64.xml:

• Раскладка памяти: KIMAGE_TEXT_BASE = 0xffffffc008000000, VA_BITS=39, DIRECT_MAP=256GB
• task_struct: 36864 бит, полностью разобран (ABI XML layout-offset-in-bits)
• file_operations: нет iopoll (android13 GKI), IOCTL=0x48, open=0x68
• cred: atomic_t usage = 4 байта, uid=0x04
• struct page: 64 байта, slab_cache=0x18

Ключевое открытие: исходники — android15 GKI, устройство — android13 GKI — смещения task_struct отличаются на 0x40~0x88 байт, нельзя слепо копировать из исходников.

2. Распаковка прошивки → извлечение символов

Символы извлечены из двух версий прошивки (15.2.7.6 / 15.2.10.2) — один и тот же символ отличается между версиями на 10KB~200KB, обязательно использовать правильную версию.

3. Проверка дизассемблированием → capstone подтвердил ключевые смещения

Это подтвердило, что раскладка task_struct относится к ветке android15, а не к android13 от frankel.

4. Компиляция → прошла успешно

NDK r29, make PROJECT=android_15.0_kernel_MT6985 → preload.so (150KB).

5. Запуск → многократные краши

Инструкция краша (capstone):

Почему провалилось

Корневая причина 1: KernelSnitch ненадёжен на MTK

KernelSnitch — точка входа всего эксплойта — он утекает адрес mm_struct через тайминговые различия в futex-хеш-таблицах:

1. Обнаружение коллизий — успешно: при низком пороге найдено 5 коллизий
2. Подбор (bruteforce) почти всегда проваливается — ключевая проблема:

На устройствах Pixel нет KASAN_HW_TAGS, этот механизм работает. На MTK — нет.

Корневая причина 2: CONFIG_PANIC_ON_OOPS — убийца

Плюс bootloader заблокирован (flash.locked=1) → нельзя прошить кастомное ядро, чтобы убрать эту опцию.

Корневая причина 3: Дрейф версий ядра

Хотя мажорные номера версий совпадают (5.15.178), ветки GKI разные (android13 vs android15), раскладка ключевых структур (task_struct/cred и др.) не совпадает. Многократное переключение между наборами смещений frankel/android15, в итоге зафиксировано только через дизассемблирование.

Испробованные корректировки (все безрезультатны)

Текущее состояние target.h

В exploit/targets/android_15.0_kernel_MT6985/target.h:

Ассемблер собирается, код запускается, проигрыш на последнем километре.

Если хотите продолжить

Обязательные условия (все необходимы)

1. Убрать CONFIG_PANIC_ON_OOPS — либо прошить кастомное ядро (нужна разблокировка bootloader), либо найти устройство MT6985, где эта опция отключена по умолчанию
2. Решить проблему KernelSnitch — нужна калибровка таймингов кэша для MTK Dimensity 9200, либо полностью заменить KernelSnitch на другой способ утечки mm_struct в эксплойте

Возможные альтернативные пути

• /proc/self/pagemap — на этом устройстве ограничен (возвращает нули)
• Специфичные для MTK отладочные интерфейсы (/proc/mtk_*) — существуют, но требуют дальнейшего анализа
• Уязвимости ioctl в драйверах камеры/GPU MTK — более простой путь повышения привилегий
• Ждать адаптации MTK-варианта сообществом

Остаточная ценность этого репозитория

• symbols/kallsyms_PD2241_15.2.10.2.txt — полная таблица символов 15.2.10.2, можно использовать напрямую
• device_config.txt — фактическая конфигурация ядра устройства, видно, что изменил vendor
• exploit/targets/android_15.0_kernel_MT6985/target.h — смещения структур проверены
• scripts/server_compile.py — автоматизированная компиляция, после изменения параметров пересборка быстрая

Чек-лист граблей (чтобы будущие исследователи их избегали)

1. Распаковка файлов в Windows: tar -xf может не справиться с большими zip, используйте Python zipfile или распаковывайте вручную
2. Конфликт версий protobuf в payload_dumper: сгенерированный update_metadata_pb2.py требует protobuf 5.x, нужно вручную удалить строку импорта runtime_version
3. Запуск ./preload.so напрямую вызывает segfault: обязательно использовать /system/bin/linker64 /data/local/tmp/preload.so
4. ABI XML точнее исходников: layout-offset-in-bits вычисляется компилятором, в 100 раз точнее ручного подсчёта 5000 байт
5. Ветка GKI влияет на раскладку: task_struct отличается между android13/14/15, нельзя копировать смещения между ветками
6. Разные версии прошивки = разные смещения символов: 15.2.7.6 и 15.2.10.2 отличаются на 10KB~200KB
7. vivo vendor добавил множество OEM-полей: CONFIG_ANDROID_VENDOR_OEM_DATA=y, CONFIG_SCHED_INFO=y, CONFIG_RSC_* → отклонение от стандартного GKI
8. Цепочка инструментов извлечения символов: boot.img → kernel.bin → LZ4 распаковка → Image → kallsyms-finder → таблица символов

Хронология

2026-07-29, выжил, чтобы рассказать эту историю

Продолжение от 2026-07-31: проверка и исправления после получения исходников

После получения android_15.0_kernel_MT6985.tar.gz (дерево исходников 5.15.178 + ABI XML) проведена полная перекрёстная проверка, подробности в VERIFICATION.md. Кратко:

1. MT6985 = Dimensity 9200 (MT6989 — это 9300), выше исправлено.
2. Смещения символов 23/23 верны (проверка kallsyms), смещения task_struct / cred / waiter / page / pipe / configfs полностью совпадают с ABI дерева исходников.
3. Смещения FOPS были ошибочными: исходные значения скопированы из frankel (android13 GKI, без iopoll, ioctl=0x48); но раскладка task_struct устройства (pi_blocked_on=0x8b0, подтверждено дизассемблированием в рантайме) совпадает с этим деревом исходников, значит file_operations того же ядра должен иметь iopoll@0x30, ioctl=0x50, open=0x70 и т.д. — target.h исправлен, плюс используется встроенная в эксплойт самопроверка leak_kernel_base() на реальном устройстве как страховка.
4. Патч совместимости KernelSnitch с MTK (patches/kernelsnitch_mtk_fixes.patch):
   • размер пользовательской futex-хеш-таблицы приведён в соответствие с ядерной (possible CPU + 2, округление до степени двойки), чтобы избежать гарантированного провала bruteforce при possible≠online;
   • в перебор MTE-тегов добавлен 0xf (untagged), а KSNITCH_MTE_ENABLED=1 теперь реально работает (в исходном util.c mte=0 было захардкожено);
   • не влияет на non-MTK цели.
5. Точка краша rt_mutex_adjust_prio_chain+0x1b0 находится на этапе pselect/pi-цепочки, раньше самопроверки FOPS; после указанных исправлений стоит повторить проверку на устройстве.

Тест на реальном устройстве 2026-07-31: KernelSnitch заработал, этап slide — по-прежнему стена

Устройство (PD2241, compiler251203103903), 8+ раундов реального тестирования:

• KernelSnitch исправлен и проверен: MM_STRUCT_SZ=0x400 (исходные 0x500 приводили к смещению сетки сканирования и только ложным срабатываниям) + перебор MTE-тегов 0..15 (тег указателя mm на устройстве меняется) + untag поддельных адресов. Теперь реальный mm_struct находится стабильно.
• Каждый раунд по-прежнему крашится на rt_mutex_adjust_prio_chain+0x1b0: тайминговая гонка pselect/pi-цепочки (поддельный waiter не попадает в правильное смещение в стеке ядра). Планировщик vivo RSC изменил путь futex/pi, что, возможно, в корне ломает эту гонку. Выравнивание slide-стека вынесено в переменную окружения SLIDE_SHIFT, полное сканирование не завершено.
• Этапы FOPS/pipe/cred ещё не достигнуты, проверка на реальном устройстве будет продолжена.

Итоговое решение: откат к платной разблокировке bootloader (больше не полагаемся на этот путь).