Root 隐藏不是隐身斗篷：用检测矩阵做暴露面自检

所谓“隐藏”可能只是不给某 App root，也可能涉及 mount namespace、包/文件、属性、Zygote Hook 或硬件 attestation。本文只在备用机、AVD 和开源 detector 上做可重复自检；成功标准是解释每层信号并能撤销，不是让银行、DRM、MDM 或反作弊 App 放行。

你会完成什么#

• 建立无隐藏 baseline，保存 Root 管理器状态、授权、本地检测与 Play 认证结果。
• 只启用 Root 管理器原生的拒绝授权/按 App 隔离功能，不叠第三方隐藏栈。
• 用 Root Checker/RootBeer、开源 Native Detector、Momo、Key Attestation 与 SPIC 按层记录结果。
• 撤销唯一变量并复测，识别 false positive、false negative 与不可改变的 boot/attestation 信号。

先看结论#

心智模型#

baseline（无隐藏） → 只启用一个原生隔离 → 同一矩阵复测 → 撤销 → 再复测
       │                       │                    │
本地文件/包/属性/mount      Zygote/进程           boot state/attestation
每层分别记录；“App 能打开”只是表象，不是完整证明

RootBeer 自己也说明本地 root 检测只能提供信号：OEM 预装 BusyBox 等情况可能误报，而已 Root 的设备也不存在绝对可靠的本地判定。Momo 覆盖更多社区常见痕迹，但截至核对日没有可审计的公开上游源码，应只作为补充观察，不能从随机镜像下载。Key Attestation 读取硬件证书，SPIC 请求并展示 Play Integrity verdict，而“关于手机”与只读 adb shell getprop 才负责 build/SPL/属性基线；这些是不同层，隐藏包名不能重写真实启动状态。

工具清单#

项目全景：Root 隐藏的 9 个项目，一个不漏#

九个项目按内核、Zygisk/模块、注入/映射、设备指南和工具箱分层，强调隐藏是多信号回归工程，不是安装一个“万能模块”。

1. 内核级隐藏与挂载/SELinux 信号 · 1#

用 SKRoot 一类项目说明内核 patch、挂载痕迹和 SELinux 探针的关系。仅在可恢复测试内核上审计，不接受“通杀所有内核”作为兼容证据。

本组共 1 项：1 个源项目、0 个 Fork，其中 0 项已归档。它们用于对照、诊断或审计，不组成可批量安装的推荐清单。

2. Zygisk 与隐藏模块 · 3#

覆盖 NoHello、隐藏安装器和通用 Root Hide 模块，说明 Zygisk/模块加载顺序、作用域和冲突。每次只加一个模块并保留禁用入口。

本组共 3 项：3 个源项目、0 个 Fork，其中 1 项已归档。它们用于对照、诊断或审计，不组成可批量安装的推荐清单。

3. 注入、maps 与环境检测研究 · 2#

把 AndroidInjectByPass 与逆向笔记放入授权实验室，讲 /proc/maps、文件/进程信号和 Hook 的防守验证用途，不给第三方应用提供规避步骤。

本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。它们用于对照、诊断或审计，不组成可批量安装的推荐清单。

4. 机型指南与完整 Root 路线 · 2#

小米/HyperOS 与通用 HideRoot 指南用于展示从解锁到验证的完整上下文，但其时间敏感结论必须按机型、地区和当前补丁重新核对。

本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

5. 工具箱与环境配置自动化 · 1#

综合工具箱只作为编排入口：拆开其 payload、下载源和实际执行命令逐项审计，避免用一键按钮掩盖多个系统修改。

本组共 1 项：1 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

开始前#

在无支付、企业资料和唯一 2FA 的备用机记录 exact build、SPL、Root 实现/版本、Zygisk/framework、模块列表、授权列表、bootloader/ROM 状态。固定 detector APK 的 commit/version/hash，关闭自动更新，准备一张表逐项记录。先确认 Safe Mode、ADB，以及与 Root 实现实际修改目标匹配的原厂镜像或完整厂商恢复路径；Samsung 只准备完整 Odin 恢复，不单刷启动分区。

截至 2026-08-09，任何“零痕迹、通杀、永久通过”都无法由宣传语证明。检测器、Root 实现、Android、Play services 或服务端任一更新，旧矩阵就失效，必须带完整版本重新测试。

操作步骤#

1. 建立未隐藏基线#

撤销所有第三方隐藏/Integrity 模块，重启两次。先用 Root Checker 或终端确认 su 授权，再运行 RootBeer 并保存每个子检查；如需第二个开源实现，只从固定 commit 审计并自行构建 Android Native Root Detector，不运行聚合仓库里的第三方 PoC APK。若你已持有可验证来源的 Momo，可记录其逐项文本，否则明确写“未使用”，不要临时找 APK。用“关于手机”与只读 adb shell getprop 保存 build/SPL/属性基线；Key Attestation Demo 的记录要导出到干净第二台设备加载验证，因为 Root/受控系统上的本机解析可被篡改；SPIC 另存 Play Integrity 原始响应。导出 Root 授权与模块列表；不要只截一个红绿灯。

2. 只启用一个原生控制#

选择一个开源 detector 作为目标，在 Root 管理器中明确拒绝其 root 请求，并按该实现官方说明启用最小的 App 隔离/deny 范围。不要改包名、装第三方模块或清 detector 数据。重启一次，记录设置截图和时间，这就是唯一实验变量。

3. 重复完全相同的测试矩阵#

按同一顺序、同一网络、同一 detector 版本运行全部检查。把每项写成“仍检测/不再检测/不适用/未知”，并保存原始文本。若只有 su 调用失败而文件/mount/attestation 不变，这是合理结果，不应包装成“全隐藏成功”。

4. 撤销并做回归#

取消目标范围和拒绝规则，重启；再次运行同一矩阵。结果应回到 baseline 的可重复范围。若仍不同，检查 App 数据、残留模块、framework 或系统更新；必要时禁用 Root 实现，并恢复其实际修改目标的原厂镜像或执行完整厂商恢复，再建立新 baseline。Samsung 不使用单分区回刷。

验证#

“目标 App 打开”最多是一项用户界面观察，后台 API、支付、推送、DRM 或账户策略仍可独立失败。本文的验收对象始终是开源 detector 和自有测试环境。

排错#

完成清单#

• □已记录设备 build/SPL、Root/Zygisk/framework/模块和 detector 版本/hash。
• □Baseline 包含每个本地子检查、Play certification 与 boot/attestation 摘要。
• □实验只启用一个原生拒绝/隔离控制，没有叠第三方隐藏模块。
• □结果按文件、包、属性、mount、进程、Hook、attestation 分层记录。
• □已撤销并重启，复测结果回到 baseline 可解释范围。
• □未把开源自检转用于银行、DRM、MDM、反作弊或真实生产账号。

一手资料#

• RootBeer 官方仓库
• Android Native Root Detector 上游仓库
• OWASP Root Detection 测试
• Play Integrity verdict
• Magisk 官方安装与 Samsung 恢复警告
• Android SDK Platform-Tools
• Key Attestation Demo 上游仓库
• SPIC 上游仓库