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 是内核特性，语义更标准
  • 但实时性稍差，多数变更需要重启

特点与限制

• 特点：

  1. 内核态 su：安全模型清晰，可做细粒度 App profile（按 UID/GID 控制权限大小）
  2. 官方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）

特点

1. KPM 内核模块：

   • 在已经被 kpimg 接管的内核里，动态加载 KPM 模块
   • 支持对内核函数进行 hook，部分 hook 即时生效
   • 无/system/bin/su文件，通过监听拦截/system/bin/su或su指令来实现提权

2. 模块系统 + Lua 脚本：

   • 用户态 apd 管理模块目录、事件（post-fs-data / boot-completed 等）
   • 最新版本中可以用 Lua 替代传统 shell 脚本，增强复杂逻辑可维护性

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

   • 用 tools/kallsym.c、tools/patch.c 等做符号解析、patch
   • 用 kernel/patch/android/user_init.sh 等把 apd 接到系统启动阶段

三、综合对比与结论

技术路线对比（简表）

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

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

• KernelSU：
  适合有 GKI 内核，且希望在内核层面细控 Root 权限（App profile）的人，
  更偏“官方化”的内核模块方案，但对旧机型支持有限 可以自定义挂载

• APatch：
  从技术理念上最“硬核”，不依赖源码、支持广泛内核版本，
  内核模块 hook + Lua 模块系统，对研究者 / 高级玩家非常友好。