在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 eth0 192.168.1.188

在普通使用者或者system使用者許可權下面這條命令是不起作用的，但是不會返回失敗和異常，那麼怎樣實現這個功能呢（兩種思路）。

1、系統啟動的時候init程序建立一個後臺程序，該程序處於root使用者許可權下面。用來監聽系統中應用程式的請求（可以用socket實現），並代其完成。這樣應用程式就可以執行root使用者許可權的任務了。

2、實現一個虛擬的裝置，該裝置的功能就是在核心態幫應用程式執行相應的命令。Linux核心態沒有許可權的問題了。肯定可以執行成功。

     解決設定網絡卡IP地址問題時，選擇是後者相對來說設計比較簡單。

應用程式利用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:return true;

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 root root   

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許可權。

管理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許可權使用的，防止被惡意程式濫用。
原始碼地址：

帶著兩個問題我們來分析原始碼：
1、superuser是怎麼知道誰想用root許可權？ 
2、superuser是如何把使用者的選擇告訴su程式的呢？
即superuser和su程式是如何通訊的，他們倆位於不通的時空，一個在java虛擬機器中，一個在linux的真實程序中。
共有兩個activity: 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);
   FileOutputStream suOutStream = 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("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();

上面提到的su肯定是動過手腳的,有程序使用root許可權，superuser是怎麼知道的，看完su的程式碼明白了，關鍵是句：

  sprintf(sysCmd, "am start -a android.intent.action.MAIN 

                                 -n com.koushikdutta.superuser/com.koushikdutta.superuser.SuperuserRequestActivity 

                                 --ei uid %d --ei pid %d > /dev/null", g_puid, ppid);

  if (system(sysCmd))
   return executionFailure("am.");

原理是am命令，看了下am的用法，明白了：
在Android中，除了從介面上啟動程式之外，還可以從命令列啟動程式，使用的是命令列工具am啟動的方法為

$ adb shell
$ su
# am start -n ｛包(package)名｝/｛包名｝.{活動(activity)名稱}

程式的入口類可以從每個應用的AndroidManifest.xml的檔案中得到，以計算器（calculator）為例，它的

<manifest xmlns:android="http://schemas.android.com/apk/res/android" …

package="com.android.calculator2" …>…

由此計算器（calculator）的啟動方法為：

# am start -n com.android.calculator2/com.android.calculator2.Calculator

一般情況希望，一個Android應用對應一個工程。值得注意的是，有一些工程具有多個活動（activity），而有一些應用使用一個工程。例如：在Android介面中，Music和Video是兩個應用，但是它們使用的都是packages/apps/Music這一個工程。而在這個工程的AndroidManifest.xml檔案中，有包含了不同的活動（activity）。

Music 和 Video（音樂和視訊）的啟動方法為：

# am start -n com.android.music/com.android.music.MusicBrowserActivity

# am start -n com.android.music/com.android.music.VideoBrowserActivity

# am start -n com.android.music/com.android.music.MediaPlaybackActivity

 啟動瀏覽器 :

am start -a android.intent.action.VIEW -d  http://www.google.cn/

撥打電話 :

am start -a android.intent.action.CALL -d tel:10086

啟動 google map直接定位到北京 :

am start -a android.intent.action.VIEW geo:0,0?q=beijing

  usage: am [subcommand] [options]（am工具的使用方法）

    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 (otherwise decode REPORT_KEY_STREAMRESULT)
        -e <NAME> <VALUE>: set argument <NAME> to <VALUE>
        -p <FILE>: write profiling data to <FILE>
        -w: wait for instrumentation to finish 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 whitelistCallInfo callInfo;
  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原理

在 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執行在一個程序中，這樣可以共享資料，應該會很有用的。 signapk編譯結束後在 android目錄下/out/host/linux-x86/framework/signapk.jar 使用方法：java -jar signapk.jar platform.x509.pem platform.pk8 test.apk test_signed.apk檔案。

漏洞— zergRush

提權實現的程式碼，見：

需要了解一下是哪個地方有問題，邊分析邊記錄此次過程。

檔案不大，當然從 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);

相關推薦