一、Android 普通app获取root用户权限的原理
Android 普通程序执行su，可以获取root权限。
该过程原理如下：
1.1 手机环境要求：手机已root
首先，该手机已root。这意味着，手机持有者已经完成了以下3步操作：
（1）保证该手机的/system/bin/下面有su可执行文件
cp /data/local/tmp/su /system/bin/ #copy su 到/system/分区
（2）保证su的所有者是root用户
chown root:root su #su的所有者置成root
（3）保证su的权限位为4775
即，非root用户对su有执行权限，且su文件有SUID权限位（rws的s）
chmod 4775 /system/bin/su #把su置成-rwsrwxr-x
rws的s，保证了运行su的进程的EUID，在运行su期间，变成了su的所有者的UID。
Linux内核为每个进程维护的三个对应的UID值：RUID、EUID、SUID。
每个值，是某个用户的UID。
Linux中，UID用于标识一个用户（例如alice，bob，root）
Android中，UID用于标识一个应用程序
关于进程的EUID，详情参考：https://blog.csdn.net/qq_39441603/article/details/125013758
这里插入一个小问题：
第一条命令cp /data/local/tmp/su /system/bin/直观上的作用是，把su文件放到环境变量中，这样shell在任意路径下执行命令su都能成功。
那么，这个copy su文件的过程是必须的吗？如果我不想copy，我直接在/data下放置su文件，并完成第2、3条命令，需要su时直接在/data下执行，可以吗？不可以
因为/data分区在被mount时，就被规定，其中的可执行文件不能有SUID权限
如果非要这么搞，需要重新挂载一次data分区：
mount -o rw,seclabel,suid,nodev,noatime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,inline_dentry,extent_cache,inline_encrypt,active_logs=6,remount -t f2fs /data
详情见：https://www.cnblogs.com/cqufengchao/p/6747167.html
1.2 app发起一个shell进程
app执行su命令，在java层通常的实现方式是：
process = Runtime.getRuntime().exec("su");
这里的Runtime.getRuntime().exec，底层原理是发起一个shell进程，去执行"su"命令。
注意，这里的shell进程很关键。后面将su源代码时会涉及这个。
"su"命令就是执行su文件。
1.3 shell进程运行su文件
一个进程有三个对应的UID：RUID，EUID，SUID
详情参考：https://blog.csdn.net/qq_39441603/article/details/125013758
由于su文件的权限位中有rws，所以：运行su的进程的EUID，在运行su期间，变成了su的所有者的UID。
而上文已述，su的所有者是root用户，所以运行su的进程的EUID，在运行su期间，变成了root用户的UID。
需要特别注意的是，当shell进程开始运行su的时候，shell进程的EUID，就已经是root用户的UID了。换言之，此时的shell进程，已经拥有root用户权限了。
但是，这种EUID变为root用户UID的情况，是有时效性的，在su文件运行完毕后就失效了。
而之所以运行过一次su文件，进程就能持久性地获得root用户权限，归功于su文件的内容。
其实，只要shell进程，运行的是一个owner是root用户，且权限位为4775的可执行文件，shell进程都能获取到（短暂的）root用户权限。之所以必须要运行su文件，而不是其他文件，就是因为su文件中的代码，能赋予shell进程持久性的root用户权限。
1.4 su中代码赋予shell进程持久性的root用户权限
这里需要解读su源代码。
这里对su源码的关键内容解释如下：
（1）su检查当前进程的RUID，发现其等于AID_SHELL，故允许继续执行
（AID_SHELL也就是Shell用户的UID）
su会检查当前进程的RUID，只有当其是Root用户的UID或Shell用户的UID时，才允许继续执行。
uid_t current_uid = getuid(); //返回当前进程的RUID
if (current_uid != AID_ROOT && current_uid != AID_SHELL)
error(1, 0, "not allowed");
对于app发起的shell进程而言，其RUID并不因su文件的rws权限位而变化（rws权限位只影响进程的EUID），所以shell进程的RUID仍是shell用户的UID，而不是root用户的UID。
所以，对于app发起的shell进程而言，这里能执行下去，是因为current_uid等于AID_SHELL，而不是current_uid等于AID_ROOT。
（2）su检查参数列表，发现无参数，故默认切换当前进程到root用户状态
su是Switch User的简写，用于各种用户切换，并不只用于切换到root用户状态。
根据su的源码，当su不加任何参数时，默认切换当前进程到uid = 0且gid = 0的状态，也就是root用户状态。
int main(int argc, char** argv) {
……
// The default user is root.
// 无参数时，默认切换到root
uid_t uid = 0;
gid_t gid = 0;
……
// If there are any arguments, the first argument is the uid/gid/supplementary groups.
// 有参数时，切换到参数argv指定的用户状态
if (*argv) {
……
// 从argv中提取内容，放入uid, gid, gids，覆盖之前uid和gid的默认值
extract_uidgids(*argv, &uid, &gid, gids, &gids_count);
……
++argv;
}
……
}
（3）su调用setuid函数，将当前shell进程的RUID，设置为root用户进程的UID
// 根据参数（或缺省默认值）设置当前进程的gid和uid
if (setgid(gid))
error(1, errno, "setgid failed");
if (setuid(uid))
// 由于当前shell进程的EUID为AID_ROOT，
// 所以这里的setuid(uid)，会按照setuid的情况(1)，
// 将当前shell进程的RUID，EUID和SUID均设置为uid
error(1, errno, "setuid failed");
这就是为什么su程序能让shell进程持久性地切换到root用户UID。
关于setuid函数，参考https://blog.csdn.net/qq_39441603/article/details/125013758
概括而言：
su文件的rws权限位，让当前的shell进程的EUID，成为了su所有者（Root用户）的UID，也就是AID_ROOT（也就是0）
所以，这里的setuid(uid)，会按照setuid的情况1，将当前进程的RUID，EUID和SUID都设置为uid，并返回0。由于无参数，所以这里的uid是缺省值AID_ROOT。
如果当前的shell进程的EUID!=AID_ROOT，则属于情况2（当进程的SUID==AID_ROOT时）或情况3（当进程的SUID!=AID_ROOT时），则setuid(uid)至多只影响当前shell进程的EUID，而不影响其RUID和SUID
之后，shell进程会继续执行完su程序。su程序执行完毕后，shell进程的RUID，EUID和SUID均为AID_ROOT，意味着shell进程获得了持久性的Root用户权限。
二、su源码完整解读
下面给出su程序源码的完整解读。
部分参考：https://zhuanlan.zhihu.com/p/47661378
2.1 Android版本
以android-12.0.0_r3为例：
源码参考：http://aospxref.com/android-12.0.0_r3/
2.2 su 二进制&源码位置
su二进制文件一般在/system/bin 目录或/system/xbin 目录
编译安卓系统源代码时，编译好的su二进制文件在/out/target/product/<vendor>/system/xbin中，
但system.img镜像文件中没有su二进制文件。
su的源代码在/system/extras/su 目录下：
http://aospxref.com/android-12.0.0_r3/xref/system/extras/su/
2.3 su 源码分析（带注释）
Android.mk：
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_CFLAGS := -Wall -Werror
LOCAL_SRC_FILES:= su.cpp
LOCAL_MODULE:= su
LOCAL_LICENSE_KINDS:= SPDX-license-identifier-Apache-2.0
LOCAL_LICENSE_CONDITIONS:= notice
LOCAL_NOTICE_FILE:= $(LOCAL_PATH)/NOTICE
LOCAL_HEADER_LIBRARIES := libcutils_headers
LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLES)
include $(BUILD_EXECUTABLE)
su.cpp源码：
#include <errno.h>
#include <error.h>
#include <getopt.h>
#include <paths.h>
#include <pwd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <private/android_filesystem_config.h>
// 根据用户名获取uid和gid
void pwtoid(const char* tok, uid_t* uid, gid_t* gid) {
// 根据用户名获取用户登录信息
struct passwd* pw = getpwnam(tok);
if (pw) {
if (uid) *uid = pw->pw_uid;
if (gid) *gid = pw->pw_gid;
} else {
char* end;
errno = 0;
uid_t tmpid = strtoul(tok, &end, 10);
if (errno != 0 || end == tok) error(1, errno, "invalid uid/gid '%s'", tok);
if (uid) *uid = tmpid;
if (gid) *gid = tmpid;
}
}
// 调用pwtoid，根据用户名获取uid和gid
// arg1: main的argv[0]（逗号分隔）
void extract_uidgids(const char* uidgids, uid_t* uid, gid_t* gid, gid_t* gids, int* gids_count) {
char *clobberablegids;
char *nexttok;
char *tok;
int gids_found;
if (!uidgids || !*uidgids) {
*gid = *uid = 0;
*gids_count = 0;
return;
}
clobberablegids = strdup(uidgids);
strcpy(clobberablegids, uidgids);
nexttok = clobberablegids;
tok = strsep(&nexttok, ",");
pwtoid(tok, uid, gid);
tok = strsep(&nexttok, ",");
if (!tok) {
/* gid is already set above */
*gids_count = 0;
free(clobberablegids);
return;
}
pwtoid(tok, NULL, gid);
gids_found = 0;
while ((gids_found < *gids_count) && (tok = strsep(&nexttok, ","))) {
pwtoid(tok, NULL, gids);
gids_found++;
gids++;
}
if (nexttok && gids_found == *gids_count) {
fprintf(stderr, "too many group ids\n");
}
*gids_count = gids_found;
free(clobberablegids);
}
// su的用法：
// su [WHO [COMMAND...]]
// WHO：要切换到的用户，默认为root，逗号分隔
// COMMAND：切换到WHO之后要执行的命令
int main(int argc, char** argv) {
uid_t current_uid = getuid(); //返回当前进程的RUID
// 当前进程的RUID必须是root用户UID 或shell用户UID
// 关于shell用户：
// 安卓app 获取shell权限时，通常使用：
// Process p = Runtime.getRuntime().exec("su");
// 这里的Runtime.getRuntime().exec，
// 底层原理是调用操作系统接口，新建一个shell进程异步执行命令
if (current_uid != AID_ROOT && current_uid != AID_SHELL) error(1, 0, "not allowed");
// Handle -h and --help.
++argv;
if (*argv && (strcmp(*argv, "--help") == 0 || strcmp(*argv, "-h") == 0)) {
fprintf(stderr,
"usage: su [WHO [COMMAND...]]\n"
"\n"
"Switch to WHO (default 'root') and run the given COMMAND (default sh).\n"
"\n"
"WHO is a comma-separated list of user, group, and supplementary groups\n"
"in that order.\n"
"\n");
return 0;
}
// The default user is root.
// 无参数时，默认切换到root
uid_t uid = 0;
gid_t gid = 0;
// su的核心部分：由setgroups、setgid、setuid完成，设置当前进程的附加组、gid和uid
// If there are any arguments, the first argument is the uid/gid/supplementary groups.
// 有参数时，切换到参数argv指定的用户状态
if (*argv) {
gid_t gids[10];
int gids_count = sizeof(gids)/sizeof(gids[0]);
// 从argv中提取内容，放入uid, gid, gids，覆盖之前uid和gid的默认值
extract_uidgids(*argv, &uid, &gid, gids, &gids_count);
// 根据参数 设置当前进程的附加组
if (gids_count) {
// int setgroups(size_t size, const gid_t * list);
// setgroups()用来 将 当前进程的附加组 设置为 参数2 list数组中所标明的group
// setgroups()参数1 size 为list数组的gid_t 数目, 最大值为NGROUP(32)
if (setgroups(gids_count, gids)) {
error(1, errno, "setgroups failed");
}
}
++argv;
}
// 根据参数（或缺省默认值）设置当前进程的gid和uid
if (setgid(gid))
error(1, errno, "setgid failed");
if (setuid(uid))
// 由于当前shell进程的EUID为AID_ROOT，
// 所以这里的setuid(uid)，会按照setuid的情况(1)，
// 将当前shell进程的RUID，EUID和SUID均设置为uid
// 否则按照情况(2)或情况(3)，至多只影响当前进程的EUID
error(1, errno, "setuid failed");
// Reset parts of the environment.
setenv("PATH", _PATH_DEFPATH, 1);
unsetenv("IFS");
struct passwd* pw = getpwuid(uid);
if (pw) {
setenv("LOGNAME", pw->pw_name, 1);
setenv("USER", pw->pw_name, 1);
} else {
unsetenv("LOGNAME");
unsetenv("USER");
}
// Set up the arguments for exec.
char* exec_args[argc + 1]; // Having too much space is fine.
size_t i = 0;
for (; *argv != NULL; ++i) {
exec_args[i] = *argv++;
}
// Default to the standard shell.
if (i == 0) exec_args[i++] = const_cast<char*>("/system/bin/sh");
exec_args[i] = NULL;
execvp(exec_args[0], exec_args);
error(1, errno, "failed to exec %s", exec_args[0]);
}
关于Supplementary group（附加组）：
参见：https://blog.csdn.net/qq_39441603/article/details/125010004
三、su daemon 模式
上述方案的核心是在 $PATH 环境变量(例如/system/bin:/system/xbin:/sbin:/vendor/bin:/vendor/xbin)下放置su可执行文件，并给su文件以suid权限。
然而从Android 4.3开始，很多分区（例如/system 和 /data）在一开始挂载时就被设置为nosuid，因此上述方案自然行不通。
如果直接观察 su 文件的权限，也是正常的0755权限，并没有suid位：
所以一个可行的方案是，在设备启动时由init进程开启一个su daemon 守护进程，当有程序调用su时，就作为client与这个server通信，由远程的server完成所有操作。由于init进程具有天然的root权限，由它 fork 出的su daemon自然也是root身份，这就实现了提权。
参考：《Android su提权的简单实现》
https://www.jianshu.com/p/6bc251ee9026
四、Android系统对app进程root权限的进一步限制
（1）在 Android 4.3 之前，app进程 可以直接借助 有SUID标志位的su二进制文件 来获取root用户权限。
（2）Android 4.3之后，app进程基于SUID获取root权限的方案被禁用。主要措施是：
- /system 和 /data 分区以 nosuid option被挂载，让文件的SUID标识失效。
- app进程是由zygote 进程 fork产生的。zygote进程设置了NO_NEW_PRIVS标志，父进程的NO_NEW_PRIVS位会在父进程fork、clone和execve时，被子进程继承 ，并且不能被撤销。NO_NEW_PRIVS标志会让当前进程在执行可执行文件时，进程的EUID和EGID不受可执行文件的SUID和SGID位影响。
关于zygote进程fork出app进程的过程
参考：https://www.toutiao.com/article/6777894692462789124/
Android 4.3之后，/system 分区也被以 nosuid option被挂载；
那么，系统进程如何获取root权限呢？
app进程是否可以使用同样的方式呢？
（3）系统进程改用 Capability来获取root权限，但app进程不行。
-
系统daemon可通过可执行文件的capability来获取进程的cap_effective，
-
但app进程不能这样做，因为app进程是由zygote 进程fork出来的；而zygote进程设置了NO_NEW_PRIVS标志，使得app进程无法通过可执行文件的capability来获取cap_effective。
P’(ambient) = (file is privileged) ? 0 : P(ambient)
P’(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding))) | P’(ambient)
P’(effective) = F(effective) ? P’(permitted) : P’(ambient)
也就是：
P’(effective) = F(effective) ? ( (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding))) | ( (file is privileged) ? 0 : P(ambient) ) ) : ( (file is privileged) ? 0 : P(ambient) )NO_NEW_PRIVS标志会使SUID和SGID位无法改变进程的 uid 或 gid，file capability也不会被添加到进程的capability中。也就是NO_NEW_PRIVS标志会使获取root权限的 SUID方案和file capability方案 失效。
参考：https://www.kernel.org/doc/html/latest/translations/zh_CN/userspace-api/no_new_privs.html
（4）对app进程切换EUID的其他限制：
- 仅当进程的cap_bset数组中有 SETUID/SETGID capability时，进程才能切换 UID。而从Android 4.4开始，zygote fork app进程时，会对所有fork出来的子进程进行CAPBSET_DROP动作，让子进程不具有任何capability。
- 从Android Oreo开始，OS通过SECCOMP过滤器阻止某些SYSCALL，app进程更改UID/GID的能力被进一步抑制。
（5）SELinux带来的约束
即使一个进程的euid变成了0，或者拥有了所有capability， 它也必须受到SELinux策略的约束。
也就是，SELinux机制进一步约束了root权限进程的行为。
五、Android设备 具体root方案
前文已述，一个shell进程，要想获得root权限，需要执行下列代码：
cp /data/local/tmp/su /system/bin/ #copy su 到/system/分区
chown root:root su #su的所有者置成root
chmod 4775 /system/bin/su #把su置成-rwsr-xr-x
但问题是，上面的每一行代码，都需要root用户权限才能执行。
而上述代码本身就是用于获取root用户权限的。所以再执行上述代码之前，普通app发起的进程，是无法获取root用户权限的。
那么这个逻辑闭环如何打破呢？这就需要root技术。
5.1 使用提权漏洞
一个办法是，找一个本身有root权限的进程来执行上述代码。这样普通app执行process = Runtime.getRuntime().exec("su");就能获得root权限了。
但是，有root权限的进程，都是预装app发起的，代码写死了，普通app没法控制它去执行特定的代码。
这个时候就需要用提权漏洞，来root手机。比如zergRush漏洞，就利用了一个拥有root权限的进程的栈溢出漏洞。
5.2 修改ROM并刷机
（1）BootLoader：
引导加载程序BootLoader是系统启动时自动运行的一个底层程序。
程序的主要目的是初始化硬件，然后找到并启动主操作系统。
Android bootloader一般是锁定的,也就仅仅允许启动或安装一个被OEM签名的操作系统img。
（2）Fastboot：
Fastboot是一种手机状态的名称，也是一个协议的名称。
当手机处于快速启动模式（Fastboot模式）时，若PC与手机通过USB连接，则两者可通过Fastboot协议进行通信。
具体而言，PC上的fastboot命令行工具，通过USB bulk，与手机上的USB Client通信。
PC上的fastboot命令行工具：位于Android SDK中
手机上的USB Client：Bootloader
Fastboot最初的作用是向BootLoader发送分区镜像，来将镜像写入到特定的设备分区中，实现分区清除或者覆盖，以方便Android系统移植（device bring-up）和设备恢复出厂设置。
但是现在，Fastboot多被用于解锁Bootloader。
（3）Recovery：
功能相当于PC中的PE。
用于存放Recovery恢复模式的分区，里面有一套Linux Kernel，但并不是安卓系统里的那个Linux Kernel。
分为原生Recovery和定制Recovery（例如TWRP提供的Recovery）。
（4）Boot：
启动顺序在bootloader之后，与recovery同级。
用于存放安卓系统的Linux Kernel相关内容。
可以参考：
https://blog.csdn.net/fmc088/article/details/90376116
5.2.1 Magisk patch boot.img，fastboot 刷入 patched boot.img（线刷）
整体思路：
用Magisk app 对 ROM的boot.img进行patch，并将patched boot.img存放至PC；
手机重启进入Fastboot；
使用PC上Fastboot工具，通过数据线，将patched boot.img刷入手机。
可以参见：
https://blog.csdn.net/qq_39441603/article/details/124679514
（1）解BootLoader锁
未解锁的BootLoader，不允许刷入非官方签名过的img镜像（包括Recovery.img，Boot.img等）
解锁之后，就可以通过PC上的fastboot程序，刷入Magisk patch过的boot.img
（2）Magisk对boot.img进行patch
获取到当前OS的线刷包的boot.img后，使用Magisk app对boot.img进行patch。
线刷包通常是tgz格式，例如https://xiaomirom.com/download/mi-8-dipper-weekly-9.8.22/#china-fastboot。
Magisk对boot.img进行patch的过程：Magisk通过对boot.img的patch，在boot启动阶段创建钩子，把/data/magisk.img挂载到/magisk，构建出一个在 system 基础上能够自定义替换，增加以及删除的文件系统。
所有操作都在启动时完成，实际上并不修改/system(即所谓systemless方案，以不触动 /system 的方式修改 /system)。/magisk相当于android系统的另一个独立分区。
（3）fastboot 刷入 patched boot.img
重启进入fastboot，并使用PC上的Fastboot命令行工具，通过USB bulk，基于fastboot协议，与手机上的USB Client通信，刷入 patched boot.img
adb reboot bootloader
fastboot flash boot magisk_patched-22100_LMHbQ.img
fastboot reboot
5.2.2 TWRP刷入第三方Recovery + Magisk.zip
详细过程可参考：
使用ADB Sideload方案：https://miuiver.com/install-magisk-via-twrp/
格式化整个Data分区方案：https://forum.butian.net/share/1068
（1）解BootLoader锁
（2）刷入定制Recovery
定制Recovery可从TWRP项目中获得
直接启动定制Recovery：fastboot boot custom-recovery.img
将定制Recovery永久写入设备：fastboot flash custom-recovery.img
将定制Recovery永久写入设备并启动：fastboot flash boot custom-recovery.img
（3）借助定制Recovery刷入Magisk.zip
从界面中的Log来看，好像是，在这个Magisk.zip的刷入过程中，Magisk会去patch boot.img：
使用ADB Sideload：
格式化整个Data分区：
线刷和卡刷区别主要在于：
线刷没动Recovery，在Fastboot模式下手，刷入Magisk app提前patch好的boot.img；
卡刷动了Recovery，在Recovery模式下手，通过customized Recovery来修改boot.img。
六、Magisk原理
参考：https://www.zhihu.com/question/278585502
Magisk的原理，大致是通过修改boot分区，使得手机在启动时，systemless中的文件先作为系统文件加载，然后才加载真正的系统，达到了不修改system分区而实现修改的效果。
比如修改机型或是字体，只需要安装并启用相应的模块，模块存放在systemless里面，就会在手机启动时生效；又因为system分区本身并没有被修改，只需要禁用模块就可以还原，无需备份原有的配置；
而root，也就是把root相关的一些文件放在systemless里，取代掉手机系统原本的su文件（SuperSU就是直接修改system里的su文件，而magisk是把su放在systemless中，手机启动时取代系统原有su）
Magisk通过启动时在 boot 中创建钩子，把 /data/magisk.img 挂载到 /magisk，在 system 基础上构建出了一个能够自定义替换、增加以及删除的文件系统。所有操作都在启动的时候完成，实际上并没有对 /system 分区进行修改（即 systemless方案，以不触动 /system 的方式修改 /system）。
扫一扫
1939
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
