破解android的root权限的本质是：在系统中加入一个任何用户都可能用于登陆的su命令。或者说替换掉系统中的su程序，因为系统中的默认su程序需要验证实际用户权限,只有root和 shell用户才有权运行系统默认的su程序，其他用户运行都会返回错误。而破解后的su将不检查实际用户权限，这样普通的用户也将可以运行su程序，也可以通过su程序将自己的权限提升。
root破解没有利用什么Linux内核漏洞（Linux内核不可能有这么大的漏洞存在）,可以理解成root破解就是在你系统中植入“木马su”，说它是“木马”一点儿都不为过，假如恶意程序在系统中运行也可以通过su来提升自己的权限的这样的结果将会是灾难性 的。所以一般情况下root过手机都会有一个SuperUser应用程序来让用户管理允许谁获得root权限，也算是给系统加了一层保险吧！
Android的应用程序入口肯定是Java程序。应用程序的启动者是由系统临时根据Androidmanifest.xml中定义的权限而创建的临时用户。而不像linux那样是使用登陆者的身份启动，从而使得进程具有登陆者的所有权限。这也是Android的安全机制之一。
新的权限机制也带来新的问题，Android给应用程序的权限是按功能来分，java虽然可以访问文件系统。但由于应用程序本身是临时用户启动，这个临时用户权限十分有限。因此诞生了<越狱/root机器>这样的产物。
其实root机器不是真正能让你的应用程序具有root权限。它原理就跟linux下的像sudo这样的命令。在系统的bin目录下放个su程序并且属主是root并有suid权限。则通过su执行的命令都具有Android root权限。
当然使用临时用户权限想把su拷贝的/system/bin目录并改属性并不是一件容易的事情。这里用到2个工具跟2个命令。
工具就是busybox。不熟悉的同学可以去网上google下。这个太有名了我就不多说了。把busybox拷贝到你有权限访问的目录然后给他赋予4755权限，你就可以用它做很多事了。
当然busybox不能提升权限，真正提升权限的是ratc这个程序，这个程序中一键root包里面可以找到，作用是rooting在adb的shell。
网上介绍Ratc的文章不多，它是rage against the cage 的缩写。是真正的提升权限的破解程序。虽然我没看过源代码，但估计是利用adb源代码部分内容来实现的，
原理估计跟模拟器使用adb shell登陆可以获得root shell差不多。（因为它运行需要adb连接才会成功）。
使用busybox前先运行ratc，这样运行busybox的UID将是0，也就是root。
首先把system目录改成可读性的：busybox mount -o remount,rw /system，
当然你还不能改下面的文件，因为system下文件的所有者都不是你。但你可以偷梁换柱把system下的目录给换掉。
使用命令Busybox mount -t tmpfs none /system/xbin，呵呵这下xbin目录你随便写了。
将su跟busybox弄过去cp /data/data/xxx/su /system/xbin。然后赋权限chmod 4755 /system/xbin/su。
然后使目录生效busybox --install -s /system/xbin，别忘善后busybox mount -o remount,ro /system去掉system可写。
这样只是临时的，只能用su跟busybox能执行一些原来系统没有权限执行的命令而已。当系统重启后/system/xbin又变为原来的文件。
真正要改系统的话需要自己写内核代码（相当于windows的驱动程序）。内核文件拥有所有权限。使用busybox命令insmod /data/data/xxx/xxx.ko装载内核文件，你想干嘛就可以干嘛了。
当然我们不是搞破解的没必要去改别人的机器，我们只是想让自己应用程序具有root权限而已。所以临时的su就可以了。
我们用c++写一个可执行文件。使用socket可以跟java的程序通讯。然后将需要使用root权限才能执行的代码放在c++程序里，然后java程序中创建新的su进程，
将c++程序带全路径作为参数1。启动后就可以通过socket调用c++函数去执行你想干的事了。最后程序执行完了别忘了善后busybox umount /system/xbin。
最后说说要注意的事情，如果机器已经拥有Android root权限的话就不需要做这些事情了，但root过的机器都有装有个权限管理的程序。会弹出对话框。但这个程序管理能力有限，如果不想让他弹出的话。也许可以通过改su文件名来解决。有兴趣的同学不妨试试。
--------------------------------------------------------------------------------------------------------------------------------------------------------
破解手机Root权限是比较简单及安全的，破解Root权限的原理就是在手机的/system/bin/或/system/xbin/目录下放置一个可执行文件“su”，这是一个二进制文件，仅仅在系统中置入这个“su”文件是不会给手机的软件或硬件造成任何故障。
下面的代码是android系统原版的su中的部分代码，可以看出只允许getuid()为AID_ROOT和AID_SHELL的进程可以使用su进行登陆。
也就是说，Android系统默认的su程序只能root和shell可以用运行su，这个是安全的。如果把这个限制拿掉，就是root破解了，获取了root权限。
/* Until we have something better, only root and the shell can use su. */
myuid = getuid();
if (myuid != AID_ROOT && myuid != AID_SHELL) {
fprintf(stderr,"su: uid %d not allowed to su\n", myuid);
return 1;
}
在Superuser(一个破解程序)这个android程序中的su不再有上面的一部分，这样任何进程都可以使用su进行登陆了。
还有一部分android程序要使用root权限可能的用法类似于（这个也是Superuser中的一部分代码）：
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();
而在上面提到的Superuser和android原生的su源码中都有这部分代码：
if(setgid(gid) || setuid(uid)) {
fprintf(stderr,"su: permission denied\n");
return 1;
}
从出上面的分析可以认为破解android的root权限的实质是：在系统中加入一个任何用户都可能用于登陆的su命令。当然这首先要取得root权限才能做到。
在z4root这个android下的破解android的root权限的程序中有一个rageagainstthecage，这就是破解的关键。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
root破解过程的终极目标是替换掉系统中的su程序。但是要想替换掉系统中su程序本身就是需要root权限的，怎样在root破 解过程中获得root权限，成为我们研究的重点了。
下面我们先清点一下我们需要破解系统情况，假设需要破解的Android系统具备如下条件：
1、可以通过adb连接到设备，一般意味着驱动程序已经安装。
2、但是adb获得用户权限是shell用户，而不是root。
要想理解root破解过程我们首先需要了解一下adb工具，SDK中包含adb(android debug briage)工具，设备端有adbd服务程序后台运行，为开发机的adb程序提供服务，adbd的权限，决定了adb的权限。
具体用户可查看/system/core/adb下的源码，查看 Android.mk你将会发现adb和adbd其实是一份代码，然后通过宏来编译。
查看adb.c的adb_main函数你将会发现adbd中有如下代码：
int adb_main(int is_daemon)
{
......
property_get("ro.secure", value, "");
if (strcmp(value, "1") == 0) {
// don't run as root if ro.secure is set...
secure = 1;
......
}
if (secure) {
......
setgid(AID_SHELL);
setuid(AID_SHELL);
......
}
}
从中我们可以看到adbd会检测系统的ro.secure属性，如果该属性为1则将会把自己的用户权限降级成shell用户。一般设备出厂的时候在/default.prop文件中都会有：
ro.secure=1
这样将会使adbd启动的时候自动降级成shell用户。
然后我们再介绍一下adbd在什么时候启动的呢？答案是在init.rc中配置的系统服务，由init进程启动。我们查看init.rc中有如下内容：
# adbd is controlled by the persist.service.adb.enable system property
service adbd /sbin/adbd
disabled
在init.rc中配置的系统服务启动的时候都是root权限（因为init进行是root权限，其子程序也是root）。由此我们可以知道在adbd程序在执行：
/* then switch user and group to "shell" */
setgid(AID_SHELL);
setuid(AID_SHELL);
代码之前都是root权限，只有执行这两句之后才变成shell权限的。这样我们就可以引出root破解过程中获得root权限的方法了，那就是让以上面setgid和setuid函数执行失败，也就是降级失败，那就继续在root权限下面运行了。
这其实利用了一个RageAgainstTheCage漏洞。这里面做一个简单说明：
1、出厂设置的ro.secure属性为1，则adbd也将运行在shell用户权限下；
2、adb工具创建的进程ratc也运行在shell用户权限下；
3、ratc一直创建子进程（ratc创建的子程序也将会运行在shell用户权限下），紧接着子程序退出，形成僵尸进程，占用shell用户的进程资源，直到到达shell用户的进程数为 RLIMIT_NPROC的时候（包括adbd、ratc及其子程序），这是ratc将会创建子进程失败。
这时候杀掉adbd，adbd进程因为是 Android系统服务，将会被Android系统自动重启，这时候ratc也在竞争产生子程序。在adbd程序执行上面setgid和setuid之 前，ratc已经创建了一个新的子进程，那么shell用户的进程限额已经达到，则adbd进程执行setgid和setuid将会失败。根据代码我们发 现失败之后adbd将会继续执行。
这样adbd进程将会运行在root权限下面了。
3、这时重新用adb连接设备，则adb将会运行在root权限下面了。
通过上面的介绍我们发现利用RageAgainstTheCage漏洞，可以使adbd获得root权限，也就是adb获得了root权限。
拿到root权限剩下的问题就好办了，复制破解之后的su程序到系统中，都是没有什么技术含量的事情了。
其实堵住adbd的这个漏洞其实也挺简单的：
/* then switch user and group to "shell" */
if (setgid(AID_SHELL) != 0) {
exit(1);
}
if (setuid(AID_SHELL) != 0) {
exit(1);
}
如果发现setgid和setuid函数执行失败，则adbd进程异常退出，就把这个漏洞给堵上了。
为什么这么多设备都没有堵上这个漏洞呢？我觉得是设备厂商的策略，虽然知道怎么封堵漏洞但是就是留着个后门给大家，让第三方给自己定制 rom，提高自己系统的易用性。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
去年的Android adb setuid提权漏洞被用于各类root刷机，漏洞发现人Sebastian Krahmer公布的利用工具RageAgainstTheCage（rageagainstthecage-arm5.bin）被用于z4root等提权工具、Trojan.Android.Rootcager等恶意代码之中。下面我们来分析这一漏洞的产生原因。
The Android Exploid Crew小组在后来发布了一份PoC代码：rageagainstthecage.c。从这份代码开始着手。
在main(:72)函数中，首先获取了RLIMIT_NPROC的值(:83)，这个值是Linux内核中定义的每个用户可以运行的最大进程数。
然后，调用find_adb()函数(:94)来搜索Android系统中adb进程的PID，具体而言，该函数读取每个进程对应的文件的/proc//cmdline，根据其是否等于”/sbin/adb”来判断是否adb进程。
接下来，fork了一个新的进程(:109)，父进程退出，而子进程继续。接下来，在113行创建一个管道。
rageagainstthecage.c
代碼:
if (fork() > 0)
exit(0);
setsid();
pipe(pepe);
重头戏发生在下面的122到138行，代码如下：
rageagainstthecage.c
代碼:if (fork() == 0) {
close(pepe[0]);
for (;;) {
if ((p = fork()) == 0) {
exit(0);
} else if (p < 0) {
if (new_pids) {
printf("\n[+] Forked %d childs.\n", pids);
new_pids = 0;
write(pepe[1], &c, 1);
close(pepe[1]);
}
} else {
++pids;
}
}
}
新建一个进程后，在子进程之中，exploit代码不断地fork()(:125)，而新的子进程不断退出，从而产生大量的僵尸进程（占据shell用户的进程数）。
最终，进程数达到上限，fork()返回小于0，于是打印当前已经创建多少子进程，并向管道输入一个字符（:131）。
在这里，管道的作用是和(:122)fork出来的父进程同步，该进程在141行read这一管道，因而阻塞直至僵尸进程已经达到上限(:131)。
进一步的，exploit杀掉adb进程，并在系统检测到这一现象并重启一个adb之前，再一次fork()，将前一个adb留下的进程空位占据。
最后，在152行，exploit调用wait_for_root_adb()，等待系统重启一个adb，这个新建的adb就会具有root权限。
为什么在shell用户的进程数达到上限RLIMIT_NPROC以后，新建的adb会具有root权限？我们来看adb的源码。
在/system/core/adb/adb.c的第918行，我们可以看到如下代码：
android_src/system/core/adb/adb.c
代碼:/* then switch user and group to "shell" */
if (setgid(AID_SHELL) != 0) {
exit(1);
}
if (setuid(AID_SHELL) != 0) {
exit(1);
}
这已经是漏洞修补以后的代码。在漏洞最初被发现时，代码如下：
android_src/system/core/adb/adb.c
代碼:/* then switch user and group to "shell" */
setgid(AID_SHELL);
setuid(AID_SHELL);
简而言之，原来没有检查setuid()函数的返回值。事实上，在此之前，adb.c中的代码都是以root权限运行，以完成部分初始化工作。
在这一行，通过调用setuid()将用户从root切换回shell，但setuid()在shell用户进程数达到上限RLIMIT_NPROC时，会失败，因此adb.c继续以root身份运行，而没有报错。
我们来看setuid()的man手册（man 2 setuid），其中有如下说明：
man 2 setuid
代碼:RETURN VALUE
On success, zero is returned. On error, -1 is returned, and errno is
set appropriately.
ERRORS
EAGAIN The uid does not match the current uid and uid brings process
over its RLIMIT_NPROC resource limit.
可以看到，setuid是可能发生错误的，并且在uid的进程数超过RLIMIT_NPROC极限时，发生EAGAIN错误。
在android的源码中，setuid()定义于/bionic/libc/unistd/setuid.c，实际上引用了一个外部符号__setuid，
这个符号在/bionic/libc/arch_xxx/syscalls/__setuid.S中定义，最终是一个%eax=$__NR_setuid32，%ebx=uid的int 0×80中断。
因为只是要分析原理，我们不再鏖战于Android，转而看向Linux内核。
在最新的kernel2.6中，setuid()位于kernel/sys.c的682行，其中，在697行，一切正常的情况下，它会调用set_user()来完成用户切换。
set_user()实现于同一文件的587行，其中一部分代码如下：
kernel/sys.c
代碼:if (atomic_read(&new_user->processes) >= rlimit(RLIMIT_NPROC) &&
new_user != INIT_USER) {
free_uid(new_user);
return -EAGAIN;
}
含义很明显，当目标用户的进程数达到上限，那系统就不能再将一个进程分配给它，因而返回-EAGEIN。然后再setuid()中，直接跳过后面的代码，而返回错误。
至此，整个漏洞的原理已经分析完毕。整理如下：
1、在Android的shell用户下，制造大量的僵尸进程，直至达到shell用户的进程数上限RLIMIT_NPROC；
2、kill当前系统中的adb进程，并再次占据其进程位置以保持达到上限；
3、系统会在一段时间后重启一个adb进程，该进程最初是root用户，在完成少许初始化工作后，调用setuid()切换至shell用户；
4、此时shell用户的进程数已经达到上限，所以setuid()失败，返回-1，并且用户更换没有完成，adb还是root权限；
5、adb没有检查setuid()的返回值，继续后续的工作，因此产生了一个具有root权限的adb进程，可以被用于与用户的下一步交互。
实际上，setuid在目标用户进程数达到RLIMIT_NPROC极限时返回错误，这一问题可能产生的安全隐患最早可以追溯到2000年。而在2006年，出现了真正利用这一编码问题的漏洞（CVE-2006-2607）。
因此，这并不是一个全新的漏洞。我们可以得出几点结论：
1、函数返回值一直是忽略的对象，因为getuid()永远不会失败，程序员可能会认为setuid()也不会失败——至少没有遇到过，因此忽略了对返回值的检查。检查一个系统函数是否调用失败是一个常识，但又是很麻烦的事，如果为了省事而忽略，问题就可能产生了。
2、Android下的安全问题，很多并非全新的，而且个人判断将来还会有大量漏洞、恶意代码产生于传统思路，而作用于新的平台。面对这一新的平台，我们是否能抢先于攻击者做好防范准备，是一个需要我们思考和实践的问题。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
写这篇文章前，首先要感谢 ，他的两篇关于 root 权限的文章对于我的工作起到了非常大的帮助，这篇文章可以说是对他的文章的一个补充。 Simon_fu 的文章可以参考如下两个网页：
一般来说， Android 下的应用程序可以“直接”得到的最大的权限为 system ，但是如果我们需要在程序中执行某些需要 root 权限的命令，如 ifconfig 等，就需要 root 权限了。按照 Simon 的文章中提到的，应用程序有以下两种办法临时获得 root 权限：
1) 实现一个 init 实现一个 Service ，来帮助 Android 应用程序执行 root 权限的命令。
2) 实现一个虚拟设备，这个设备帮助 Android 应用程序执行 root 权限的命令。
第二种办法我这里没有尝试，暂时也不会。这里讲讲我在实现第一种办法的过程和遇到的一些问题。
1. 将我们要执行的命令写成脚本，或者可执行程序。
下面是我的脚本 ifconfig_test.sh ：
# ！ /system/bin/sh
ifconfig
注意： 脚本的第一行必须为 # ！ /system/bin/sh ，否则无法执行，通过 dmesg 可以查看到信息内容为cannot execve ./ifconfig_test.sh: Exec format error
也可以采用 C/C++ 编写需要执行的命令或者程序，并在编译 image 的时候编译成可执行程序。
2. 在 init.rc 中注册 service
Android 中的 service 需要在 init.rc 中注册， Init.rc 中定义的 Service 将会被 init 进程创建，这样将可以获得root 权限。当得到相应的通知（通过属性设置）后， init 进程会启动该 service 。
本文中注册的内容如下：
service ifconfig_test /system/etc/ifconfig_test.sh
oneshot
disabled
其中， oneshot 表示程序退出后不再重新启动， disabled 表示不在系统启动时启动。
注意： 这里 service name 不能超过 16 个字符。我之前的 service name 由于定义的比较长， 18 个字符，设置属性通知 service 启动后查看 dmesg 可以看到提示： init: no such service 。查看 /system/core/init/parser.c的源代码，在 parse_service->valid_name 函数中可以看到如下内容： if (strlen(name) > 16) { return 0; } ，证明 service 的名字的确不能超过 16 个字符。
3. 将 Android 应用程序提升为 system 权限
既然应用程序可以通过启动 service 获得 root 权限，那么岂不是很不安全。 Android 考虑到了这点，规定只有 system 权限的应用程序才能设置属性，通知 service 启动。关于提升 system 权限的文章网上已有很多，这里就不再细说，可以参考如下两篇文章：
http://blog.csdn.net/liujian885/archive/2010/03/22/5404834.aspx
http://labs.chinamobile.com/mblog/532767_73183
4. 在应用程序中添加属性设置代码
前面已经提到，对于 Android 来说，应用程序通知 init 启动 service 是通过设置系统属性来完成的，具体为设置 System 系统属性 “ctl.start” 为 “ifconfig_test” ，这样 Android 系统将会帮我们运行 ifconfig_test 这个service 了。
对该系统属性的设置有三种方法，分别对应三种不同的应用程序：
1) Java 代码
Android 在 Java 库中提供 System.getProperty 和 System.setProperty 方法， Java 程序可以通过他们来设置和获得属性。代码如下：
SystemProperties.set("ctl.start", "ifconfig_test");
上面的代码是通知 Android 执行 ifconfig_test service ，如果需要查询当前 service 执行的状态，如是否执行完毕，可以通过如下代码查询：
ret = SystemProperties.get("init.svc. ifconfig_test ", "");
if(ret != null && ret.equals("stopped"))
{
return true;
}
2） JNI 代码
当编写 NDK 的程序时，可以使用 property_get 和 property_set 这两个 API 来获得和设置属性。使用这两个API 必须要包含头文件 cutils/properties.h 和链接 libcutil 库。
3） Shell 脚本
Android 提供了命令行 setprop 和 getprop 来设置和获取属性，他们可以在脚本中被使用。
由于我的程序是在 JNI 中调用脚本，脚本中又执行 ifconfig ，因此我将设置属性的部分放在了脚本中完成，代码如下：
setprop ctl.start ifconfig_test
#wait for the service until it stops
ret=1
while [ $ret -ne 0 ]
do
getprop | grep "$ENABLE_MAPPER_SRV" | grep stopped
ret=$?
done
通过上面 4 个步骤， Android 应用程序就获得了 root 权限，更具体的说，是在执行我们需要执行的命令时临时获得了 root 权限。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Android 下应用程序不能直接 获得 root 权限，因此如果需要修改 /sys 或 /proc 等目录下的文件时，有以下两种方法可以选择：
-
通过 service 或虚拟设备的方法将使得应用程序临时 获得 root 权限
-
对 /sys 或 /proc 目录下的文件修改访问权限，使得它们能够被程序访问
对于方法 1 ，可以参看我后续会写到的一篇文章《如何使 Android 应用程序获得 root 权限》，也可以在网上搜索别的相关文章。
这里讲讲方法 2 。
为了理解方法 2 ，首先要知道 Android 上的权限机制。 Android 会为每个安装在系统上的包（ apk ）配一个唯一的 linux userID ，名称为 "app_" 加一个数字，比如 app_43 。这样该应用程序的文件只对该用户可见，也就是说，应用程序只能访问相同 uid 和 gid 的文件。
另外，也可以通过 AndroidManifest.xml 修改应用程序的 uid 。如果将 android:sharedUserId 项的值改为其它 apk 的 java package name ，则该应用程序和所指定的应用程序拥有相同的 uid ，可以访问对方的文件。
通过 android:sharedUserId 还可以将应用程序提升为 system 权限。
有了上面的知识，这里有三种方法来修改我们所要访问的文件：
-
将文件改为 777 权限
-
将文件改为 apk 的 uid 和 gid
-
将文件修改为 system 的 uid ，同时将 apk 也提升为 system 权限
这三种方法都需要修改所要访问系统文件的权限。要更改权限，在 init.rc 文件中添加相应的命令即可。下述命令就将 /dev/cpuctl/tasks 修改为 system 的 uid 和 gid ，并且将其权限更改为 777 。
chown system system /dev/cpuctl/tasks
chmod 0777 /dev/cpuctl/tasks
修改 init.rc 该文件需要修改 ramdisk.img ，具体修改方法可以网上搜索，也可以参看这篇文章最后的附录。或者在源代码中直接修改 init.rc 文件然后编译即可。
下面依次分析一下上面提到的三种修改访问文件的方法。第一种方法是最简单的，不过安全性不好，仅仅可以作为实验使用，不推荐；第二种方法将系统文件文件的 uid 修改后，拓展性不好，并且我不能确定每次分配给apk 的 uid 是否相同。我这里试了几次，重新安装后 apk 的 uid 都是相同的，不过没有找到相关文章，所以不敢用。最后我这里采用第三种方法实现。
1）首先修改 init.rc
chown system system /sys/bus/usb/devices/testfile
这样每次启动后，系统都会执行 init.rc 文件将 testfile 的 uid 修改为 system ，这样 uid 同问 system 的程序就能够访问该文件了。
2） 其次将 apk 提升为 system 权限
将 apk 提升为 system 权限需要目标系统中的签名文件对 apk 进行签名，因此这种方法仅适用于某个 rom ，不能用于所有 rom 。
具体的提升办法网上有很多，这里不再多说，可以参考这两篇文章：
http://blog.csdn.net/liujian885/archive/2010/03/22/5404834.aspx
http://labs.chinamobile.com/mblog/532767_73183
至此，我们的目标就达成了。
附 修改 ramdisk.img 的方法
在网上找到了一些修改 ramdisk.img 的方法，都有点问题，我这里写一下自己的流程。由于 ramdisk.img 是首先用 cpio 打包，再用 gzip 压缩后的文件，因此在解压和压缩时都需要经历这两个步骤。
1） mv ramdisk.img ramdisk.img.gz
2） gunzip ramdisk.img.gz #gunzip 解压得到 ramdisk.gz
3） cpio –iI ramdisk.gz # 用 cpio 解压上一步得到的文件
4） 修改 init.rc
5） find. | cpio –o –H newc | gzip -9 > ramdisk.gz #cpio 打包后， gzip 再压缩
6） mv ramdisk.gz ramdisk.img
