做了哪些事

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. 固件解包 → 提取符号

从两版固件 (15.2.7.6 / 15.2.10.2) 中提取符号——同一个符号两版之间差了 10KB~200KB，必须用对版本。

3. 反汇编验证 → capstone 确认关键偏移

这确认了 task_struct 布局是 android15 分支，不是 frankel 的 android13。

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 两套偏移之间切换，最终靠反汇编才锁定。

尝试过的调整 (全部没用)

target.h 现状

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

汇编能过, 跑得起来, 输在最后一公里。

如果你要继续

必要条件 (缺一不可)

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 分支影响 layout: android13/14/15 的 task_struct 不同, 不能跨分支复制 offset
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, lived to tell the tale

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 的幂取整）， 避免 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（不再依赖本路径）。