三源交叉哈希 — Java API、系统属性、内核三层比对
三源交叉哈希是什么
Guise Test 的核心诊断逻辑。同一批设备事实（品牌、型号、指纹、GPU、序列号……），分别从三个完全独立的通道读取，各自哈希后比对。
| 通道 | 读取方式 | Guise 能 Hook 吗 |
|---|---|---|
| Java API | Build.MODEL、GLES20.glGetString() 等 | ✅ 大部分 |
| 系统属性 | SystemProperties.get("ro.product.model") | ✅ 23 个 ro.\* 键 |
| 内核 | /sys/devices/soc0/machine、/proc/cpuinfo 等 | ❌ 不能 |
为什么三源
假设你在 Guise 里把 Build.MODEL 改成 Pixel 7。理想情况下：
- Java API 层返回
Pixel 7— 哈希 H1 - 系统属性层返回
Pixel 7— 哈希 H2 - 内核层返回真机的 SoC 信息 — 哈希 H3
Guise Test 告诉你：
| 结果 | 含义 |
|---|---|
| H1 ≠ H3 | Java 层和内核层不一致 — 你的 GPU 信息（来自内核）和 Build 型号（来自 Java）矛盾 |
| H2 ≠ H1 | 属性层和 Java 层不一致 — 你只改了 Build 类，忘了 SystemProperties |
| H1 = H2 ≠ H3 | Java 和属性层一致，只有内核层不同 — 这是正常的，内核层就是改不了 |
| H1 = H2 = H3 | 三层完全一致 — 除非你的真机本来就是目标设备，否则不可能（内核信息是物理事实） |
一个具体例子
Guise Test 运行在一台红米 Note 10 上，配置伪装为「Pixel 7」：
通道 1 (Java API):
Build.MODEL = Pixel 7
Build.BRAND = Google
Build.MANUFACTURER = Google
GPU Renderer = Mali-G710
[哈希 H1]
通道 2 (SystemProperties):
ro.product.model = Pixel 7
ro.product.brand = Google
[哈希 H2] ✓ 和 H1 一致
通道 3 (内核):
/sys/devices/soc0/machine = msmsteppe
/proc/cpuinfo → Qualcomm SM6115
GPU 实际是 Adreno 618
[哈希 H3] ✗ 和 H1 不同Guise Test 直接告诉你：
- Java 和属性层都对了 → 你的 Build 配置正确
- GPU 显示是 Mali-G710（Pixel 7 的 GPU）但内核 SoC 是 SM6115（红米 Note 10 的 SoC）→ 这是物理事实，改不了
- 结果：2 条一致、1 条物理限制 → 可接受
基线对照
Guise Test 还有一个有用的功能——基线对照：
- 第一次运行时，记录当前身份哈希作为「基线」
- 之后每次运行，对比基线和当前值，显示具体哪些字段变了
- 用来验证配置修改是否真的生效、或者应用是不是在偷偷采集你
这比「每次凭感觉看配置对不对」靠谱得多。