実施した作業

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 bits、完全解析 (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. ファームウェア展開 → シンボル抽出

2 つのファームウェアバージョン (15.2.7.6 / 15.2.10.2) からシンボルを抽出 — 同じシンボルでもバージョン間で 10KB〜200KB の差があり、正しいバージョンを使用する必要がある。

3. 逆アセンブル検証 → capstone で重要オフセットを確認

これにより task_struct レイアウトが frankel の android13 ではなく android15 ブランチであることが確認された。

4. コンパイル → 成功

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

5. 実行 → 繰り返しクラッシュ

クラッシュ命令 (capstone):

失敗の理由

根本原因 1: KernelSnitch が MTK で信頼性が低い

KernelSnitch は exploit 全体の入口 — futex ハッシュバケットのタイミング差で mm_struct アドレスをリークする：

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 の 2 セットのオフセット間で何度も切り替え、最終的に逆アセンブルで確定した。

試した調整 (全て効果なし)

target.h の現状

exploit/targets/android_15.0_kernel_MT6985/target.h 内：

アセンブルは通る、実行もできる、最後の 1 キロメートルで負けた。

続行する場合

必要条件 (全て必須)

1. CONFIG_PANIC_ON_OOPS を無効化 — カスタムカーネルをフラッシュするか (bootloader のロック解除が必要)、デフォルトでこのオプションが無効な MT6985 デバイスを見つける
2. KernelSnitch の解決 — MTK Dimensity 9200 のキャッシュタイミング較正が必要、または exploit 内で KernelSnitch を完全に置き換えて別の mm_struct リーク方式を使用

考えられる代替アプローチ

• /proc/self/pagemap — 本デバイスでは制限済み (全ゼロを返す)
• MTK 固有のデバッグインターフェース (/proc/mtk_*) — 存在するがさらなる分析が必要
• MTK カメラ/GPU ドライバの ioctl 脆弱性 — より簡単な権限昇格パス
• コミュニティによる 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. payload_dumper の protobuf バージョン競合: 生成された 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 はコンパイラが計算したもので、5000 バイトを手動で数えるより 100 倍正確
5. GKI ブランチがレイアウトに影響: android13/14/15 の task_struct は異なるため、ブランチ間でオフセットをコピーできない
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 = 天玑 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 を修正し、exploit 内蔵の leak_kernel_base() による実機自己検証をフォールバックとして利用。
4. KernelSnitch の MTK 互換性パッチ（patches/kernelsnitch_mtk_fixes.patch）：
   • ユーザー空間の futex ハッシュテーブルサイズをカーネルと一致させる（possible CPU + 2 の 2 のべき乗に切り上げ）、 possible≠online の場合に bruteforce が必然的に失敗する問題を回避；
   • MTE tag 走査に 0xf（untagged）を追加し、KSNITCH_MTE_ENABLED=1 を実際に 有効化（元の util.c は mte=0 をハードコード）；
   • 非 MTK target には影響なし。
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 tag 0..15 走査（デバイスの mm ポインタ tag は変化する）+ 偽装アドレス untag。現在は実際の mm_struct を安定して発見可能。
• 各ラウンドで依然として rt_mutex_adjust_prio_chain+0x1b0 でクラッシュ：pselect/pi チェーンの タイミング競合（偽装 waiter がカーネルスタックの正しいオフセットに配置できない）。vivo RSC スケジューラが futex/pi パスを 変更しており、この race を根本的に破壊している可能性がある。slide スタックアライメントは SLIDE_SHIFT 環境変数として パラメータ化済みだが、スキャンは未完了。
• FOPS/pipe/cred 段階には未到達、実機検証は継続中。

最終選択：有料で bootloader のロック解除を依頼（本パスに依存しない）。