5498人阅读
Android（39）
破解android的root权限的本质是：在系统中加入一个任何用户都可能用于登陆的su命令。或者说替换掉系统中的su程序，因为系统中的默认su程序需要验证实际用户权限,只有root和 shell用户才有权运行系统默认的su程序，其他用户运行都会返回错误。而破解后的su将不检查实际用户权限，这样普通的用户也将可以运行su程序，也可以通过su程序将自己的权限提升。&
root破解没有利用什么Linux内核漏洞（Linux内核不可能有这么大的漏洞存在）,可以理解成root破解就是在你系统中植入“木马su”，说它是“木马”一点儿都不为过，假如恶意程序在系统中运行也可以通过su来提升自己的权限的这样的结果将会是灾难性 的。所以一般情况下root过手机都会有一个SuperUser应用程序来让用户管理允许谁获得root权限，也算是给系统加了一层保险吧！&
Android的应用程序入口肯定是Java程序。应用程序的启动者是由系统临时根据Androidmanifest.xml中定义的权限而创建的临时用户。而不像linux那样是使用登陆者的身份启动，从而使得进程具有登陆者的所有权限。这也是Android的安全机制之一。&
新的权限机制也带来新的问题，Android给应用程序的权限是按功能来分，java虽然可以访问文件系统。但由于应用程序本身是临时用户启动，这个临时用户权限十分有限。因此诞生了&越狱/root机器&这样的产物。&
其实root机器不是真正能让你的应用程序具有root权限。它原理就跟linux下的像sudo这样的命令。在系统的bin目录下放个su程序并且属主是root并有suid权限。则通过su执行的命令都具有Android root权限。&
当然使用临时用户权限想把su拷贝的/system/bin目录并改属性并不是一件容易的事情。这里用到2个工具跟2个命令。&
工具就是busybox。不熟悉的同学可以去网上google下。这个太有名了我就不多说了。把busybox拷贝到你有权限访问的目录然后给他赋予4755权限，你就可以用它做很多事了。&
当然busybox不能提升权限，真正提升权限的是ratc这个程序，这个程序中一键root包里面可以找到，作用是rooting在adb的shell。&
网上介绍Ratc的文章不多，它是rage against the cage 的缩写。是真正的提升权限的破解程序。虽然我没看过源代码，但估计是利用adb源代码部分内容来实现的，&
原理估计跟模拟器使用adb shell登陆可以获得root shell差不多。（因为它运行需要adb连接才会成功）。&
使用busybox前先运行ratc，这样运行busybox的UID将是0，也就是root。&
首先把system目录改成可读性的：busybox mount -o remount,rw /system，&
当然你还不能改下面的文件，因为system下文件的所有者都不是你。但你可以偷梁换柱把system下的目录给换掉。&
使用命令Busybox mount -t tmpfs none /system/xbin，呵呵这下xbin目录你随便写了。&
将su跟busybox弄过去cp /data/data/xxx/su /system/xbin。然后赋权限chmod 4755 /system/xbin/su。&
然后使目录生效busybox --install -s /system/xbin，别忘善后busybox mount -o remount,ro /system去掉system可写。&
这样只是临时的，只能用su跟busybox能执行一些原来系统没有权限执行的命令而已。当系统重启后/system/xbin又变为原来的文件。&
真正要改系统的话需要自己写内核代码（相当于windows的驱动程序）。内核文件拥有所有权限。使用busybox命令insmod /data/data/xxx/xxx.ko装载内核文件，你想干嘛就可以干嘛了。&
当然我们不是搞破解的没必要去改别人的机器，我们只是想让自己应用程序具有root权限而已。所以临时的su就可以了。&
我们用c++写一个可执行文件。使用socket可以跟java的程序通讯。然后将需要使用root权限才能执行的代码放在c++程序里，然后java程序中创建新的su进程，&
将c++程序带全路径作为参数1。启动后就可以通过socket调用c++函数去执行你想干的事了。最后程序执行完了别忘了善后busybox umount /system/xbin。&
最后说说要注意的事情，如果机器已经拥有Android root权限的话就不需要做这些事情了，但root过的机器都有装有个权限管理的程序。会弹出对话框。但这个程序管理能力有限，如果不想让他弹出的话。也许可以通过改su文件名来解决。有兴趣的同学不妨试试。&
--------------------------------------------------------------------------------------------------------------------------------------------------------&
破解手机Root权限是比较简单及安全的，破解Root权限的原理就是在手机的/system/bin/或/system/xbin/目录下放置一个可执行文件“su”，这是一个二进制文件，仅仅在系统中置入这个“su”文件是不会给手机的软件或硬件造成任何故障。&
下面的代码是android系统原版的su中的部分代码，可以看出只允许getuid()为AID_ROOT和AID_SHELL的进程可以使用su进行登陆。&
也就是说，Android系统默认的su程序只能root和shell可以用运行su，这个是安全的。如果把这个限制拿掉，就是root破解了，获取了root权限。&
/* 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;&
& 在Superuser(一个破解程序)这个android程序中的su不再有上面的一部分，这样任何进程都可以使用su进行登陆了。&
还有一部分android程序要使用root权限可能的用法类似于（这个也是Superuser中的一部分代码）：&
Process process = Runtime.getRuntime().exec(&su&);&
DataOutputStream os = new DataOutputStream(process.getOutputStream());&
os.writeBytes(&mount -oremount,rw /dev/block/mtdblock3 /system\n&);&
os.writeBytes(&busybox cp /data/data/com.koushikdutta.superuser/su /system/bin/su\n&);&
os.writeBytes(&busybox chown 0:0 /system/bin/su\n&);&
os.writeBytes(&chmod 4755 /system/bin/su\n&);&
os.writeBytes(&exit\n&);&
os.flush();&
而在上面提到的Superuser和android原生的su源码中都有这部分代码：&
if(setgid(gid) || setuid(uid)) {&
fprintf(stderr,&su: permission denied\n&);&
return 1;&
从出上面的分析可以认为破解android的root权限的实质是：在系统中加入一个任何用户都可能用于登陆的su命令。当然这首先要取得root权限才能做到。&
在z4root这个android下的破解android的root权限的程序中有一个rageagainstthecage，这就是破解的关键。&
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------&
root破解过程的终极目标是替换掉系统中的su程序。但是要想替换掉系统中su程序本身就是需要root权限的，怎样在root破 解过程中获得root权限，成为我们研究的重点了。&
下面我们先清点一下我们需要破解系统情况，假设需要破解的Android系统具备如下条件：&
&&& 1、可以通过adb连接到设备，一般意味着驱动程序已经安装。&
&&& 2、但是adb获得用户权限是shell用户，而不是root。&
要想理解root破解过程我们首先需要了解一下adb工具，SDK中包含adb(android debug briage)工具，设备端有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&
&&& service adbd /sbin/adbd&
&&& disabled&
& 在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漏洞。这里面做一个简单说明：&
&&& 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权限下面了。&
&&& 3、这时重新用adb连接设备，则adb将会运行在root权限下面了。&
通过上面的介绍我们发现利用RageAgainstTheCage漏洞，可以使adbd获得root权限，也就是adb获得了root权限。&
拿到root权限剩下的问题就好办了，复制破解之后的su程序到系统中，都是没有什么技术含量的事情了。&
其实堵住adbd的这个漏洞其实也挺简单的：&
&&& /* then switch user and group to &shell& */&
&&& if (setgid(AID_SHELL) != 0) {&
&&&&&& exit(1);&
&&& if (setuid(AID_SHELL) != 0) {&
&&&&& exit(1);&
如果发现setgid和setuid函数执行失败，则adbd进程异常退出，就把这个漏洞给堵上了。&
为什么这么多设备都没有堵上这个漏洞呢？我觉得是设备厂商的策略，虽然知道怎么封堵漏洞但是就是留着个后门给大家，让第三方给自己定制 rom，提高自己系统的易用性。&
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------&
去年的Android adb setuid提权漏洞被用于各类root刷机，漏洞发现人Sebastian Krahmer公布的利用工具RageAgainstTheCage（rageagainstthecage-arm5.bin）被用于z4root等提权工具、Trojan.Android.Rootcager等恶意代码之中。下面我们来分析这一漏洞的产生原因。&
The Android Exploid Crew小组在后来发布了一份PoC代码：rageagainstthecage.c。从这份代码开始着手。&
在main(:72)函数中，首先获取了RLIMIT_NPROC的值(:83)，这个值是Linux内核中定义的每个用户可以运行的最大进程数。&
然后，调用find_adb()函数(:94)来搜索Android系统中adb进程的PID，具体而言，该函数读取每个进程对应的文件的/proc/&pid&/cmdline，根据其是否等于”/sbin/adb”来判断是否adb进程。&
接下来，fork了一个新的进程(:109)，父进程退出，而子进程继续。接下来，在113行创建一个管道。&
rageagainstthecage.c&
if (fork() & 0)&
&&& exit(0);&
setsid();&
pipe(pepe);&
重头戏发生在下面的122到138行，代码如下：&
rageagainstthecage.c&
代碼: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 {&
&&&&&&&&&&& ++&
&&&&&&& }&
新建一个进程后，在子进程之中，exploit代码不断地fork()(:125)，而新的子进程不断退出，从而产生大量的僵尸进程（占据shell用户的进程数）。&
最终，进程数达到上限，fork()返回小于0，于是打印当前已经创建多少子进程，并向管道输入一个字符（:131）。
在这里，管道的作用是和(:122)fork出来的父进程同步，该进程在141行read这一管道，因而阻塞直至僵尸进程已经达到上限(:131)。&
进一步的，exploit杀掉adb进程，并在系统检测到这一现象并重启一个adb之前，再一次fork()，将前一个adb留下的进程空位占据。&
最后，在152行，exploit调用wait_for_root_adb()，等待系统重启一个adb，这个新建的adb就会具有root权限。&
为什么在shell用户的进程数达到上限RLIMIT_NPROC以后，新建的adb会具有root权限？我们来看adb的源码。&
在&android_src&/system/core/adb/adb.c的第918行，我们可以看到如下代码：&
android_src/system/core/adb/adb.c&
代碼:/* then switch user and group to &shell& */&
if (setgid(AID_SHELL) != 0) {&
&&& exit(1);&
if (setuid(AID_SHELL) != 0) {&
&&& exit(1);&
这已经是漏洞修补以后的代码。在漏洞最初被发现时，代码如下：&
android_src/system/core/adb/adb.c&
代碼:/* then switch user and group to &shell& */&
setgid(AID_SHELL);&
setuid(AID_SHELL);&
简而言之，原来没有检查setuid()函数的返回值。事实上，在此之前，adb.c中的代码都是以root权限运行，以完成部分初始化工作。&
在这一行，通过调用setuid()将用户从root切换回shell，但setuid()在shell用户进程数达到上限RLIMIT_NPROC时，会失败，因此adb.c继续以root身份运行，而没有报错。&
我们来看setuid()的man手册（man 2 setuid），其中有如下说明：&
man 2 setuid&
代碼:RETURN VALUE&
&&&&&& On& success,& zero is returned.& On error, -1 is returned, and errno is&
&&&&&& set appropriately.&
&&&&&& EAGAIN The uid does not match the current uid and& uid& brings& process&
&&&&&&&&&&&&& over its RLIMIT_NPROC resource limit.&
可以看到，setuid是可能发生错误的，并且在uid的进程数超过RLIMIT_NPROC极限时，发生EAGAIN错误。&
在android的源码中，setuid()定义于&android_src&/bionic/libc/unistd/setuid.c，实际上引用了一个外部符号__setuid，&
这个符号在&android_src&/bionic/libc/arch_xxx/syscalls/__setuid.S中定义，最终是一个%eax=$__NR_setuid32，%ebx=uid的int 0×80中断。&
因为只是要分析原理，我们不再鏖战于Android，转而看向Linux内核。&
在最新的kernel2.6中，setuid()位于kernel/sys.c的682行，其中，在697行，一切正常的情况下，它会调用set_user()来完成用户切换。&
set_user()实现于同一文件的587行，其中一部分代码如下：&
kernel/sys.c&
代碼:if (atomic_read(&new_user-&processes) &= rlimit(RLIMIT_NPROC) &&&
&&&&&&& new_user != INIT_USER) {&
&&& free_uid(new_user);&
&&& return -EAGAIN;&
含义很明显，当目标用户的进程数达到上限，那系统就不能再将一个进程分配给它，因而返回-EAGEIN。然后再setuid()中，直接跳过后面的代码，而返回错误。&
至此，整个漏洞的原理已经分析完毕。整理如下：&
1、在Android的shell用户下，制造大量的僵尸进程，直至达到shell用户的进程数上限RLIMIT_NPROC；&
2、kill当前系统中的adb进程，并再次占据其进程位置以保持达到上限；&
3、系统会在一段时间后重启一个adb进程，该进程最初是root用户，在完成少许初始化工作后，调用setuid()切换至shell用户；&
4、此时shell用户的进程数已经达到上限，所以setuid()失败，返回-1，并且用户更换没有完成，adb还是root权限；&
5、adb没有检查setuid()的返回值，继续后续的工作，因此产生了一个具有root权限的adb进程，可以被用于与用户的下一步交互。&
实际上，setuid在目标用户进程数达到RLIMIT_NPROC极限时返回错误，这一问题可能产生的安全隐患最早可以追溯到2000年。而在2006年，出现了真正利用这一编码问题的漏洞（CVE-）。&
因此，这并不是一个全新的漏洞。我们可以得出几点结论：&
1、函数返回值一直是忽略的对象，因为getuid()永远不会失败，程序员可能会认为setuid()也不会失败——至少没有遇到过，因此忽略了对返回值的检查。检查一个系统函数是否调用失败是一个常识，但又是很麻烦的事，如果为了省事而忽略，问题就可能产生了。&
2、Android下的安全问题，很多并非全新的，而且个人判断将来还会有大量漏洞、恶意代码产生于传统思路，而作用于新的平台。面对这一新的平台，我们是否能抢先于攻击者做好防范准备，是一个需要我们思考和实践的问题。&
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------&
写这篇文章前，首先要感谢&&，他的两篇关于&root&权限的文章对于我的工作起到了非常大的帮助，这篇文章可以说是对他的文章的一个补充。&Simon_fu&的文章可以参考如下两个网页：
&&&&&&&一般来说，&Android&下的应用程序可以“直接”得到的最大的权限为&system&，但是如果我们需要在程序中执行某些需要&root&权限的命令，如&ifconfig&等，就需要&root&权限了。按照&Simon&的文章中提到的，应用程序有以下两种办法临时获得&root&权限：
1)&&&&&&&&实现一个&init&实现一个&Service&，来帮助&Android&应用程序执行&root&权限的命令。
2)&&&&&&&&实现一个虚拟设备，这个设备帮助&Android&应用程序执行&root&权限的命令。
第二种办法我这里没有尝试，暂时也不会。这里讲讲我在实现第一种办法的过程和遇到的一些问题。
1.&&&&&&&将我们要执行的命令写成脚本，或者可执行程序。
下面是我的脚本&ifconfig_test.sh&：
#&！&/system/bin/sh
&&&&&&&注意：&脚本的第一行必须为&#&！&/system/bin/sh&，否则无法执行，通过&dmesg&可以查看到信息内容为cannot execve ./ifconfig_test.sh: Exec format error
也可以采用&C/C++&编写需要执行的命令或者程序，并在编译&image&的时候编译成可执行程序。
2.&&&&&&&在&init.rc&中注册&service
Android&中的&service&需要在&init.rc&中注册，&Init.rc&中定义的&Service&将会被&init&进程创建，这样将可以获得root&权限。当得到相应的通知（通过属性设置）后，&init&进程会启动该&service&。
本文中注册的内容如下：
service ifconfig_test /system/etc/ifconfig_test.sh
&&&&&&&其中，&oneshot&表示程序退出后不再重新启动，&disabled&表示不在系统启动时启动。
注意：&这里&service name&不能超过&16&个字符。我之前的&service name&由于定义的比较长，&18&个字符，设置属性通知&service&启动后查看&dmesg&可以看到提示：&init: no such service&。查看&/system/core/init/parser.c的源代码，在&parse_service-&valid_name&函数中可以看到如下内容：&if
(strlen(name) & 16) { return 0; }&，证明&service&的名字的确不能超过&16&个字符。
3.&&&&&&&将&Android&应用程序提升为&system&权限
既然应用程序可以通过启动&service&获得&root&权限，那么岂不是很不安全。&Android&考虑到了这点，规定只有&system&权限的应用程序才能设置属性，通知&service&启动。关于提升&system&权限的文章网上已有很多，这里就不再细说，可以参考如下两篇文章：
4.&&&&&&&在应用程序中添加属性设置代码
前面已经提到，对于&Android&来说，应用程序通知&init&启动&service&是通过设置系统属性来完成的，具体为设置&System&系统属性&“ctl.start”&为&“ifconfig_test”&，这样&Android&系统将会帮我们运行&ifconfig_test&这个service&了。
对该系统属性的设置有三种方法，分别对应三种不同的应用程序：&&
1)& Java 代码
&&Android 在 Java 库中提供 System.getProperty 和 System.setProperty 方法， Java 程序可以通过他们来设置和获得属性。代码如下：
SystemProperties.set(&ctl.start&, &ifconfig_test&);
上面的代码是通知&Android&执行&ifconfig_test service&，如果需要查询当前&service&执行的状态，如是否执行完毕，可以通过如下代码查询：
ret = SystemProperties.get(&init.svc. ifconfig_test &, &&);
if(ret != null && ret.equals(&stopped&))
&&&&&&&&2）&&JNI&代码
当编写&NDK&的程序时，可以使用&property_get&和&property_set&这两个&API&来获得和设置属性。使用这两个API&必须要包含头文件&和链接&libcutil&库。
3）&&Shell&脚本
Android&提供了命令行&setprop&和&getprop&来设置和获取属性，他们可以在脚本中被使用。
由于我的程序是在&JNI&中调用脚本，脚本中又执行&ifconfig&，因此我将设置属性的部分放在了脚本中完成，代码如下：
setprop ctl.start ifconfig_test
#wait for the service until it stops
while [ $ret -ne 0 ]
&&&&&&&getprop | grep &$ENABLE_MAPPER_SRV& | grep stopped
&&&&&&&ret=$?
&&&&&&&通过上面&4&个步骤，&Android&应用程序就获得了&root&权限，更具体的说，是在执行我们需要执行的命令时临时获得了&root&权限。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------&
Android&下应用程序不能直接&获得&root&权限，因此如果需要修改&/sys&或&/proc&等目录下的文件时，有以下两种方法可以选择：
通过&service&或虚拟设备的方法将使得应用程序临时&获得&root&权限对&/sys&或&/proc&目录下的文件修改访问权限，使得它们能够被程序访问
对于方法&1&，可以参看我后续会写到的一篇文章《如何使&Android&应用程序获得&root&权限》，也可以在网上搜索别的相关文章。
这里讲讲方法&2&。
为了理解方法&2&，首先要知道&Android&上的权限机制。&Android&会为每个安装在系统上的包（&apk&）配一个唯一的&linux userID&，名称为&&app_&&加一个数字，比如&app_43&。这样该应用程序的文件只对该用户可见，也就是说，应用程序只能访问相同&uid&和&gid&的文件。
另外，也可以通过&AndroidManifest.xml&修改应用程序的&uid&。如果将&android:sharedUserId&项的值改为其它&apk&的&java package name&，则该应用程序和所指定的应用程序拥有相同的&uid&，可以访问对方的文件。
通过&android:sharedUserId&还可以将应用程序提升为&system&权限。
有了上面的知识，这里有三种方法来修改我们所要访问的文件：
将文件改为&777&权限将文件改为&apk&的&uid&和&gid将文件修改为&system&的&uid&，同时将&apk&也提升为&system&权限
这三种方法都需要修改所要访问系统文件的权限。要更改权限，在&init.rc&文件中添加相应的命令即可。下述命令就将&/dev/cpuctl/tasks&修改为&system&的&uid&和&gid&，并且将其权限更改为&777&。
chown system system /dev/cpuctl/tasks
chmod 0777 /dev/cpuctl/tasks
修改&init.rc&该文件需要修改&ramdisk.img&，具体修改方法可以网上搜索，也可以参看这篇文章最后的附录。或者在源代码中直接修改&init.rc&文件然后编译即可。
下面依次分析一下上面提到的三种修改访问文件的方法。第一种方法是最简单的，不过安全性不好，仅仅可以作为实验使用，不推荐；第二种方法将系统文件文件的&uid&修改后，拓展性不好，并且我不能确定每次分配给apk&的&uid&是否相同。我这里试了几次，重新安装后&apk&的&uid&都是相同的，不过没有找到相关文章，所以不敢用。最后我这里采用第三种方法实现。
1）首先修改&init.rc
chown system system /sys/bus/usb/devices/testfile
这样每次启动后，系统都会执行&init.rc&文件将&testfile&的&uid&修改为&system&，这样&uid&同问&system&的程序就能够访问该文件了。
2）&其次将&apk&提升为&system&权限
将&apk&提升为&system&权限需要目标系统中的签名文件对&apk&进行签名，因此这种方法仅适用于某个&rom&，不能用于所有&rom&。
具体的提升办法网上有很多，这里不再多说，可以参考这两篇文章：
至此，我们的目标就达成了。
附&修改&ramdisk.img&的方法
在网上找到了一些修改&ramdisk.img&的方法，都有点问题，我这里写一下自己的流程。由于&ramdisk.img&是首先用&cpio&打包，再用&gzip&压缩后的文件，因此在解压和压缩时都需要经历这两个步骤。
1）&&&&mv ramdisk.img ramdisk.img.gz
2）&&&&gunzip ramdisk.img.gz&&#gunzip&解压得到&ramdisk.gz
3）&&&&cpio –iI ramdisk.gz&&#&用&cpio&解压上一步得到的文件
4）&&&&修改&init.rc
5）&&&&find. | cpio –o –H newc | gzip -9 & ramdisk.gz&&&#cpio&打包后，&gzip&再压缩
6）&&&&mv ramdisk.gz ramdisk.img
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：756192次
积分：6872
积分：6872
排名：第2246名
转载：297篇
评论：172条
(1)(2)(1)(2)(2)(4)(1)(5)(15)(6)(9)(1)(11)(6)(20)(20)(5)(4)(10)(12)(10)(4)(12)(7)(17)(16)(6)(14)(11)(6)(9)(2)(1)(12)(6)(10)(25)}