内核漏洞与临时 Root#

一开始我认为这套方案可能利用了 MediaTek Download Agent 一类的底层漏洞，但在直接静态检查解锁工具本体后，可以确认它实际走的是另一条路线。整个流程发生在 Android 已经正常启动之后。脚本会先通过 ADB 将对应系统版本的 preload.so 推送到 /data/local/tmp，再利用 LD_PRELOAD 触发其中的漏洞代码，获得一次临时 Root。取得足够权限以后，工具才会继续把修改过的 LK 镜像写入设备的 lk_a 和 lk_b 分区。

从工具中的字符串和调用逻辑来看，preload.so 内包含 KernelSnitch、pselect、futex、pipe physrw、kernel_read64、kernel_write_data 等非常明确的内核利用特征。其中针对 305 版本的 payload 里还能直接找到 GhostLock 相关字符串，因此这一版可以比较明确地判断使用了 GhostLock 系列 Android Kernel Exploit 来取得临时 Root。

OS2 和 OS3 对应的 preload.so 没有直接出现 GhostLock 名称，但仍能看到 KernelSnitch + Futex PI + pselect + pipe physrw 这一组相同的利用特征。现有静态证据足以排除之前猜测的 heapb8 / MediaTek DA2 路线，但无法证明这两个 payload 与某个公开 GhostLock 仓库完全一致，只能确认它们属于同源或高度相关的内核利用链。

从利用位置来看，GhostLock 属于 Android / Linux Kernel 层面的漏洞利用，并不是所谓“天玑 SoC 漏洞”。 Dimensity 9400+（MT6991）的设备特异性更多出现在后半段。工具需要使用与 MT6991 匹配的 LK 镜像，临时 Root 只是为了获得写入这些受保护分区所需的权限。

静态检查 main/lk.dll 时能看到 MediaTek、MT6991、fastboot、oem unlock、oem setmtklks、Start unlock flow 等字符串。这个文件虽然使用 .dll 扩展名，却不是 Windows DLL，而是针对 MT6991 修改过的 LK（Little Kernel）镜像。脚本先在已经启动的 Android 中通过 ADB 推送并触发 preload.so，拿到临时 Root 后写入 lk_a、lk_b，随后重启到 Fastboot，由修改后的 LK 参与后续解锁状态处理。

这套方案同时受内核版本和 LK 版本约束。系统安全更新可能修掉临时 Root 所依赖的内核漏洞，OTA 也可能重新写入 LK 分区。即使漏洞本身还能触发，只要系统里的分区布局、LK 版本或启动链发生变化，原来的工具也未必还能直接使用。

解 BL 锁后，系统仍可正常进入 HyperOS，但设备已不再处于厂商默认的完整安全状态。后续的 Root、完整性检测和环境隐藏问题，也都建立在这一前提上。

模块与挂载#

KernelSU 模块经常被概括成 Systemless，但这里的重点并不是“没有修改”，而是尽量不直接改写原始系统分区。像启动脚本、system.prop 和 sepolicy 规则，本身不一定需要文件挂载；如果模块需要替换 /system 等分区里的文件，则需要由 Metamodule 提供挂载能力。应用最终看到的是修改后的运行时视图，原始分区内容仍然可以保持不变。

我现在使用的 Hybrid Mount META 就属于这一层。它作为 Metamodule 负责模块文件的挂载编排，可以在 OverlayFS、Magic Mount 等后端之间选择。这样一来，普通模块只负责提供要修改的文件或脚本，具体怎样把这些内容映射进系统，由 Metamodule 统一处理。排查模块问题时也需要把“模块自己的逻辑”和“挂载是否成功”分开看。

Zygisk 与 LSPosed#

KernelSU 本身不内置 Zygisk，所以当前环境里由 Zygisk Next 提供 Zygisk API。它位于 KernelSU 和 LSPosed 之间，负责给依赖 Zygisk 的模块提供运行环境。LSPosed 再通过这套环境进入 Zygote 派生出的应用进程，并按作用域加载对应的 Xposed 模块。

在我现在这套配置里，加载顺序就是 KernelSU → Zygisk Next → LSPosed → 具体的 LSPosed 模块。这里任何一层失效，问题都会传到上面。例如 Zygisk Next 没有正常注入时，LSPosed Manager 仍可能存在，但 HyperCeiler、HyperIsland、HyperLight 这类模块不会真正进入目标进程。

当前模块#

当前配置里的模块并不都在做同一件事。KernelSU 侧主要负责挂载、运行环境和隐藏相关处理，LSPosed 侧则更多用于界面与应用行为修改。

环境隐藏#

现在的 Root 检测已经不是“有没有 su”这么单一。应用可以从用户空间痕迹、安装包列表、系统属性、挂载状态、Bootloader 状态、Zygisk/Hook 痕迹以及 Key Attestation 等不同位置判断设备环境。不同检测项拿到的信息来源不同，所以一个模块通常只能处理其中一部分。

目前我使用的是酷安 @小白qwqQAQ 发布的 小白一键隐藏 v2.2.0。它会自动配置 Zygisk Next、HMA-OSS、密钥与安全日期等组件，把原本需要分别处理的几项环境配置集中到一起。真正起作用的仍然是这些底层组件本身，所以排查问题时不能只看“一键隐藏”是否安装成功。

HMA-OSS 主要针对应用列表。部分应用会主动枚举已安装软件，如果直接发现 Root 管理器、Fake Location 或其他常见工具，即使它们没有找到 su，也可能继续判定设备环境异常。HMA-OSS 的作用就是在 Zygisk 层处理这类应用列表查询。

Key Attestation 又是另一条链路。它涉及 keystore2、证书链、硬件支持信息以及安全补丁等级等内容，并不只是读取几个 ro.* 属性。当前使用的 TEESimulator-RS 就放在这一层，所以前面提到的 ro.build.version.security_patch、Vendor 补丁日期和 post-security-patch-level 不一致，实际配置时不能混成一个值看待。

不同隐藏方案也不适合直接叠加。两个模块如果同时改 Boot 属性、挂载规则、包名可见性或者 Attestation 结果，最后出现的问题通常不是“隐藏得更多”，而是两边互相覆盖。更换方案时最好先确认旧模块动过哪些位置，再决定哪些组件需要一起替换。

环境检测#

我现在更关注检测失败发生在哪一层，而不是只看某个检测工具最后给出的“通过 / 不通过”。如果是应用列表暴露，应该先查 HMA 和作用目标；如果是 Bootloader 或系统属性异常，就看对应的 Boot 信息和隐藏模块；如果问题落在 Key Attestation，则要检查证书链、Keybox 和安全补丁字段。把这些问题分开后，比不断叠加新模块更容易定位。

检测结果也不是固定的。应用更新后可以增加新的检测路径，系统 OTA 会改变 Kernel、属性和安全补丁信息，隐藏模块本身也可能因为 Android 或 HyperOS 更新而失效。因此每次大版本更新后，我都会把 Root 权限、Zygisk、LSPosed、模块挂载和完整性检测分别确认，而不是只看 KernelSU Manager 是否还能正常打开。