AOSP源碼定制-對root定制的補(bǔ)充流程

AOSP源碼定制-對root定制的補(bǔ)充

介紹

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

問題引入

ro.vendor相關(guān)

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

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

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



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

這里我解包修改再重打包，out目錄下，vendor相關(guān)的屬性已經(jīng)修改完成。



編譯刷機(jī)后，還是沒效果。

通過啟動流程修改

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

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

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



這里的關(guān)鍵函數(shù)是load_properties_from_file，查找跟進(jìn)。



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



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



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

adb相關(guān)

再測試發(fā)現(xiàn)還是被檢測，繼續(xù)排查，發(fā)現(xiàn)是ro.debuggable的問題。

我將該值置為零，再編譯發(fā)現(xiàn)不檢測了。

但是會存在問題，進(jìn)系統(tǒng)，切到su，data等目錄不再有權(quán)限訪問，這是不能接受的。

這里補(bǔ)充一點東西。

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

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

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

修改adb.c 中開啟root 權(quán)限的判斷邏輯。

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

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

這里就修改一處即可。

將這里的降權(quán)判斷函數(shù)，返回值強(qiáng)恒為false即可。



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

總結(jié)

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

審核編輯：劉清