Shamiko 为什么不能在 APatch 上用
Shamiko 是什么
Shamiko 是 Magisk 生态里最流行的 root 隐藏模块——它能让 SafetyNet 和 Play Integrity 检测不到设备被 root 过，同时允许开发者模式和 USB 调试正常开启。大量需要过 root 检测的 App（银行、游戏、企业 MDM）都依赖它。
为什么 Shamiko 在 APatch 上不能用
APatch 官方文档明确说：
无法使用 Shamiko。Shamiko 是专有软件，其闭源特性导致无法适配。
技术原因：Shamiko 是闭源的 Magisk 模块，它内部实现了对 Magisk 特定机制的 hook（magisk 内部 API、su 守护进程 hook），这些机制在 KernelSU 和 APatch 里都不存在。没有源码的情况下，没法做适配。
风险提醒
官方同时说：
APatch 开发者将不对任何因使用 Shamiko 导致的问题承担任何责任，你需要自行承担使用风险。
不只是不能用——尝试强行把 Shamiko 装到 APatch 上还可能导致：
- bootloop（模块在非 Magisk 环境下 hook 到了不存在的接口）
- SELinux 异常
- 系统稳定性问题
APatch 有原生 root 隐藏能力吗
好消息是：APatch 本身的设计就比 Magisk 更隐蔽——root 在内核空间、SuperCall 密钥错误时静默返回、没有 su 守护进程和 su 二进制。很多 Magisk + Shamiko 组合想解决的问题，APatch 默认就解决了：
| 隐藏项目 | Magisk 需要 Shamiko | APatch 原生行为 |
|---|---|---|
| su 二进制 | Shamiko 隐藏 | 不存在 su 二进制 |
| magisk 属性 | Shamiko 修改 build.prop | 不存在 magisk 属性 |
| SafetyNet | Shamiko pass | 可能直接 pass（但不完全保证） |
| 文件检测 /data/adb | Shamiko hook | KPM 可以 hook access()/open() |
| Play Integrity | Shamiko pass | 看设备型号（官方还是非官方 ROM） |
可替代方案
虽然 Shamiko 不能用，但有几种替代思路：
KPM 内核级 hook
用 KPM hook access()、openat()、getdents64() 等 syscall——检测 App 对 root 痕迹的探测请求时直接拦截。比 Shamiko 的用户空间 hook 更彻底。
GitHub 上有现成的 KPM root 隐藏模块，搜一下就能找到。
Zygisk 下的 LSPosed 模块
如果已经装了 ZygiskNext，可以装 LSPosed 的 root 隐藏模块——在 Java 层 hook SafetyNet/Play Integrity 的调用逻辑。
APatch 白名单 + KPM 组合
最干净的方案：
- 用 KPM 内核级 hook 彻底隐藏 root 痕迹
- 用 APatch 的白名单控制哪些 App 能获取 root
- 不开 su 守护进程（APatch 默认就这样）
- 不碰 SELinux policy（APatch 默认 hook 绕过）
关于 Riru 的情况
Riru 也是 Magisk 生态的组件，它通过 modifyboot 方式修改 boot 分区，在 Zygote 进程启动前注入自己。Riru 也和 APatch 不兼容——Riru 假设 boot 分区的 ramdisk 有特定结构，而 APatch 修补内核后这个结构可能已经变了。
总结
- Shamiko 是专有软件，没法适配 APatch
- APatch 原生设计已经比 Magisk 更隐蔽
- 用 KPM 内核 hook 替代 Shamiko 的隐藏功能
- 有 Zygisk 的话，LSPosed 模块也能做 Java 层的检测绕过