KPM 是什么 — 内核空间模块 vs APM 用户空间模块
两个层次的模块
APatch 有两套模块系统，分别运行在不同层次：
| 模块类型 | 运行位置 | 设计目标 | 典型用途 |
|---|---|---|---|
| APM（AndroidPatch Module） | 用户空间 / systemless 叠加 | 修改系统分区文件、添加脚本 | 换字体、改 build.prop、注入 init.d 脚本 |
| KPM（KernelPatch Module） | 内核空间（Ring 0） | 内核级 inline-hook、syscall-table-hook | 隐藏 root、hook 文件访问、系统调用拦截 |
APM 是"表面"的修改——叠加文件、追加属性、跑脚本，本质上是给 Android 系统层加东西。
KPM 是"深层"的修改——代码直接运行在内核里，可以 hook 任何内核函数、拦截任何系统调用，APM 能做到的事它也能做到，但反过来不行。
KPM 和传统 LKM 的关系
KPM 的设计灵感来自 LKM（Loadable Kernel Module）——Linux 内核的可加载内核模块机制：
- 都是让代码运行在内核空间
- 都是为了扩展内核功能而不需要重新编译整个内核
但 KPM 比 LKM 更灵活：
- 不需要内核编译支持（CONFIG_MODULES 不是必须的）
- 不需要 modprobe（嵌入 boot.img 直接生效，或运行时加载）
- 不需要 kallsyms 导出修改（KernelPatch 会自己处理）
KPM 能做什么
文档明确提到的能力：
- 内核函数 inline-hook：在内核代码执行到某个函数入口时跳转到自定义代码
- syscall-table-hook：修改系统调用表，让特定 syscall 跳到自定义处理逻辑
这些能力足够做很多"超能力"级别的事：
- 隐藏 root 相关的文件、属性、进程（比 APM 的白名单更彻底）
- 拦截 open()、access() 等文件操作来保护分区镜像不被篡改
- 自定义 syscall 行为（比如让某个进程看不到某个 syscall 的返回值）
- 内核级别的反检测
从 APM 升级到 KPM
如果你的需求 APM 做不到（比如需要 hook 一个只有内核才知道的函数），就需要用 KPM。但 KPM 的开发门槛显著更高：
- 需要了解 Linux 内核的调用约定和 hook 原理
- 写错了直接搞挂内核（kernel panic / bootloop）
- 调试难度大（内核级别的问题不像用户空间有堆栈）
三种安装方式
KPM 有三种安装方式，详见专门章节：
- 嵌入 — 在修补 boot.img 时直接嵌进内核，开机 pre-kernel-init 阶段加载
- 加载 — 管理器里点"加载"立即生效，重启后消失
- 安装 — 保存到 /data/adb/kpmodules/ 持久化，在特定事件触发时加载（目前 APatch 未完全实现）