ROOT Android系统的设备一般和越狱Apple iOS系统的设备类似，都是为了获得整个设备任意区域的读写控制权，使得用户可以在任意区域读写文件，包括操作系统区域，ROOT Android系统即为能使普通用户获得ROOT权限使用该Android设备。
普通用户获得ROOT权限后使用Android设备可以帮助他们越过手机制造商的限制，也可以卸载手机制造商预装的应用程序，甚至可以替换该设备的操作系统(ROM)。但ROOT过的Android设备可能会因为误操作，应用软件的恶意行为导致设备不可用，甚至存储在设备中的个人隐私及财产遭受威胁等。
本文不会探讨ROOT设备随后带来的风险，而将会着重探讨多种ROOT技术的一种，深入浅出该技术是如何利用Android系统发布初adb setuid提权漏洞去ROOT设备的。
漏洞信息
CVE: CVE-2010-EASY
Affect: 2.2.3及之前，Fixed：2.3.6
漏洞代码： /system/core/adb/adb.c
/2.2.3/system/core/adb/adb.c adb_main
Image may be NSFW.
Clik here to view.
（代码1 2.2.3系统漏洞代码定位）
/2.3.6/system/core/adb/adb.c adb_main
Image may be NSFW.
Clik here to view.
（代码2 2.3.6修复之后的漏洞代码）
下述漏洞代码都基于2.2.3，修复之后的代码基于2.3.6。
众所周知，Android系统是基于Linux系统的，所以不管是利用Android系统原生漏洞还是手机制造商定制而出现的漏洞，ROOT技术万变不离其宗都是将su文件复制到Android系统/system/xbin目录下，将所有者更换成root用户，并用chmod命令设置为可执行权限和setuid(s)权限。
(1)可执行权限，即该文件可以被执行，包含所有用户都可以执行的权限，即755，命令为chmod 755后加文件名；
(2)setuid(s)权限，即该文件可以被任意用户以文件所有者的身份执行，比如一个文件的所有者是root用户，如果该文件具有setuid（s）权限，那么任意用户都可以运行它，并且是以root用户身份.执行ROOT操作时，su文件的所有者是root用户，但其因为被设置了setuid(s)权限，该文件可以被任意用户以root用户身份运行，命令为chmod 4755后加文件名。
adb工具原理及介绍
这个2010年出的漏洞是利用adb工具进行破解的，所以在此之前我们需要了解adb工具工作的原理：开发者拿到的Android SDK包含了adb工具，该adb工具其实包含了client端和server端，并且我们的设备端有adb的守护进程adbd程序在运行，当我们使用adb client向adb server发送命令时，adb server会连接设备的adbd程序，由adbd程序执行开发者传过来的命令。即我们开发者使用adb命令操控设备其实是透过协议将命令传递给adbd，由adbd替我们完成命令。
Image may be NSFW.
Clik here to view.
（图1 通过ps命令显示Android adbd进程）
从上述adb工具工作原理过程中，我们可以得知：
(1)adbd程序是由Android设备在开机时就应该准备好的，不难猜测这个adbd程序是通过配置rc中的系统服务由init进程开机自启动的，我们可以查看init.rc内容：
Image may be NSFW.
Clik here to view.
（图2 通过cat命令查看显示Android init.rc文件）
init.rc果然有adbd启动这一项，所以我们这个猜测是正确的。
(2)正如上述，我们在外部使用adb client最后都会被adbd程序运行，所以说adbd的进程权限决定了adb命令的权限。
但是配置在init.rc中程序有init进程启动之后应该都是以root身份运行的并且具备root权限，而我们从图一可以看出在未ROOT过的手机中adbd程序却是以shell身份运行的，对于Android系统设计者来说这是无可厚非的，因为这样可以避免使用adb直接以root身份操控设备，但这是怎么实现的呢？
adbd进程切换用户
Image may be NSFW.
Clik here to view.
（代码3 跟踪/2.2.3/system/core/adb/adb.c adb_main函数）
来，跟踪代码，发现adb_main函数会从default.prop中获取ro.secure值，并根据此值去做切换用户操作，如果ro.secure为1则切换，否则不予切换，事实上设备出厂的时候在/default.prop文件中都会有将ro.secure值置为1，所以我们未root过的设备adbd命令都被从root用户切换成了shell用户了。
Leverage adbd
本文一开始就介绍了root的终极目的，就是复制su文件到指定位置并且赋予可执行权限和setuid权限，但是这一过程本身就需要拥有root权限，所以我们可以考虑能否在adbd进程启动上打点注意呢？因为init进程在启动adbd进程的过程中在执行setgid和setuid代码之前一直都是拥有root权限的，如果我们让setgid和setuid执行失败，那岂不是adbd会一直拥有root权限。
Image may be NSFW.
Clik here to view.
（图3 init进程启动adbd进程示意图）
从漏洞代码可以看出adbd在setgid和setuid的过程中，并未检测降级是否成功，所以hacker只需要阻止或者破环这个降级过程，就可以达到使adbd进程以root用户的运行的目的，从而使得外部adb client拥有root权限运行一切命令的能力，ROOT过程就自然水到渠成了。
PoC知识准备
查看setuid函数，寻求找到失败的突破口，直接man下setuid，获得下述文档：
Image may be NSFW.
Clik here to view.
（图4 Linux man 2 setuid 帮助文档）
文档指出setuid是可能发生错误的，如在目标用户的进程数超过RLIMIT_NPROC限制时，系统就不能再将一个进程分配给这个目标用户，并会发生EAGAIN错误，如果直接忽略这个错误的话，则adbd仍继续以root用户运行。
所以我们需要继续研究RLIMIT_NPROC这个值，这个参数是Linux为了均衡多用户通过使用shell命令使用系统资源设定的，Linux系统替每个用户限定了最大进程数目、最多内存使用、最多打开文件数目等系统资源的使用，这个RLIMIT_NPROC即为通过shell每一个用户最多打开进程的数目，我们可以通过ulimit -a 来查看。
Image may be NSFW.
Clik here to view.
（图5 HTC one设备每个用户通过shell使用资源限制情况）
比如这台HTC one手机就允许每一个用户打开12408个进程，打开1024个文件，拥有262144KB内存等系统资源。
PoC执行方案
- 使用shell用户登录设备，获取shell用户的可以开启的最大进程数目RLIMIT_NPROC；
- 制造大量进程并达到shell用户的RLIMIT_NPROC，并占据不释放；
- Kill当前已经存在的adbd进程（该adbd进程已被降级成shell用户）；
- 再次创建一个进程用来占据进程数并不释放；
- 等待系统重新创建adbd进程，在创建过程中adbd一直为root用户进程，但在setuid时切换至shell用户失败；
- init进程不会检查切换用户是否失败，而将继续以完成adbd进程的创建工作，最后创建出仍以root用户为所有者的adbd进程；
- 退出shell用户，在推出之前清除多余进程，然后以adb client命令的形式完成su文件复制，权限设置，授权apk的安装等ROOT步骤。