这篇文章记录一次对 Hunter Root 环境检测的处理过程。实际碰到的点主要有两个：

1. 硬件级完整性检测：TEE / Verified Boot。
2. 日志侧信道检测：通过系统审计日志反推设备存在 Root 痕迹。

这两个点一个偏“设备状态伪装”，一个偏“痕迹清理与权限隔离”，思路并不一样，分开处理会更清晰。

0x00 结论先看

• TEE / Verified Boot 检测可通过 TrickyStore 处理。
• 日志嗅探检测的关键不是隐藏文件本身，而是阻止目标 App 读取 logcat 中的审计日志。
• 处理完成后，Hunter 检测页恢复绿色。

0x01 硬件级检测：TEE & Verified Boot

处理方法

部署 TrickyStore 模块，并在 /data/adb/tricky_store/ 中配置 target.txt，将 Hunter 的目标包名加入处理列表。

如果系统里同时还用了其他隐藏类模块，建议先确认模块职责不要重叠，否则排查时很容易混淆到底是谁生效。

原理分析

这一类检测关注的不是普通文件路径，而是更底层的设备完整性状态，例如 Verified Boot、Key Attestation 或 TEE 相关字段。即使常规的 Root 隐藏已经处理过，应用依旧可以通过这些硬件或系统级信号判断设备是否“可信”。

TrickyStore 的思路，本质上是对目标应用可见的完整性信息做定向伪装，让应用在读取这些状态时拿到“看起来正常”的结果。

0x02 日志嗅探检测：Find Root File In Sniff

问题定位

我最初根据日志里的路径，怀疑它是在探测 APatch 相关目录；但后面复查设备环境时，发现当前系统里并没有 /data/adb/ap/log，也没有安装 APatch。

因此，更稳妥的结论应该是：Hunter 命中的并不是“当前目录一定存在”这个事实，而是它从系统日志里读到了与 Root 环境相关的审计记录。这个记录可能来自历史残留、之前装过的组件、其他模块留下的兼容路径，或者单纯是一次失败访问触发的 avc: denied 日志。

只要目标 App 能读到这类日志，它就可以不依赖目录是否真实存在，直接利用审计信息完成环境判定。

换句话说，它并不是直接“看见了 Root 文件”，而是通过“访问失败后留下的系统日志”完成了侧信道检测。

处理方法

先清理旧日志，再剥夺 Hunter 读取日志的能力：

1
2
3

logcat -c
appops set com.zhenxi.hunter 43 ignore
pm revoke com.zhenxi.hunter android.permission.READ_LOGS

其中：

• logcat -c 用于清理历史日志，避免旧的 avc 记录继续干扰检测结果。
• appops set com.zhenxi.hunter 43 ignore 用于在 AppOps 层面对 READ_LOGS 做拦截，这里的 43 对应 READ_LOGS。
• pm revoke com.zhenxi.hunter android.permission.READ_LOGS 用于从权限层进一步收紧日志读取能力。

原理分析

核心思路不是删除某个特定模块的痕迹，而是切断“日志回显”这条检测链。只要目标 App 无法读取 logcat，它就拿不到 SELinux 拒绝访问后产生的审计记录，自然也就无法利用这条侧信道做环境判定。

0x03 验证结果

重新打开 Hunter 后，检测页面已经恢复为绿色，说明这检测点都已经被处理掉。

0x04 小结

这次处理比较有代表性的一点在于：Root 检测未必都是“扫文件”和“扫包名”这么直接。

Hunter 这里至少包含两种不同思路：

1. 通过 TEE / Verified Boot 判断设备完整性。
2. 通过 logcat 读取 avc: denied 审计日志，利用系统日志做侧信道取证，而不必依赖目标路径当前真实存在。

因此，绕过时也不能只盯着“隐藏 su、隐藏 Magisk”这一类老思路。很多时候真正暴露环境的，不是目标文件本身，而是系统在访问、拒绝、审计过程中留下的附带信息。日志里出现的路径，也不应该直接等价为“当前设备上一定存在这个模块或这个目录”。