許多機友新購來的Android機器沒有刷過Root權限，無法使用一些需要高權限的軟件，以及進行一些高權限的操作，其實刷手機Root權限是比較簡單及安全的，刷Root權限的原理就是在手機的/system/bin/或/system/xbin/目錄下放置一個可執(zhí)行文件“su”，這是一個二進制文件，相當于電腦上的exe文件，僅僅在系統(tǒng)中置入這個“su”文件是不會給手機的軟件或硬件造成任何故障。
下面的代碼是android系統(tǒng)原版的su中的部分代碼，可以看出只允許getuid()為AID_ROOT和AID_SHELL的進程可以使用su進行登陸。
復制代碼 代碼如下:
<SPAN style="FONT-SIZE: 18px"><STRONG>/* 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;
}</STRONG></SPAN>
面在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;
}
看上去這里就是進行權限切換的地方了。面普通用戶要能使用su，su的權限要是這樣：
-rwsr-xr-x. 1 root root 34904 11月 3 2010 /bin/su
這個和電腦版的su上是一樣的。
從出上面的分析可以認為刷android的root權限的實質(zhì)是：在系統(tǒng)中加入一個任何用戶都可能用于登陸的su命令。當然這首先要取得root權限才能做
到。在z4root這個android下的刷android的root權限的程序中有一個rageagainstthecage，可能就是設法得到root權限的程序。
第二篇文章：
如果你進行過程序開發(fā)，在root過的手機上面獲得root權限的代碼如下：
復制代碼 代碼如下:
Process process = Runtime.getRuntime().exec("su");
DataOutputStream os = new DataOutputStream(process.getOutputStream());
......
os.writeBytes("exit\n");
os.flush();
從上面代碼我們可以看到首先要運行su程序，其實root的秘密都在su程序中，《android root權限分析》中講到Android系統(tǒng)默認的su程序只能root和shell可以用運行su，這個是安全的。如果把這個限制拿掉，就是root了！
下面我們仔細分析一下程序是怎樣獲得root權限的，如果對Linux的su命令熟悉的朋友可能知道su程序都設置SUID位，我們查看一下我的手機（已經(jīng)root）上的su權限設置，
我們發(fā)現(xiàn)su的所有者和所有組都是root，是其實是busybox的軟鏈接，我們查看busybox的屬性發(fā)現(xiàn)，其設置了SUID和SGID，并且所有者和所有組都是root。SUID和SGID的作用是什么呢？如果你不太清楚，請參考《Linux進程的實際用戶ID和有效用戶ID》，這樣運行busybox的普通用戶，busybox運行過程中獲得的是root的有效用戶。su程序則是把自己啟動一個新的程序，并把自己權限提升至root（我們前面提到su其實就是busybox，運行期它的權限是root，當然也有權限來提升自己的權限）。
再強調(diào)一下不光root手機上su需要設置SUID，所有的Linux系統(tǒng)上的su程序都需要設置SUID位。請參考一下UC服務器的su的權限情況：
我們發(fā)現(xiàn)su也設置了SUID位，這樣普通用戶也可以運行su程序，su程序會驗證root密碼，如果正確su程序可以把用戶權限提高的root（因為其設置SUID位，運行期是root權限，這樣其有權限提升自己的權限）。
這樣我們就可以看出其實Android系統(tǒng)的根本原理就是替換掉系統(tǒng)中的su程序，因為系統(tǒng)中的默認su程序需要驗證實際用戶權限（只有root和 shell用戶才有權運行系統(tǒng)默認的su程序，其他用戶運行都會返回錯誤）。而后的su將不檢查實際用戶權限，這樣普通的用戶也將可以運行su程序， 也可以通過su程序?qū)⒆约旱臋嘞尢嵘?br />
到這里大家對root不感到神秘了吧。root沒有利用什么Linux內(nèi)核漏洞（Linux內(nèi)核不可能有這么大的漏洞存在），可以理解成root就是在你系統(tǒng)中植入“木馬su”，說它是“木馬”一點兒都不為過，假如惡意程序在系統(tǒng)中運行也可以通過su來提升自己的權限的這樣的結(jié)果將會是災難性 的。所以一般情況下root過手機都會有一個SuperUser應用程序來讓用戶管理允許誰獲得root權限，也算是給系統(tǒng)加了一層保險吧！
通過上文《Android系統(tǒng)root原理分析》 的介紹大家應該明白了root過程的終極目標是替換掉系統(tǒng)中的su程序。但是要想替換掉系統(tǒng)中su程序本身就是需要root權限的，怎樣在root破 解過程中獲得root權限，成為我們研究的重點了。下面我們先清點一下我們需要系統(tǒng)情況，假設需要的Android系統(tǒng)具備如下條件：
復制代碼 代碼如下:
1、可以通過adb連接到設備，一般意味著驅(qū)動程序已經(jīng)安裝。
2、但是adb獲得用戶權限是shell用戶，而不是root。
要想理解root過程我們首先需要了解一下adb工具，SDK中包含adb工具，設備端有adbd服務程序后臺 運行，為開發(fā)機的adb程序提供服務，adbd的權限，決定了adb的權限。具體用戶可查看/system/core/adb下的源碼，查看 Android.mk你將會發(fā)現(xiàn)adb和adbd其實是一份代碼，然后通過宏來編譯。
查看adb.c的adb_main函數(shù)你將會發(fā)現(xiàn)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) {
......
從中我們可以看到adbd會檢測系統(tǒng)的ro.secure屬性，如果該屬性為1則將會把自己的用戶權限降級成shell用戶。一般設備出廠的時候在/default.prop文件中都會有：
復制代碼 代碼如下:
ro.secure=1
這樣將會使adbd啟動的時候自動降級成shell用戶。
然后我們再介紹一下adbd在什么時候啟動的呢？答案是在init.rc中配置的系統(tǒng)服務，由init進程啟動。我們查看init.rc中有如下內(nèi)容：
復制代碼 代碼如下:
# adbd is controlled by the persist.service.adb.enable system property
service adbd /sbin/adbd
disabled
對Android屬性系統(tǒng)少有了解的朋友將會知道，在init.rc中配置的系統(tǒng)服務啟動的時候都是root權限（因為init進行是root權限，其子程序也是root）。由此我們可以知道在adbd程序在執(zhí)行：
復制代碼 代碼如下:
/* then switch user and group to "shell" */
setgid(AID_SHELL);
setuid(AID_SHELL);
代碼之前都是root權限，只有執(zhí)行這兩句之后才變成shell權限的。
這樣我們就可以引出root過程中獲得root權限的方法了，那就是讓以上面setgid和setuid函數(shù)執(zhí)行失敗，也就是降級失敗，那就繼續(xù)在root權限下面運行了。
這其實利用了一個RageAgainstTheCage漏洞，具體分析請參考《Android adb setuid提權漏洞的分析》和《RageAgainstTheCage》。這里面做一個簡單說明：
復制代碼 代碼如下:
1、出廠設置的ro.secure屬性為1，則adbd也將運行在shell用戶權限下；
2、adb工具創(chuàng)建的進程ratc也運行在shell用戶權限下；
3、ratc一直創(chuàng)建子進程（ratc創(chuàng)建的子程序也 將會運行在shell用戶權限下），緊接著子程序退出，形成僵尸進程，占用shell用戶的進程資源，直到到達shell用戶的進程數(shù)為 RLIMIT_NPROC的時候（包括adbd、ratc及其子程序），這是ratc將會創(chuàng)建子進程失敗。這時候殺掉adbd，adbd進程因為是 Android系統(tǒng)服務，將會被Android系統(tǒng)自動重啟，這時候ratc也在競爭產(chǎn)生子程序。在adbd程序執(zhí)行上面setgid和setuid之 前，ratc已經(jīng)創(chuàng)建了一個新的子進程，那么shell用戶的進程限額已經(jīng)達到，則adbd進程執(zhí)行setgid和setuid將會失敗。根據(jù)代碼我們發(fā) 現(xiàn)失敗之后adbd將會繼續(xù)執(zhí)行。這樣adbd進程將會運行在root權限下面了。
3、這是重新用adb連接設備，則adb將會運行在root權限下面了。
通過上面的介紹我們發(fā)現(xiàn)利用RageAgainstTheCage漏洞，可以使adbd獲得root權限，也就是adb獲得了root權限。拿到root權限剩下的問題就好辦了，復制之后的su程序到系統(tǒng)中（見上文《Android系統(tǒng)root原理分析》的介紹），都是沒有什么技術含量的事情了。
其實堵住adbd的這個漏洞其實也挺簡單的：
復制代碼 代碼如下:
/* then switch user and group to "shell" */
if (setgid(AID_SHELL) != 0) {
exit(1);
}
if (setuid(AID_SHELL) != 0) {
exit(1);
}
|
網(wǎng)站導航
發(fā)表于 2021-10-7 20:06
收藏
淘帖
頂一個
踩
提升卡
置頂卡
變色卡
千斤頂
znds.com 