Guise Test — 验证 Hook 实际生效的靶应用

为什么需要 Guise Test

Guise 自己不知道「伪装有没有生效」——它只负责把 Hook 代码注入进去。但：

• 应用 A 读取 Android ID 走的是 Settings.Secure 还是别的路径？
• 应用 B 的完整性检查会不会从内核 SoC 读了 Hook 不到的信息？
• 某个通道真的拦截到了，还是应用绕过了？

没有客户端能告诉你「真伪」——这本来就是这类工具的天花板。但客户端能测一件事：「Guise 声称的配置和应用实际读到的 API 返回值是否一致？」

Guise Test 是什么

Guise Test 是和 Guise Reborn 同仓库发布的一个独立小型诊断应用：

• 单独的 APK，单独安装
• 专门用来测量目标应用各个 Android API 的实际返回值
• 在 Guise 的 Releases 页面里，找带 guise-test 标签的 Release

使用方式

1. 安装 Guise Test APK

从 GitHub Releases 下载并安装，就像装普通 APK 一样。

2. 在 Guise 里勾选 Guise Test 作为目标应用

进入 Guise → 应用列表 → 找到 Guise Test → 勾选 → 重启 Guise Test。

3. 配置一套伪装参数

比如你想验证「小米 11」档案的完整生效：

1. 在 Guise Test 的配置页里，用一键随机选一套小米 11 档案
2. 保存 → 重启 Guise Test
3. 打开 Guise Test，看它显示的各通道返回值

4. 三源交叉哈希

Guise Test 的核心能力是三源交叉哈希（详见下篇）——同一批设备事实，分别从 Java API、系统属性、内核三个通道读三遍，各自哈希。

哪个哈希不一样，它直接告诉你：「是哪条通道没跟上」。

为什么要装 Guise Test

每次改完配置，用 Guise Test 测一遍：

• ✅ 所有通道都跟上 → 配置正确，可以放心用在真实目标应用上
• ❌ 某个通道没跟上 → Guise Test 告诉你具体是 Build、属性层、GPU 还是内核层出了问题
• ⚠️ 物理事实改不了 → Guise Test 会明确标出哪些是客户端无法修改的（内核 SoC、内存、ABI）

第一次装 Guise 后，强烈建议先配 Guise Test 跑一次。理想结果是：

• 不一致 0 项
• 痕迹暴露 0 项
• 物理事实正常标注

确认 Hook 链路完整，再用在真实的目标应用上。