SuperSU 实现 Root 权限的核心原理是通过替换系统原生的 su 文件并配合权限管理机制,使普通应用能够通过授权流程获得 Root 权限。以下是其实现的关键步骤和技术细节:
⚙️ 一、突破原生限制:修改 su 文件
-
原生
su的限制
Android 系统自带的su文件(位于/system/bin或/system/xbin)仅允许root或shell用户调用,普通应用执行时会因权限检查失败被拒绝 。关键源码逻辑如下:int main() { uid_t current_uid = getuid(); // 仅 root 或 shell 用户可调用 if (current_uid != AID_ROOT && current_uid != AID_SHELL) { error(1, 0, "not allowed"); // 直接拒绝 } // 否则启动 root shell } -
SuperSU 的改造
-
移除 UID 检查:SuperSU 提供的
su文件删除了上述 UID 检查逻辑,允许任何用户(包括普通应用)调用su命令 -
设置 SUID 位:通过
chmod 06755命令为su文件添加SUID权限位(-rwsr-sr-x)。当任何用户执行该文件时,进程的 UID 会临时切换为文件所有者(root),从而获得 Root 权限
-
🔐 二、权限管理机制
SuperSU 并非无条件授予 Root 权限,而是通过 “前台代理 + 后台守护进程” 实现动态管理:
-
权限请求流程
-
当应用执行
su命令时,SuperSU 的su文件将请求转发给后台守护进程su daemon -
守护进程通知 SuperSU 应用(
Superuser.apk)弹出授权对话框,由用户决定是否允许
-
-
安全控制
-
日志记录:所有权限请求被记录,用户可查看哪些应用尝试获取 Root 权限
-
临时授权:支持为应用授予一次性 Root 权限,避免长期留权
-
⚠️ 三、与系统组件的交互
-
SELinux 策略调整
Android 的 SELinux 会默认拦截非授权进程的提权操作。SuperSU 通过刷入时注入自定义策略(如supolicy工具),允许进程切换到su域 。例如:policy 复制 allow appdomain su_exec:process transition; // 允许域切换 -
Recovery 刷入流程
-
设备需解锁 Bootloader,刷入第三方 Recovery(如 TWRP) 。
-
通过 Recovery 刷入 SuperSU 的 ZIP 包,该包包含:
-
修改后的
su文件(替换系统原生文件) -
Superuser.apk(权限管理界面) -
SELinux 策略工具(
supolicy) 。
-
-
⛔ 四、局限性及淘汰原因
尽管 SuperSU 曾广泛使用,但其设计在 Android 9+ 系统上面临严重兼容性问题:
-
系统分区只读
Android 9+ 强化了系统分区加密(dm-verity),直接修改/system分区会导致启动失败 。 -
SafetyNet 检测
Google 的 SafetyNet 会检测系统文件篡改。SuperSU 修改su文件的行为会被识别,导致 Google Pay、Netflix 等应用无法运行 。 -
SELinux 策略收紧
新系统的 SELinux 策略进一步限制非系统进程提权,SuperSU 的注入机制失效。
🔄 五、与 Magisk 的对比
| 特性 | SuperSU | Magisk |
|---|---|---|
| 修改方式 | 直接替换系统 su 文件 | 无系统(Systemless)挂载虚拟文件系统 |
| 隐蔽性 | ❌ 易被 SafetyNet 检测 | ✅ 不修改系统分区,规避检测 |
| Android 9+ 兼容性 | ❌ 最高支持 Android 7.0 | ✅ 支持 Android 13+ 及 GKI 内核 |
| 权限管理 | 弹窗授权 + 日志记录 | 动态授权 + Zygisk 注入 |
💎 总结
SuperSU 通过 替换系统 su 文件 + 设置 SUID 位 突破原生限制,再结合 权限弹窗管理 和 SELinux 策略注入 实现可控的 Root 权限。然而,其依赖系统分区修改的设计在 Android 高版本上因分区只读、SafetyNet 检测和 SELinux 收紧而被淘汰。现代方案如 Magisk 通过无系统修改和动态挂载解决了这些问题,成为当前主流。