Android Root 的演进与抉择

Android Root 发展历程和方案分析

Android Root 顾名思义即给安卓系统获取根权限，让用户拥有系统级权限，极大提升系统可玩性。

一般来说，Root 需要先解锁 bootloader（BL），解锁的目的，是让用户有权限刷写各个分区，从而能：

更换系统（system / vendor / product 等）

更换内核（boot ）

注入 Root / 模块方案

注意：解锁 BL ≠ 必然 Root，也可以只刷机不 Root。

主流 Root 方案按时间大致可以排成这样：

KingRoot → SuperSU → Magisk → SKRoot（小众） → KernelSU → APatch

一、Root 实现思路：按技术路线分类

用户态 Root（User-space Root）

不直接修改内核代码

修改 boot.img → ramdisk → init 脚本，在早期启动阶段插入自己的用户态 root 程序

通过 用户态守护进程 管理权限（例如 magiskd）

一般依赖一个 管理 App 配合使用（授权弹窗、模块管理等）

代表方案：Magisk

优点：对内核无强依赖，兼容面最广

缺点：本质不在内核，某些内核安全策略/厂商定制下会有局限

内核态 Root（Kernel-space Root）

直接在内核中 Hook 权限相关函数 / LSM / syscall

在内核层修改 cred、capabilities 等结构，获得最高权限

部分方案需要内核源码（早期 KernelSU），部分不需要（APatch、SKRoot）

代表方案：KernelSU、APatch、SKRoot

优点：权限层级最高，可做更“隐蔽”和细粒度的控制

缺点：与内核版本/厂商定制强相关，适配成本较高

漏洞 Root（Exploit-based Root）

利用系统或内核漏洞临时/半永久获取 Root

通常依赖特定 Android / 内核版本，系统一更新就失效

代表方案：KingRoot 等一键 Root 工具

优点：用户体验简单，历史上对锁 BL 的机器也有机会

缺点：完全吃漏洞红利，维护性差，安全风险高

二、按时间线看典型方案

KingRoot：漏洞驱动的早期 Root

主要活跃在 Android 4.4 ~ 6.0 时代

通过 内核 / 系统漏洞（如提权漏洞）获得 Root

多为 临时或半永久 Root，重启或 OTA 后经常失效

随着漏洞不断被修复，这类方案很快被淘汰

定位：

完全基于漏洞的时代产物，如今更多是历史意义。

SuperSU：system 分区注入 su 的经典方案

思路：直接修改 system.img，在 /system/bin 或 /system/xbin 注入 su 二进制

通过 su 的 setuid 机制实现提权

典型适用 Android 4.x ~ 6.x，system 还比较“好改”的时代

随着：

system 分区逐渐只读 / 受更严格完整性保护

Magisk 引入 systemless Root

SuperSU 很快失去优势。

定位：

传统“改 system.img 注入 su”的代表

Magisk：用户态 systemless Root 的时代

Magisk 把 Root 方式拉到了一个新高度。

核心实现

修改 boot.img → ramdisk → init：

用 magiskinit 接管早期启动，作为“第一个用户态进程”

启动 root 守护进程 magiskd

/system/bin/su 在 Magisk 中 只是前端/中转：

解析参数 → 连接 magiskd → 由 magiskd 以 root fork/exec 真正的命令

提权的决策和执行在 magiskd 中完成，而不是在 su 本身

不在 system 分区直接写入文件，做到 systemless

（实际上是用挂载/覆盖的方式“虚拟出”修改过的系统视图）

关键特点

首创 magic mount 模块系统：

在不实际修改系统文件的情况下，实现对 /system、/vendor 等目录的文件覆盖

极大提升“玩机模块生态”

强兼容性：

只要能改 boot.img中的init脚本，大多数内核版本都能使用

依赖管理 App（Magisk App）：

管理模块、处理 su 授权弹窗、升级/卸载

局限

纯用户态方案，需要搭配app

模块生态与内核态模块（如 APatch 的 KPM ）相比，在内核能力利用上略逊一筹

不支持kernelsu后来的模块webui功能,需要额外安装app解决

SKRoot：早期“内核 Root + su 环境注入”的探索者

时间上早于目前主流内核 Root（KernelSU / APatch）

无需内核源码：

离线分析目标内核镜像（ELF/镜像格式）

找到如 do_execve 等关键函数与 task_struct/cred/seccomp 的偏移

插入自定义 shellcode 实现内核级提权

号称“隐藏性很强”：

没有模块系统

常见用法是：针对单个或少数进程注入 su 环境

通过 PATH / so 寄生等方式，让特定 APP 获得 su，而不是全局暴露

适配范围：大致 3.10 ~ 6.6 内核

优点：

不依赖内核源码，适配范围相对广

su 环境可以“定向注入”，对其他进程很隐蔽

缺点：

