Android root 原理
本帖最后由 java 于 2018-7-17 18:02 编辑Android 获取ROOT权限原理解析
https://blog.csdn.net/chaihuasong/article/details/8463212/
一、 概述本文介绍了android中获取root权限的方法以及原理，让大家对android玩家中常说的“越狱”有一个更深层次的认识。 二、 Root的介绍1. Root 的目的可以让我们拥有掌控手机系统的权限，比如删除一些system/app下面的无用软件，更换开关机铃声和动画，拦截状态栏弹出的广告等。2. Root的原理介绍谷歌的android系统管理员用户就叫做root，该帐户拥有整个系统至高无上的权利，它可以访问和修改你手机几乎所有的文件，只有root才具备最高级别的管理权限。我们root手机的过程也就是获得手机最高使用权限的过程。同时为了防止不良软件也取得root用户的权限，当我们在root的过程中，还会给系统装一个程序，用来作为运行提示，由用户来决定，是否给予最高权限。这个程序的名字叫做Superuser.apk。当某些程序执行su指令想取得系统最高权限的时候，Superuser就会自动启动，拦截该动作并作出询问，当用户认为该程序可以安全使用的时候，那么我们就选择允许，否则，可以禁止该程序继续取得最高权限。Root的过程其实就是把su文件放到/system/bin/ Superuser.apk 放到system/app下面，还需要设置/system/bin/su可以让任意用户可运行，有set uid和set gid的权限。即要在android机器上运行命令：adb shell chmod 4755 /system/bin/su。而通常，厂商是不会允许我们随便这么去做的，我们就需要利用操作系统的各种漏洞，来完成这个过程。特别说明：我们烧机中的Eng版本并没有Root权限3. Root的方法从Root的原理我们了解到，root过程分三步：<font color="rgb(79, 79, 79)"><font face="-apple-system, ""><font style="font-size: 16px">a. adb push su /system/bin
b. adb push SuperUser.apk /system/app
c. adb shell chmod 4755 /system/bin/su
</font></font></font>若系统是eng版的，做到以上三步，那么我们Root就大功告成，但实际是不行的。为什么呢？原因有三：1、user版的/system路径是只读权限，不能简单写入2、 chmod需要Root权才能运行（死循环了）3、有些系统在启动时会自动将su的4755权限设成755，甚至直接删除su那么针对这种情况，我们怎么办呢？非常简单：烧一个eng版本的boot.img就行了可以用展讯的烧录工具，或者用fastboot模式从sd卡烧一个boot.img文件即可至此，我们Root就成功了，可以用R.E(Root Explorer)在根目录创建和删除文件。 三、 深入理解Root机制其流程是：<font color="rgb(79, 79, 79)"><font face="-apple-system, ""><font style="font-size: 16px">1. Su 被用户调用
2. Su 创建了一个socket监听
3. Su 向Superuser发送了一个广播，说是有一个程序要请求root
4. Su 等待socket 数据接收。有超时处理。
5. Superuser 界面收到广播后，弹出一个对话框，询问用户
6. Superuser 向传来的数据中的socket写回用户应答结果。
7. Su 根据socket得到的结果处理应该不应该继续执行
8. 完成提权管理
</font></font></font>superuser.apk这个程序是root成功后，专门用来管理root权限使用的，防止被恶意程序滥用。源码地址： http://superuser.googlecode.com/svn/trunk我们有两点疑问：1.superuser是怎么知道谁想用root权限？ 2.superuser是如何把用户的选择告诉su程序的？即superuser和su程序是如何通讯的，他们俩位于不通的时空，一个在java虚拟中，一个在linux的真实进程中。superuser共有两个activity: SuperuserActivity和 SuperuserRequestActivity，其中SuperuserActivity主要是用来管理白名单的，就是记住哪个程序已经被允许使用root权限了，省的每次用时都问用户。SuperuserRequestActivity 就是用来询问用户目前有个程序想使用root权限，是否允许，是否一直允许，即放入白名单。这个白名单比较关键，是一个sqlite数据库文件，位置：/data/data/com.koushikdutta.superuser/databases/superuser.sqlite
上文说过，root的本质就是往 /system/bin/下放一个su文件，不检查调用者权限的su文件。普通程序可以调用该su来运行root权限的命令。superuser.apk中就自带了一个这样的su程序。一开始superuser会检测/system/bin/su是否存在:<font color="rgb(79, 79, 79)"><font face="-apple-system, ""><font style="font-size: 16px">File su = new File("/system/bin/su");
// 检测su文件是否存在,如果不存在则直接返回
if (!su.exists()){
Toast toast = Toast.makeText(this, "Unable to find /system/bin/su.", Toast.LENGTH_LONG);
toast.show();
return;
}
//如果大小一样，则认为su文件正确，直接返回了事。
if (su.length() == suStream.available())
{
suStream.close();
return; //
}
// 如果检测到/system/bin/su文件存在，但是不对头，则把自带的su先写到"/data/data/com.koushikdutta.superuser/su"
//再写到/system/bin/su。
byte[] bytes = new byte;
DataInputStream dis = new DataInputStream(suStream);
dis.readFully(bytes);
FileOutputStream suOutStream = new FileOutputStream("/data/data/com.koushikdutta.superuser/su");
suOutStream.write(bytes);
suOutStream.close();
Process process = Runtime.getRuntime().exec("su");
DataOutputStream os = new DataOutputStream(process.getOutputStream());
os.writeBytes("mount -oremount,rw /dev/block/mtdblock3 /system\n");
os.writeBytes("busybox cp /data/data/com.koushikdutta.superuser/su /system/bin/su\n");
os.writeBytes("busybox chown 0:0 /system/bin/su\n");
os.writeBytes("chmod 4755 /system/bin/su\n");
os.writeBytes("exit\n");
os.flush();
</font></font></font>有进程使用root权限，superuser是怎么知道的呢，关键是句：
<font color="rgb(79, 79, 79)"><font face="-apple-system, ""><font style="font-size: 16px">sprintf(sysCmd, "am start -a android.intent.action.MAIN
-n com.koushikdutta.superuser/com.koushikdutta.superuser.SuperuserRequestActivity
--ei uid %d --ei pid %d > /dev/null", g_puid, ppid);
if (system(sysCmd))
return executionFailure("am.");
</font></font></font>原理是am命令，am的用法：
<font color="rgb(79, 79, 79)"><font face="-apple-system, ""><font style="font-size: 16px"> usage: am
start an Activity: am start [-D] [-W] <INTENT>
-D: enable debugging
-W: wait for launch to complete
start a Service: am startservice <INTENT>
send a broadcast Intent: am broadcast <INTENT>
start an Instrumentation: am instrument <COMPONENT>
-r: print raw results (otherwise decode REPORT_KEY_STREAMRESULT)
-e <NAME> <VALUE>: set argument <NAME> to <VALUE>
-p <FILE>: write profiling data to <FILE>
-w: wait for instrumentation to finish before returning
start profiling: am profile <PROCESS> start <FILE>
stop profiling: am profile <PROCESS> stop
<INTENT> specifications include these flags:
[-a <ACTION>] [-d <DATA_URI>] [-t <MIME_TYPE>]
[-c <CATEGORY> [-c <CATEGORY>] ...]
[-e|--es <EXTRA_KEY> <EXTRA_STRING_VALUE> ...]
[--esn <EXTRA_KEY> ...]
[--ez <EXTRA_KEY> <EXTRA_BOOLEAN_VALUE> ...]
[-e|--ei <EXTRA_KEY> <EXTRA_INT_VALUE> ...]
[-n <COMPONENT>] [-f <FLAGS>]
[--grant-read-uri-permission] [--grant-write-uri-permission]
[--debug-log-resolution]
[--activity-brought-to-front] [--activity-clear-top]
[--activity-clear-when-task-reset] [--activity-exclude-from-recents]
[--activity-launched-from-history] [--activity-multiple-task]
[--activity-no-animation] [--activity-no-history]
[--activity-no-user-action] [--activity-previous-is-top]
[--activity-reorder-to-front] [--activity-reset-task-if-needed]
[--activity-single-top]
[--receiver-registered-only] [--receiver-replace-pending]
[<URI>]<span style="font-family:Calibri;font-size:14px;"> </span>
</font></font></font>还有个疑点，就是su怎么知道用户是允许root权限还是反对呢？原来是上面提到的白名单起来作用，superuser把用户的选择放入：
/data/data/com.koushikdutta.superuser/databases/superuser.sqlite 数据库中，然后su进程再去读该数据库来判断是否允许。<font color="rgb(79, 79, 79)"><font face="-apple-system, ""><font style="font-size: 16px">static int checkWhitelist()
{
sqlite3 *db;
int rc = sqlite3_open_v2(DBPATH, &db, SQLITE_OPEN_READWRITE, NULL);
if (!rc)
{
char *errorMessage;
char query;
sprintf(query, "select * from whitelist where _id=%d limit 1;", g_puid);
struct whitelistCallInfo callInfo;
callInfo.count = 0;
callInfo.db = db;
rc = sqlite3_exec(db, query, whitelistCallback, &callInfo, &errorMessage);
if (rc != SQLITE_OK)
{
sqlite3_close(db);
return 0;
}
sqlite3_close(db);
return callInfo.count;
}
sqlite3_close(db);
return 0;
}
</font></font></font>
C & C
四、 资源文件的获取从上文的源码地址获取源代码，替换系统的system/extras/su/下面的su.c和Android.mk文件，使用编译命令 ./mk td28 u adr system/extras/su/编译成功后会生成out/target/product/hsdroid/system/xbin/su文件，而Superuser.apk就是普通的apk文件，都在源码地址里面可以下载，下载后倒入到eclipse即可直接运行。 五、 总结在阅读完本文后，可以站在专业的角度了解root的真正原理，以及有用户有需求时我们可以帮助其快速的解决问题。
Android root 原理欢迎转载，转载请注明出处：http://www.cnblogs.com/lanrenxinxin/p/5572640.html0x00 关于root linux和类Unix系统的最初设计都是针对多用户的操作系统，对于用户权限的管理很非常严格的，而root用户（超级用户）就是整个系统的唯一管理员，拥有等同于操作系统的所有权限。所以一旦获取到root权限，就可以对整个系统进行访问和修改。而在Android下获取root权限之后就可以自己定制系统，卸载一些预装软件，完全掌控自己的设备。
0x01 setUID 在讨论root的原理之前，有一个非常重要的概念，就是文件的setUID权限。linux下普通的文件权限大家都很清楚，可读，可写，可执行，下图很清楚的一个普通的可执行文件root的权限，r（可读），w（可写），x（可执行）。https://images2015.cnblogs.com/blog/624196/201606/624196-20160612193130886-1321292695.png 但是，要考虑一种情况，比如说，一个用户是有权修改自己的密码的，但是记录密码的文件/etc/shadow只有root用户才是可写的，那普通用户如何才能修改自己的密码呢？这一切都要归功于setUID的设置，修改密码时使用的命令passwd对应的二进制程序是/usr/bin/passwdhttps://images2015.cnblogs.com/blog/624196/201606/624196-20160612194014105-616032278.png可以看到passwd的二进制文件的权限位中不仅仅是rwx了，多了一个s权限，而这个s权限就是我们的主角，setUID权限。由于passwd有setUID权限，所以linux系统可以临时把这个文件的所有者（root）身份角色赋给普通用户，以达到让普通用户可以修改自己密码的目的。那如何设置setUID权限呢？平常使用的普通文件权限位是由3、３、３共9位的二进制数字组成 －－－｜－－－｜－－－，分别对应文件所有者，文件所有者同一用户组权限和其他用户权限。最开始的名为root的可执行文件的权限为rwxrwxr-x，所对应的二进制位就是111 111 101 ，然后每三位对应421换算成16进制，就是775。而新增的setUID权限是在前面新增了三位，分别表示setGID、setUID、stick bit权限，而我们现在只关心setUID权限。因此加上setUID权限之后，文件的权限应该由4位数字组成，例如之前的root文件加上setUID权限就是4755。而修改密码的passwd文件对应的权限位就是4755。可以通过一个小例子来直观的感受一下，平常使用的cat命令对应的二进制文件是没有setUID权限的：https://images2015.cnblogs.com/blog/624196/201606/624196-20160612201852011-1688576101.png可以在普通用户下尝试使用cat去读取/etc/shadow文件的内容：https://images2015.cnblogs.com/blog/624196/201606/624196-20160612202038730-533686501.png提示权限不够，再给cat加上setUID权限之后再去读取/etc/shadow的内容：https://images2015.cnblogs.com/blog/624196/201606/624196-20160612202346793-23202773.png是可以读出来的，但是/etc/shadow中的内容都经过加密处理。
0x02 Linux 下的root平常使用的linux发行版，需要切换到root用户时，直接使用su命令，然后输入su用户的密码就可以切换到root用户了。https://images2015.cnblogs.com/blog/624196/201606/624196-20160609192815027-443851262.pnghttps://images2015.cnblogs.com/blog/624196/201606/624196-20160612200929949-1567953583.png
0x03 Android 的root但是在未root的Android设备上是没有su的二进制文件，直接执行su命令会提示"su not found"。https://images2015.cnblogs.com/blog/624196/201606/624196-20160609200227761-318532671.png 再进入已经root过的设备上查看，平常在adb shell中用的命令对应的二进制文件都是在/system/bin目录下，是存在su文件的：https://images2015.cnblogs.com/blog/624196/201606/624196-20160609195133699-2055442432.png可以看到这里的su只是一个指向/system/xbin/的一个链接。https://images2015.cnblogs.com/blog/624196/201606/624196-20160609194946074-419987031.png可以看到这里的su是有setUID权限位的。而要在系统分区 /system/xbin 中添加文件本身就是需要root权限，而且设置su文件的所有者为root用户也是需要root权限的，设置setUID权限同样也需要root权限。这就进入到了一个死循环当中，要利用su，首先要有root权限。因此这时就需要利用到Android存在的漏洞，Android系统本身存在着很多以root权限运行的原生进程，而这些root进程中如果存在可以利用的漏洞，就可以利用进程的root身份：
[*]拷贝su文件到/system/xbin系统分区；
[*]设置su文件所有者为root用户；
[*]设置su文件的setUID权限，便于自己的进程执行su命令获取root权限。
0x04 Android4.3 之后以上方法在Android4.3之前可行，也就是Android还未引入SELinux的版本。从Android4.3开始引入SELinux之后，加上system分区多被挂载为nosuid，也就是SetUid位无效。所以都采用的是 C/S 结构来进行root。
如果厂商对于设备的bootloader没有加锁或者可以解锁，是可以通过直接修改镜像刷入su文件来root的，Nexus系列都可以。但是国内厂商的bootloader基本都被锁死，一键root工具都是利用系统本身存在的漏洞来root，虽然google一直在修补漏洞，但是国内厂商更新不及时也可以进行利用。
页:
[1]