ID：
ROOT_PROPERTY类别： Root 与系统状态 RKNHardering 2.10.0 中的状态： 已启用的检查 在最终判定中的作用： 中
本页说明 RKNHardering 2.10.0 中的实际实现，并分别指出无需 root 权限即可采取的措施、需要 root 权限的措施，以及哪些缓解方法只能减少单个信号而无法隐藏整个 VPN。
探针检查以下精确键值对：ro.debuggable=1、ro.secure=0、ro.build.selinux=0、service.adb.root=1 和 ro.build.tags=test-keys。只有精确匹配才生成 root_prop；检查器把它作为中等置信度待复核项。
至少一个固定属性具有精确的可疑值。
该信号更常表示调试/工程 ROM 或修改过的 boot 镜像，而不是某个具体 root 管理器。test-keys 在社区自定义 ROM 中尤其常见。
该行如何影响报告：该行本身不会直接得出最终判定，但会设置 needsReview=true，并加入中等置信度证据。
生产环境中的 root 配置可能完全不改变这些属性。反过来，即使没有授予 su，AOSP userdebug 构建也可能合法触发。
必须把这一行与相邻信号一起评估。单个 API 返回干净结果，并不能同时覆盖 Java Binder、libc、原始 netlink/系统调用、procfs/sysfs、本地套接字以及服务器端指标。
需要干净基线时，应使用厂商官方 user 构建。恢复出厂设置不会替换固件，也不会改变 ro.* 属性。不要下载任意 build.prop；它必须与已安装镜像匹配。
resetprop 可以改变可见值，但与启动状态、构建 fingerprint 和挂载不一致时，会产生新的指标。只把伪装用于实验室测试，不能把它当作设备干净的证明。SELinux 也不能靠单个属性值“修复”。
adb shell getprop ro.debuggable
adb shell getprop ro.secure
adb shell getprop ro.build.selinux
adb shell getprop service.adb.root
adb shell getprop ro.build.tags
把值与详情比较；root 级替换后，不同上下文看到的属性命名空间可能不同。
完成任何修改后，请对 RKNHardering 和 VPN 客户端都执行 force-stop，重新启动两者并再次进行完整扫描。Zygisk、Xposed 和内核模块通常还需要重启设备。不要只比较这一行，也要检查相邻信号：不完整的 Hook 往往会造成不同 API 之间的结果不一致。
探针本身以普通应用权限运行，不会请求 root。下方 ADB 命令仅用于辅助定位：adb shell 使用不同的 UID，所能看到的内容可能比应用进程更多，也可能更少。决定性测试是在 force-stop 后重新运行应用内检查。
修改早期启动属性或 boot 镜像可能导致启动循环。错误 fingerprint 还可能破坏 OTA 更新、Play 服务与兼容性。
只删除自己创建的 resetprop 规则并重启。若修改过 boot 镜像，请恢复同一构建的原始镜像。
中。已根据 kRootProps 核验；检查器分配中等置信度。
第三方方案的状态不能自动套用到当前设备。模块开发者的声明只是初始假设；只有在特定 Android 版本、固件和内核上得到可重复的 RKNHardering 结果，才能视为确认。
native_signs_probe.cpp — 原生探针实现.NativeSignsChecker.kt — 原生/旧版信号的主要判定逻辑.NativeSignalId.kt — 完整 ID 目录.NativeSignalCatalog.kt — 类别、slug 与输出行映射.相关信号： root-magisk-property, emulator-build-profile, root-selinux.