KernelSU: 内核 ROOT 方案， KernelSU KernelSU KernelSU 新的隐藏root防止检测封号方案

news2025/1/16 21:03:37

大约一年多以前，我在一篇讲Android 上 ROOT 的过去、现在和未来https://mp.weixin.qq.com/s?__biz=MjM5Njg5ODU2NA==&mid=2257499009&idx=1&sn=3cfce1ea7deb6e0e4f2ac170cffd7cc1&scene=21#wechat_redirect 的文章中提到：

我认为，随着 GKI 的出现，内核的碎片化会逐渐消失，我们完全可以通过修改内核的方式去获取 EL1 root。

本以为这一天很快就会到来，没想到时间过去这么久，马上都要 Android 14 了，这玩意儿还是没有出现...没办法，我就只好自己动手了！其实我之前在探索某大型 5V5 游戏的态势感知系统的时候，已经使用过内核相关技术了；正好几个月前换了新手机，其系统出厂是 Android 12，内核是基于 GKI 的；于是我尝试把这个「态势感知系统」移植到 GKI 内核上，在移植的过程中，KernelSU 的雏形初现；我索性一不做二不休，直接把它淦完了！现在我宣布：

KernelSU，一种基于内核技术的 ROOT 方案，它来了！

什么是 KernelSU？

KernelSU，顾名思义，就是基于内核的 SU。它通过自定义内核，直接在内核中赋予目标进程 root 权限。更多关于 root 的知识可以参考我之前的文章：何为 root?。

其实 KernelSU 很早就有人提出了来了，大约 2018 年的时候，XDA 上的 zx2c4 就给出了一个简单的实现[1]；虽然整个实现非常简单，但它的确给我们展示了另外一种可能。后来，LSPosed 团队在实现 WSA 的 Magisk 方案的时候，也曾通过 KernelSU 来 root WSA[2]。

由于 KernelSU 的实现需要自定义内核，而 Android 系统的碎片化极其严重，又由于 Linux 内核不同版本之间没有兼容性可言；因此之前的 KernelSU 方案很难拥有通用性：你必须给每个型号的设备编译一个自定义内核，这几乎是不可能实现的。另外，之前的 KernelSU 实现没有鉴权系统，系统中的任何进程，无需任何授权，都可以直接通过 su 访问到 root 权限；这对普通用户来说是难以接受的：随便一个 App 一上来就有可能控制你的整个手机。

不过，我今天实现的 KernelSU 已经很好地解决了以上两个问题。

我干了什么？

为了解决之前内核 root 方案的问题，我干了三件事：

第一件事，就是等。我等到了 GKI 的出现，Google 通过 GKI 统一了 Android 系统的内核，在 GKI 2.0 以后，不同的 Android 设备之间在 KMI 兼容的情况下，是可以使用通用内核的；虽然理想与现实之间还是有一些差距，但现在 GKI 内核的通用性，已经与曾经那个碎片化时代不可同日而语了。

第二件事，我找到了一种 KernelSU 的鉴权方案；通过在内核中扫描当前进程的 apk，然后验证其签名来实现 root 管理器；root 管理器与内核之间通过特制的系统调用来授权，保证未授权进程无法使用 root 功能。

第三件事，我采用了一种稳定的系统调用拦截技术；通过 kprobe 来拦截系统调用，进而实现 root 管理器和内核之前的通信，不在文件系统中留痕，能完美地隐藏自己。

FAQ

KernelSU 支持哪些设备？

内核版本 5.10 以上的设备支持，其他均不支持；未来也许可以通过 static binary instrumentation 的方式 backport 到旧内核，就看有没有有缘人来实现了。

KernelSU 与传统的 ROOT 有什么区别？

KernelSU 主要工作在内核空间，而传统的 ROOT 如 Magisk 实际工作在用户空间。

KernelSU 能有类似 Magisk 的模块功能吗？

KernelSU 会有模块功能，不过可能与 Magisk 的模块不同；KernelSU 将提供内核模块接口，其规划的模块功能，主要用来将代码或者脚本文件加载进内核空间执行；而非类似 Magisk 那样提供文件系统 overlay。不过理论上讲，KernelSU 也可以实现文件系统 overlay。