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

　　 一、Android安全机制介绍
　　Android安全架构是基于Linux多用户机制的访问控制。应用程序在默认的情况下不可以执行其他应用程序，包括读或写用户的私有数据(如联系人数据或email数据)，读或写另一个应用程序的文件。
　　一个应用程序的进程就是一个安全的沙盒。它不能干扰其它应用程序，除非显式地声明了“permissions”，以便它能够获取基本沙盒所不具备的额外的能力。它请求的这些权限“permissions”可以被各种各样的操作处理，如自动允许该权限或者通过用户提示或者证书来禁止该权限。应用程序需要的那些“permissions”是静态的在程序中声明，所以他们会在程序安装时被知晓，并不会再改变。
　　每一个Android应用程序都会在安装时就分配一个独有的Linux用户ID，这就为它建立了一个沙盒，使其不能与其他应用程序进行接触。这个用户ID会在安装时分配给它，并在该设备上一直保持同一个数值。所有的Android应用程序必须用证书进行签名认证，而这个证书的私钥是由开发者保有的。该证书可以用以识别应用程序的作者。Android应用程序允许而且一般也都是使用self-signed证书。证书是用于在应用程序之间建立信任关系，而不是用于控制程序是否可以安装。签名影响安全性的最重要的方式是通过决定谁可以进入基于签名的permisssions，以及谁可以share 用户IDs。通过这样的机制，每个应用都是相互隔离的，实现了一定的安全，但去除root用户。
　　 二、Android Root原理及方法
　　目前获取Android root 权限常用方法是通过各种系统漏洞，替换或添加SU程序到设备，获取Root权限，而在获取root权限以后，会装一个程序用以提醒用户是否给予程序最高权限，可以一定程度上防止恶意软件，通常会使用Superuser或者 SuperSU ，这种方法通常叫做“不完全Root”。而 “完全ROOT”是指，替换设备原有的ROM，以实现取消secure设置。通过ADB可以直接将SU程序放入到系统。
　　首先分析Android自带su源代码，由于源码较多，下面摘录最重要几行。
　　int main(int argc, char **argv){
　　/* 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;}
　　if (execvp(argv[2], exec_args) < 0) {}
　　/* Default exec shell. */
　　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-x 1 root root 36864 2010-01-27 01: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 程序将自己的权限提升。
　　 三、检测Android Root原理
　　Root过程分两部分，首先在重要image的头上添加了标识字串，可以检机器上这些字串是否存在，如果不存在，则怀疑这些image已经被重新烧过;另外对于不烧写第三ROM的root，可以开机添rootcheck service来检测是否存在“su”可执行文件，如果检测到有，则该进程会写字串到pro_info 分区中，工具应用可以检测在该区域是否有此字串来判读手机是否被root。考虑的pro_info 分区中信息相对敏感，对pro_info 中偏移了2M 来记录此信息，尽量减少对pro_info 信息的影响。
　　Image 头标识信息：
　　Image 名称， 位置(相对image 头的偏移) 字串 sizeUboot 0x100 109f10eed3f021e3 16BBoot image 0x100 109f10eed3f021e3 16BSystem iamge 0x100 109f10eed3f021e3 16B“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进行安全检测，也确保手机应用程序安全。