没有完整的模块系统，操作较繁琐

生态小众，文档和社区支持相对较弱

KernelSU：主流内核态 Root + overlayfs 模块

基本定位

代表性的 内核态 Root：

在内核中安装 hook（LSM / cred 修改等）

在执行 /system/bin/su 时，内核直接修改进程 cred 实现提权

/system/bin/su 在 KernelSU 中是真正的 提权入口：

它触发内核 hook

提权是在内核里完成的，而不是转发给某个守护进程（区别于 Magisk）

技术路径演进

早期：通过 谷歌GKI 内核（已被官方淘汰） / 内核源码集成（已被官方淘汰） 集成 KernelSU

现在主流：LKM（ko 模块）方式：

把修改封装成内核模块加载进 GKI 内核

同一大版本Gki内核编译出来的ko模块具有一定通用性,所以安装体验上不需要内核源代码

但 ko 的编译仍依赖内核的源码，只是这部分由项目方/维护者完成

对用户体验来说“不需要自己改源码”

模块系统：元模块（支持overlyfs/magic mount或者自定义挂载方式）

默认使用 overlayfs 实现模块系统(首创)：

支持对 /system 等只读分区做“上层覆盖”(模块安装后通常需要 重启才能生效对/system的修改)

对比 Magisk 的 magic mount：

overlayfs 是内核特性，语义更标准

但实时性稍差，多数变更需要重启

特点与限制

特点：

内核态 su：安全模型清晰，可做细粒度 App profile（按 UID/GID 控制权限大小）

官方overlayfs 模块系统：结构正规，可与 GKI 思路统一

限制：

对低版本 / 非 GKI 内核兼容性差

一些魔改了内核且不开源的gki设备对谷歌官方gki内核支持差,刷了可能开不了机

官方更推荐搭配 5.10以上的 GKI 内核搭配ko模块使用

APatch：无需源码的 kpimg 内核 Root + KPM 模块

在内核 Root 方案中，APatch 的技术路线是目前最“工程化 + 通用”的一类。

核心实现方式

仍然是 内核态 Root，但：

不需要内核源码

使用 KernelPatch 工具链解析并 patch 目标内核镜像

通过在内核镜像中注入 kpimg：

修改内核启动入口 / early init 流程

把自定义 hook 注入到内核的启动过程

重启后，kpimg 会在早期阶段接管部分逻辑，实现：

Root 提权

内核 hook（supercall / inline hook）

启动用户态守护/事件（apd 等）

兼容性

内核版本范围广：3.18 ~ 6.12

不依赖 GKI，不要求厂商公开内核源码

对各家定制内核更友好（因为是直接对内核二进制镜像做符号分析与 patch）

特点

KPM 内核模块：

在已经被 kpimg 接管的内核里，动态加载 KPM 模块

支持对内核函数进行 hook，部分 hook 即时生效

无/system/bin/su文件，通过监听拦截/system/bin/su或su指令来实现提权

模块系统 + Lua 脚本：

用户态 apd 管理模块目录、事件（post-fs-data / boot-completed 等）

最新版本中可以用 Lua 替代传统 shell 脚本，增强复杂逻辑可维护性

不依赖内核源码的工程化链路：

用 tools/kallsym.c、tools/patch.c 等做符号解析、patch

用 kernel/patch/android/user_init.sh 等把 apd 接到系统启动阶段

支持kernelsu的元模块挂载方案(2026.1.12补)

三、综合对比与结论

技术路线对比（简表）

方案

类型

是否改内核代码

是否需源码

是否依赖 App

su 角色

模块系统

KingRoot

漏洞 Root

否

否

需要

各家自定义

无 / 简单补丁

SuperSU

system 注入 su

否

否

可选

传统 setuid su

无

Magisk

用户态 Root

间接（不改内核）

否

强依赖

/system/bin/su中转到 magiskd

magic mount

SKRoot

内核 Root

是（patch 镜像）

否

有工具/库

隐藏 su + 进程定向注入

无完整模块系统

KernelSU

内核 Root

是（源码/GKI/LKM）

技术层面上需要

App 非必须

/system/bin/su 触发内核提权

元模块

APatch

内核 Root

是（kpimg patch）

否

App 非必须

内核 hook su/execve 等

APM/KPM + Lua

目前最主流的三款root方案分析

Magisk：

适合追求 广泛兼容 + 成熟模块生态 的用户，一般设备能解锁 boot.img 就能用。

KernelSU：

适合有 GKI 内核，且希望在内核层面细控 Root 权限（App profile）的人，

更偏“官方化”的内核模块方案，但对旧机型支持有限

可以自定义挂载

APatch：

从技术理念上最“硬核”，不依赖源码、支持广泛内核版本，

内核模块 hook + Lua 模块系统，对研究者 / 高级玩家非常友好。

荒漠灾虫
word如何设置显示段落标记