您的位置:首页 > 移动开发 > Android开发

Android系统root破解原理分析

2014-07-13 21:15 393 查看
转:http://dengzhangtao.iteye.com/blog/1543494/article/2609018.html

root破解过程的终极目标是替换掉系统中的su程序。但是要想替换掉系统中su程序本身就是需要root权限的,怎样在root破解过程中获得root权限,成为我们研究的重点了。下面我们先清点一下我们需要破解系统情况,假设需要破解的Android系统具备如下条件:

1、可以通过adb连接到设备,一般意味着驱动程序已经安装。

2、但是adb获得用户权限是shell用户,而不是root。(漏洞)

想理解root破解过程我们首先需要了解一下adb工具,SDK中包含adb工具,设备端有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

2: service adbd /sbin/adbd

3: disabled

对Android属性系统少有了解的朋友将会知道,在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漏洞,具体分析请参考《Android adb setuid提权漏洞的分析》和《RageAgainstTheCage》

通过上面的介绍我们发现利用RageAgainstTheCage漏洞,可以使adbd获得root权限,也就是adb获得了root权限。拿到root权限剩下的问题就好办了,复制破解之后的su程序到系统中。





adbd源码位于system/core/adb/目录下,可执行文件位于/sbin/adbd。通过adb执行ps命令,结果如下:

USER PID PPID VSIZE RSS WCHAN PC NAME

root 1 0 296 212 c00b0124 0000d9ec S /init

... ...

shell 2183 1 3372 184 ffffffff 0000eca4 S /sbin/adbd

root 2204 1859 832 336 00000000 afe0c7dc R ps

看一下倒数第二行,adbd所在进程的父进程是root,本身的user是shell。对于一个发布状态的产品,这个是最正常不过了。但现在开发中遇到这样一个需求,产品已经处在发布状态(编译模式已经改成user)的情况下,因为BSP需要处理一些内核上的东西,需要在PC上执行adb shell后具有root权限。也就是这种效果:

USER PID PPID VSIZE RSS WCHAN PC NAME

root 1 0 296 212 c00b0124 0000d9ec S /init

... ...

root 1911 1 3376 184 ffffffff 0000eca4 S /sbin/adbd

root 2198 2197 828 332 00000000 afe0c7dc R ps

要达到这个效果,就是要在启动adbd时,以root用户启动。那么,先看一下在Android中怎么启动adbd。



可以看一下Android系统根目录下的/init.rc的片段:

... ...

# adbd is controlled by the persist.service.adb.enable system property

service adbd /sbin/adbd

disabled

# adbd on at boot in emulator

on property:ro.kernel.qemu=1

start adbd

on property:persist.service.adb.enable=1

start adbd

on property:persist.service.adb.enable=0

stop adbd

... ...

这里定义了一个触发器,只要persist.service.adb.enable值被置为1,就会启动/sbin/adbd。



怎么样设置persist.service.adb.enable的值呢?这里涉及到一个属性服务/system/core/init/property_service.c。看下面的东西之前先看一下我之前翻译过来的这篇StevGuo的文档,他对属性服务描述得很仔细,也很有条理。
http://blog.csdn.net/a345017062/archive/2010/12/17/6083026.aspx
今天搜资料的时候才发现网上N多人翻译了这篇文章,有点儿晕晕的。。。

我们继续。。。

通过阅读上面的文档,我们知道了属性服务启动时加载了四个文件,这四个文件里面都可以设置系统属性,还可以通过APK设置系统属性。但我把这些方式都,结果都一样,adbd是启动起来了,用户都是shell,还是没有root权限的。看来差异应该在编译模式上,是改为user编译模式后,系统改变了adbd启动时的权限。在build目录下搜索一下,发现了main.mk中有这样的代码片段

## user/userdebug ##



user_variant := $(filter userdebug user,$(TARGET_BUILD_VARIANT))

enable_target_debugging := true

ifneq (,$(user_variant))

# Target is secure in user builds.

ADDITIONAL_DEFAULT_PROPERTIES += ro.secure=1



tags_to_install := user

ifeq ($(user_variant),userdebug)

# Pick up some extra useful tools

tags_to_install += debug

else

# Disable debugging in plain user builds.

enable_target_debugging :=

endif



# TODO: Always set WITH_DEXPREOPT (for user builds) once it works on OSX.

# Also, remove the corresponding block in config/product_config.make.

ifeq ($(HOST_OS)-$(WITH_DEXPREOPT_buildbot),linux-true)

WITH_DEXPREOPT := true

endif



# Disallow mock locations by default for user builds

ADDITIONAL_DEFAULT_PROPERTIES += ro.allow.mock.location=0



else # !user_variant

# Turn on checkjni for non-user builds.

ADDITIONAL_BUILD_PROPERTIES += ro.kernel.android.checkjni=1

# Set device insecure for non-user builds.

ADDITIONAL_DEFAULT_PROPERTIES += ro.secure=0

# Allow mock locations by default for non user builds

ADDITIONAL_DEFAULT_PROPERTIES += ro.allow.mock.location=1

endif # !user_variant



ifeq (true,$(strip $(enable_target_debugging)))

# Target is more debuggable and adbd is on by default

ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=1 persist.service.adb.enable=1

# Include the debugging/testing OTA keys in this build.

INCLUDE_TEST_OTA_KEYS := true

else # !enable_target_debugging

# Target is less debuggable and adbd is off by default

ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=0 persist.service.adb.enable=0

endif # !enable_target_debugging

这段代码我大致解释一下:

主要通过判断当前的编译模式来给几个属性赋予不同的值,然后把属性存储在ADDITIONAL_DEFAULT_PROPERTIES这个变量中,这个变量在后面是要写到根目录下的/default.prop中去,在系统启动时被属性服务加载的。也就是说我们在/default.prop中看到的几个属性的值是在这里设置的。

只看两个属性ro.secure,persist.service.adb.enable。当前是user模式的话,编译系统会把ro.secure置为1,把persist.service.adb.enable置为0.也就是说,用user模式编译出来的系统运行在安全模式下,adbd默认关闭。即使通过设置属性的方式打开,adbd进程的用户也是shell,不具有root权限。这样,普通用户或者开发者拿到一个机器后,通过PC运行adb shell时,是以shell用户登录机器的。

好了,现在把ro.secure置为0,再重新编译,只要设置属性persist.service.adb.enable的值为1,adbd进程就会以root用户的身份启动。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: