上一篇文章

Android adb 原始碼分析

理論基礎

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程式到系統中