Android安全Android root原理及方案 | Magisk原理

Posted 2023-03-31 Jouzzy

一、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）。