SuperKey 超级密钥 — 为什么比传统 su 更安全

它是什么

SuperKey 是 APatch 用来替代传统 su 守护进程授权机制的一套密码学凭证系统。

传统 root 方案（包括 Magisk、KernelSU）都是 su 守护进程模式：App 请求 root → su 守护进程收到请求 → 检查是否在白名单 → 是的话 fork 一个子进程给它 root 权限。整个流程在用户空间完成，su 守护进程本身是 root 权限，任何能访问它的恶意 App 都可能被它授权。

APatch 则完全不同：内核里有一个新系统调用叫 SuperCall，App 调用 SuperCall 时必须传入正确的 SuperKey，内核验证通过后才在当前线程上直接授予 root 权限。整个流程发生在内核态，用户空间不可见。

为什么更安全

这种设计有三个安全优势：

1. 没有 su 守护进程的攻击面

传统方案里，su 守护进程本身是 root 权限的进程。如果恶意 App 能绕过授权检查（比如通过调试 hook、竞态条件），就能利用 su 守护进程拿到 root。APatch 的 SuperCall 发生在内核里，没有用户空间进程可以被利用。

2. 验证失败时静默返回

如果调用 SuperCall 时传入了错误的 SuperKey，内核会让系统调用正常返回（返回调用前的状态），调用方完全不会感觉到"这里有个 root 权限门"。这意味着检测 App 尝试探测 SuperCall 也会被静默忽略——root 的存在对外是完全隐藏的。

3. 密钥控制谁能 root

SuperKey 像一把钥匙——只有拿到正确密钥的程序才能成功调用 SuperCall 获得 root。APatch 管理器里维护的 App 白名单，本质上就是"哪些 App 被允许使用这把钥匙"。

安全提醒：不要设置弱密码

超级密钥的权限高于 root 访问权限——拿到密钥的任何程序都能获取 root。所以：

• 绝对禁止设置 12345678、password、00000000 这类弱密码
• 新版 APatch 管理器已经强制使用强密码（8-63 位，包含数字和字母，不允许特殊字符）
• 刷入第三方修补的 boot.img 之前，确认不会泄露你的 SuperKey——修补好的 boot.img 里 SuperKey 是明文存储的
• 不要把 SuperKey 发给任何人、不要存到不安全的位置

关于 SuperKey 迁移

从旧版 APatch（11090 之前）升级时，SuperKey 机制有一个重大变化——不再强制使用 SuperKey 认证，改为验证管理器签名。这意味着：

• 从 SuperKey 版本升级，必须先升级到一个过渡版本，再升级到最新版本
• 跳过这个步骤可能导致卡开机或丢失 root 权限
• 详见官方升级指南

如果忘了 SuperKey

从原厂 boot.img 重新修补一次就行——修补时会要求你重新设置 SuperKey。