SuperKey 认证
约 1947 字大约 6 分钟
SuperKey 是一把可选的管理器认证密钥。官方 APK 的签名不方便用、或者你在做私有管理器时，可以靠它告诉内核：“这个调用方就是管理器。”
用官方管理器的人不用填。包名和 APK 签名已经是默认认证方式，也是最省事的一种。
先明确它能做什么
YukiSU SuperKey 只认管理器。它不是应用申请 Root 的密码，也不是拿到后就能随便调用内核的万能钥匙。应用能不能拿 Root，仍然看超级用户列表和 App Profile。
与 KernelPatch / APatch 的 SuperKey 不同
只是名字碰巧一样，工作方式完全不同：
| 项目 | YukiSU SuperKey | KernelPatch / APatch SuperKey |
|---|---|---|
| 入口 | prctl(KSU_PRCTL_SUPERKEY_AUTH, ...) | syscall NR45 SuperCall |
| 认证对象 | YukiSU 管理器 | 每次 SuperCall 的调用方 |
| 能力范围 | 验证密钥并登记管理器 UID | 作为通用特权命令面的凭据 |
| 后续操作 | 管理器通过 YukiSU 驱动 / ioctl 继续通信 | NR45 可分派 Root、KPM、配置等多类命令 |
| 是否能直接给应用 Root | 不能 | 取决于对应 SuperCall 命令 |
KernelPatch/APatch 每次调用 NR45 SuperCall 时都会带上 SuperKey，Root、KPM、配置等命令都从这张“总入口”分发。YukiSU 没这么做：第一次通过 prctl 验证密钥，登记好管理器 UID，后面的授权、模块和配置继续走 YukiSU 驱动。
所以 APatch 教程里的 supercall、KPM 和“SuperKey Root”都不能套到 YukiSU，密钥本身也不能互换。
三种信任配置
| SuperKey | APK 签名验证 | 可用认证路径 | 适用场景 |
|---|---|---|---|
| 留空 | 启用 | 受信任包名与 APK 签名 | 官方构建、首次安装，推荐 |
| 已设置 | 启用 | 签名认证仍可用，另可通过 SuperKey 认证 | 保留官方回退，同时使用自定义管理器 |
| 已设置 | 禁用 | 仅 SuperKey | 私有签名或封闭部署，高风险 |
填了 SuperKey，不会自动关掉 APK 签名验证。只有你另外勾选“禁用 APK 签名验证”，签名这条退路才会消失。
不要用 SuperKey-only 掩盖普通认证失败
官方 APK 都认证不了时，先查 APK 来源、包名、签名、LKM 和版本。直接改成 SuperKey-only 看似绕过去了，实际是把原问题盖住，再把恢复希望全压在一把密钥上。
内核中保存的不是明文
配置时，YukiSU 会生成 16 字节随机 salt，只保存 SHA-256(salt || key) 的前 8 字节和认证模式。认证时再拿输入的密钥重新算一遍，对得上才放行。
LKM 里没有一眼可见的明文，但 salt 和校验值仍足够拿去做离线猜测。密钥太短、太像人话，照样可能被跑出来；带私人 SuperKey 的 .ko 和镜像仍然算敏感文件。
密钥如何进入 LKM
SuperKey 可以在两个阶段设置。
编译时
构建 LKM 时传入：
KSU_SUPERKEY="your-secret"这适合自有构建流水线。流水线必须避免在命令回显、CI 参数、制品元数据和归档日志中泄露原始密钥。
修补或安装时
在管理器的 LKM 修补或安装页面填写 SuperKey，由 ksud 将对应认证数据写入这次生成的 LKM。它只影响当前输出，不会自动修改已经保存的其他镜像或 .ko。
CONFIG_KSU_SUPERKEY=y 控制内核能力，当前常规配置默认开启。管理器出现输入框不代表任意第三方或旧版 LKM 都支持它，最终以安装后的实际认证状态为准。
一次认证如何工作
一次认证实际会这样走：
- 管理器构造包含 SuperKey、Unix 秒级时间戳、结果字段和返回 fd 的认证请求；
- 管理器调用
prctl(KSU_PRCTL_SUPERKEY_AUTH, ...)； - YukiSU 的 TSR 路径截获这一专用
prctl请求； - 内核校验请求时间、当前认证模式和 SuperKey；
- 验证成功后，内核把调用方 UID 登记为管理器 UID，并向管理器提供驱动 fd；
- 后续管理请求通过驱动接口完成，不再把 SuperKey 当成每条 Root 命令的参数。
选 prctl，是因为这条入口能在 Android seccomp 环境下工作。管理器取得驱动 fd 后还保留兼容处理，但不管内部怎么走，SuperKey 的公开用途都只有管理器认证，不会变成 NR45 通用 SuperCall。
内核会拒绝：
- 来自未来的时间戳；
- 比当前时间早 30 秒以上的请求；
- 不匹配或被截断的密钥；
- 当前 LKM 未配置 SuperKey 的请求。
手机时间差太多，正确密钥也会失败。管理器身份只记在当前运行的内核里，所以重启后要重新认证。
连续失败会触发保护
连续错 3 次，发起认证的进程会被终止；累计错 10 次，设备会重启。这里没有“无限试密码”模式。
保存、手动输入与开机认证
管理器提供两项使用设置：
- 不存储 SuperKey：管理器不保存密钥，每次重启后需要手动输入；
- 开机自动验证 SuperKey：管理器启动后用已保存密钥尝试一次认证，需要允许应用自启动，失败后不会无限重试。
“不存储”只影响管理器是否留下原始输入，LKM 里的 salt 和校验值不会因此消失。更少落盘和每次重启手输一次，你自己选。
选择与保管
- 使用足够长、随机且每台设备唯一的密钥；
- 不与锁屏 PIN、账号密码、ADB 密钥口令或磁盘密码复用；
- 避免姓名、设备型号、项目名和可预测短语；
- 使用能在设备键盘上稳定输入的字符；
- 在安全的密码管理器中保存，并标注对应设备和 LKM；
- 不把明文写进公开脚本、shell history、CI 日志或问题报告。
公开构建不要塞私人 SuperKey，直接用官方签名认证。自己有多台设备时也别所有机器共用一把；一份镜像泄露，最好别顺带把整批设备都拖下水。
更换或撤销 SuperKey
SuperKey 校验数据属于 LKM 的信任配置，不能只在管理器设置里“改密码”完成轮换：
- 保留与当前固件匹配的原厂镜像和可启动 LKM；
- 使用新密钥重新构建或修补 LKM；
- 确认是否继续保留 APK 签名认证；
- 按正常 LKM 安装流程写入明确的目标槽位；
- 重启并用新密钥认证；
- 清理旧密钥和包含旧校验数据的制品。
回到纯官方签名认证同样需要安装信任配置符合目标的 LKM，仅卸载重装管理器 APK 不会改变内核中的认证配置。
认证失败怎么排查
按这个顺序检查：
- 管理器首页是否能读取 YukiSU LKM；
- LKM 是否启用了 SuperKey 并实际配置了密钥；
- 输入是否含前后空格、全角字符或大小写差异；
- 设备时间是否正确；
- 管理器是否来自预期构建；
- 重启后是否因为“不存储 SuperKey”而尚未手动认证；
- 自动认证是否被系统的自启动限制阻止。
如果签名认证仍启用，可先使用受信任官方管理器进入环境，再安装一份信任配置明确的新 LKM。如果已经进入 SuperKey-only 且密钥丢失，则没有“找回密码”入口，需要用匹配设备、固件和 KMI 的可信 LKM 或原厂镜像重新建立启动链。