AOSP源碼定制-對root定制的補充

介紹

前面通過修改build.prop中的指紋以及對su的修改，完成了基礎的定制修改，但是碰上一些app還是能被檢測到，再進行深入修改。

問題引入

ro.vendor相關

發現測試一個app時總是開不起來，但是測試別人編譯好的脫殼機卻能運行，最后其實只是ro.debuggable的問題，但是在分析的過程中發現了其他幾處遺漏沒有抹除的特征。

這里很明顯,ro.vendor.build的一些參數是有aosp的特征，沒有改成user版本，tests-key。

找了半天沒有找到對應的修改點，查了資料，看了下目錄才反應過來，vendor鏡像是一開始下驅動，運行腳本時直接打包放在vendor目錄下了，是谷歌自己給我編譯好的。



要修改找了資料，有好幾種，一種重新編譯，一種解包修改再壓縮，兩種方法都試了，最后都是沒有效果。

這里我解包修改再重打包，out目錄下，vendor相關的屬性已經修改完成。



編譯刷機后，還是沒效果。

通過啟動流程修改

繼續查資料，可以明確一個事，目前app檢測prop相關屬性，多通過getprop命令，或者通過反射調用android.os.SystemProperties來檢測，它并不會讀到/system/build.prop，/vendor/build.prop文件。

那我們只需要在系統啟動時，找到對應讀取prop文件的流程，在中間處理一下，做點手腳就可以了。

查閱源碼，找到啟動流程中載入prop配置文件的關鍵位置：



這里的關鍵函數是load_properties_from_file，查找跟進。



這里繼續跟進load_properties，很明顯了，他會讀取，然后通過property_set方法，按鍵值對寫入。



我們可以在這里加個判斷，匹配自己要修改的特征，然后自己去set。



再編譯刷機，此時通過getprop命令獲取到的已經是替換后的屬性值了，但是文件中的是不修改的。

adb相關

再測試發現還是被檢測，繼續排查，發現是ro.debuggable的問題。

我將該值置為零，再編譯發現不檢測了。

但是會存在問題，進系統，切到su，data等目錄不再有權限訪問，這是不能接受的。

這里補充一點東西。

adb的root權限是由system/core/adb/adb.c 中控制。主要根據ro.secure以及ro.debuggable等system property來控制。

默認當ro.secure為0時，開啟root權限，為1時再根據ro.debuggable等選項來確認是否可以用開啟root權限，一般會降權返回一個shell用戶權限。因此如果要開啟adb的root權限，有兩種修改的方式:

修改system property ro.secure， 讓ro.secure=0。

修改adb.c 中開啟root 權限的判斷邏輯。

但1方法顯然是很容易被檢測到，正常手機ro.secure的值都是1。

所以直接將ro.debuggable=0,修改adb源碼，達到不降權的目的。

這里就修改一處即可。

將這里的降權判斷函數，返回值強恒為false即可。



再測試adb直接返回了root用戶權限，且ro.debuggable仍然為0。

總結

主要學習到的還是通過修改啟動流程中的載入prop過程，達到抹去特征，可以將之前修改的特征通通使用這個方法進行抹除，更加簡單。

審核編輯：劉清