xiamiya 内核级 / 系统服务级 Hook
当 App 的环境探测（root/调试/frida/模拟器检测）在应用层拦不住时，往下沉到系统服务层或内核层拦截。
一、先判断需要多底层
| 层级 | 手段 | 适合 |
|---|---|---|
| 应用层 | Xposed/LSPosed hook Java API | 普通 root 检测（Build 属性、su 路径） |
| Native 层 | Frida/inline hook libc（fopen/access/stat） |
检测走 native 直接读文件 |
| 系统服务层 | hook system_server 里的 PackageManager/ActivityManager | App 查其他包、查进程列表来反检测 |
| 内核层 | KernelSU/APatch 内核模块、syscall hook | App 直接走 syscall 绕过 libc，或检测非常严 |
二、系统服务层 Hook（system_server）
- LSPosed 可 hook system_server 进程（作用域勾选"系统框架"）。
- 常 hook 点：
PackageManagerService.getInstalledPackages/getPackageInfo—— 隐藏 Magisk/Xposed 管理器等敏感包ActivityManagerService.getRunningAppProcesses—— 隐藏 frida-server/可疑进程Settings.Global/Secure.getInt—— 伪造 adb_enabled、development_settings_enabled
- 注意：改系统服务影响全局，务必精确匹配调用方（只对目标 App 生效），否则可能引起系统不稳定。
三、syscall / 内核层拦截
- 场景：App 用内联汇编直接发
svc系统调用（绕过 libc，Frida hook libc 就失效，见 svc-instruction-trace 技能）。 - KernelSU / APatch：提供内核态能力，可用 kprobe/kretprobe 挂钩 syscall 入口，或用其提供的
susfs之类方案隐藏 root 痕迹。 - 思路：
- 确定 App 检测走哪个 syscall（openat 读
/proc/self/maps、/proc/net/tcp查 frida 端口等） - 内核模块里 hook 对应 syscall，对目标进程返回伪造结果
- 或用现成的隐藏框架（Shamiko/susfs/Zygisk 模块）先试，能解决就不用自己写内核模块
- 确定 App 检测走哪个 syscall（openat 读
四、实操建议
- 优先用现成隐藏方案（Shamiko + LSPosed 排除列表、Zygisk-based hide），能过大多数检测，成本最低。
- 现成的过不了再考虑自写内核模块（需要 KernelSU/APatch 环境 + 内核开发能力）。
- 每加一层 hook 都要验证：目标 App 是否还检测得到、系统是否稳定。
边界
用于自有设备的安全研究、反检测机制学习、隐私保护、恶意软件的环境对抗分析。不协助攻击他人设备、绕过他人系统的安全控制去实施侵害。