Android系统的Root权限获取与检测

一、Android安全机制介绍

Android安全架构是基于Linux多用户机制的访问控制。应用程序在默认的情况下不可以执行其他应用程序，包括读或写用户的私有数据(如联系人数据或email数据)，读或写另一个应用程序的文件。

一个应用程序的进程就是一个安全的沙盒。它不能干扰其它应用程序，除非显式地声明了“permissions”，以便它能够获取基本沙盒所不具备的额外的能力。它请求的这些权限“permissions”可以被各种各样的操作处理，如自动允许该权限或者通过用户提示或者证书来禁止该权限。应用程序需要的那些“permissions”是静态的在程序中声明，所以他们会在程序安装时被知晓，并不会再改变。

每一个Android应用程序都会在安装时就分配一个独有的Linux用户ID，这就为它建立了一个沙盒，使其不能与其他应用程序进行接触。这个用户ID会在安装时分配给它，并在该设备上一直保持同一个数值。所有的Android应用程序必须用证书进行签名认证，而这个证书的私钥是由开发者保有的。该证书可以用以识别应用程序的作者。Android应用程序允许而且一般也都是使用self-signed证书。证书是用于在应用程序之间建立信任关系，而不是用于控制程序是否可以安装。签名影响安全性的最重要的方式是通过决定谁可以进入基于签名的permisssions，以及谁可以share用户IDs。通过这样的机制，每个应用都是相互隔离的，实现了一定的安全，但去除root用户。

二、AndroidRoot原理及方法

目前获取Androidroot权限常用方法是通过各种系统漏洞，替换或添加SU程序到设备，获取Root权限，而在获取root权限以后，会装一个程序用以提醒用户是否给予程序最高权限，可以一定程度上防止恶意软件，通常会使用Superuser或者SuperSU，这种方法通常叫做“不完全Root”。而“完全ROOT”是指，替换设备原有的ROM，以实现取消secure设置。通过ADB可以直接将SU程序放入到系统。

首先分析Android自带su源代码，由于源码较多，下面摘录最重要几行。

intmain(intargc,char**argv){

/*Untilwehavesomethingbetter,onlyrootandtheshellcanusesu.*/

myuid=getuid();

if(myuid!=AID_ROOT&&myuid!=AID_SHELL){fprintf(stderr,"su:uid%dnotallowedtosu\n",myuid);return1;}

if(execvp(argv[2],exec_args)<0){}

/*Defaultexecshell.*/

execlp("/system/bin/sh","sh",NULL);}

可以看出只允许getuid()为AID_ROOT和AID_SHELL的进程可以继续执行，否则直接返回，这就决定了只有当前用户为root和shell才能运行su。接下来执行execvp(argv[2],exec_args)，su并没有通过fork去创建一个新的进程，而是直接把自己启动一个新的进程，此时原先执行的程序实际上由su来创建的。通常情况下，执行su并不会带参数，于是它会执行execlp("/system/bin/sh","sh",NULL);

通过命令行查看此程序权限ls–l/bin/su

-rwsr-xr-x1rootroot368642010-01-2701:09/bin/su

由上可以看到，su的所有者和所有组都是root，并且其设置了SUID和SGID。因此下面介绍Linux中实际用户ID和有效用户ID概念：

实际用户ID和实际用户组ID：标识我是谁。也就是登录用户的uid和gid。有效用户ID和有效用户组ID：进程用来决定我们对资源的访问权限。一般情况下，有效用户ID等于实际用户ID，有效用户组ID等于实际用户组ID。当设置-用户-ID

(SUID)位设置，则有效用户ID等于文件的所有者的uid，而不是实际用户ID;同样，如果设置了设置-用户组-ID(SGID)位，则有效用户组ID等于文件所有者的gid，而不是实际用户组ID。由此可以得出，当一个其他用户或者用户组的进程来执行su的时候，正常情况下会因为用户ID不是root而被拒绝。但是，如果它能够跳过检查UID这一步，即能够使自己的进程获得和su相同的root的权限。

这样就可以看出Android系统的破解的根本原理就是替换掉系统中的su程序，因为系统中的默认su程序需要验证实际用户权限(只有root和shell用户才有权运行系统默认的su程序，其他用户运行都会返回错误)。而破解后的su将不检查实际用户权限，这样普通的用户也将可以运行su程序，也可以通过su程序将自己的权限提升。

三、检测AndroidRoot原理

Root过程分两部分，首先在重要image的头上添加了标识字串，可以检机器上这些字串是否存在，如果不存在，则怀疑这些image已经被重新烧过;另外对于不烧写第三ROM的root，可以开机添rootcheckservice来检测是否存在“su”可执行文件，如果检测到有，则该进程会写字串到pro_info分区中，工具应用可以检测在该区域是否有此字串来判读手机是否被root。考虑的pro_info分区中信息相对敏感，对pro_info中偏移了2M来记录此信息，尽量减少对pro_info信息的影响。

Image头标识信息：

Image名称，位置(相对image头的偏移)字串sizeUboot0x100109f10eed3f021e316BBootimage0x100109f10eed3f021e316BSystemiamge0x100109f10eed3f021e316B“su”标识信息：

识长16B，为109f10eed3f021e3。因为通常user版本没su这个文件，如果有说明是被破解时拷贝进入。代码可放置于：system/extras/xiaoyan/rootdetect.c编译时会编译成Rootdetect，并加入到init.rc中，在Android系统启动时执行，设备厂商可以通过特定工具读取Pro_info分区的标识来判读设备是否被Root。

手机应用程序可以到指定目录(system/bin/,system/xbin/,sbin/)找su文件，不过，基于安全考虑，正式版这几个目录对用户不可见。因此需要提供一种方式，让用户更直观获取系统是否被root的信息。将原先的Rootdetect服务进程进行延伸，一旦确认su程序异常，将被root的信息写入到/data/rootedflag，供启动后应用读取。这里注意到文件权限是644,就是-rw-r--r--,防止被其他用户篡改里面的内容。

四、结论

通过对Android安全机制和常见Root方法的研究，结合Android存在的安全问题，提出了一种适用于Android平台的Root检测的机制。同时，设备厂商也可以采用这种方法，检测已售设备是否被破解。应用开发者也可以借助检测工具爱内测（http://www.ineice.com/）对APP进行安全检测，也确保手机应用程序安全。