Android Hook技術(shù)防范漫談
背景
當下，數(shù)據(jù)就像水、電、空氣一樣無處不在，說它是“21世紀的生產(chǎn)資料”一點都不夸張，由此帶來的是，各行業(yè)對于數(shù)據(jù)的爭奪熱火朝天。隨著互聯(lián)網(wǎng)和數(shù)據(jù)的思維深入人心，一些灰色產(chǎn)業(yè)悄然興起，數(shù)據(jù)販子、爬蟲、外掛軟件等等也接踵而來，互聯(lián)網(wǎng)行業(yè)中各公司競爭對手之間不僅業(yè)務(wù)競爭十分激烈，黑科技的比拼也越發(fā)重要。隨著移動互聯(lián)網(wǎng)的興起，爬蟲和外掛也從單一的網(wǎng)頁轉(zhuǎn)向了App，其中利用Android平臺下Dalvik模式中的Xposed Installer和Cydia Substrate框架對App的函數(shù)進行Hook這一招，堪稱老牌經(jīng)典。
接下來，本文將分別介紹針對這兩種框架的防護技術(shù)。
Xposed Installer
原理
Zygote
在Android系統(tǒng)中App進程都是由Zygote進程“孵化”出來的。Zygote進程在啟動時會創(chuàng)建一個虛擬機實例，每當它“孵化”一個新的應(yīng)用程序進程時，都會將這個Dalvik虛擬機實例復(fù)制到新的App進程里面去，從而使每個App進程都有一個獨立的Dalvik虛擬機實例。
Zygote進程在啟動的過程中，除了會創(chuàng)建一個虛擬機實例之外還會將Java Rumtime加載到進程中并注冊一些Android核心類的JNI（Java Native Interface，Java本地接口）方法。一個App進程被Zygote進程孵化出來的時候，不僅會獲得Zygote進程中的虛擬機實例拷貝，還會與Zygote進程一起共享Java Rumtime，也就是可以將XposedBridge.jar這個Jar包加載到每一個Android App進程中去。安裝Xposed Installer之后，系統(tǒng)app_process將被替換，然后利用Java的Reflection機制覆寫內(nèi)置方法，實現(xiàn)功能劫持。下面我們來看一下細節(jié)。
Hook和Replace
Xposed Installer框架中真正起作用的是對方法的Hook和Replace。在Android系統(tǒng)啟動的時候，Zygote進程加載XposedBridge.jar，將所有需要替換的Method通過JNI方法hookMethodNative指向Native方法xposedCallHandler，這個方法再通過調(diào)用handleHookedMethod這個Java方法來調(diào)用被劫持的方法轉(zhuǎn)入Hook邏輯。
上面提到的hookMethodNative是XposedBridge.jar中的私有的本地方法，它將一個方法對象作為傳入?yún)?shù)并修改Dalvik虛擬機中對于該方法的定義，把該方法的類型改變?yōu)镹ative并將其實現(xiàn)指向另外一個B方法。
換言之，當調(diào)用那個被Hook的A方法時，其實調(diào)用的是B方法，調(diào)用者是不知道的。在hookMethodNative的實現(xiàn)中，會調(diào)用XposedBridge.jar中的handleHookedMethod這個方法來傳遞參數(shù)。handleHookedMethod這個方法類似于一個統(tǒng)一調(diào)度的Dispatch例程，其對應(yīng)的底層的C++函數(shù)是xposedCallHandler。而handleHookedMethod實現(xiàn)里面會根據(jù)一個全局結(jié)構(gòu)hookedMethodCallbacks來選擇相應(yīng)的Hook函數(shù)并調(diào)用他們的before和after函數(shù)，當多模塊同時Hook一個方法的時候Xposed會自動根據(jù)Module的優(yōu)先級來排序。
調(diào)用順序如下：A.before -> B.before -> original method -> B.after -> A.after
檢測
在做Android App的安全防御中檢測點眾多，Xposed Installer檢測是必不可少的一環(huán)。對于Xposed框架的防御總體上分為兩層：Java層和Native層。
Java層檢測
需要說明的是，Java層的檢測基本只能檢測出基礎(chǔ)的Xposed Installer框架，而不能防護其對App內(nèi)方法的Hook，如果框架中帶有反檢測則Java層檢測大多不起作用。
下面列出Java層的檢測點，僅供參考。
① 通過PackageManager查看安裝列表
最簡單的檢測，我們調(diào)用Android提供的PackageManager的API來遍歷系統(tǒng)中App的安裝情況來辨別是否有安裝Xposed Installer相關(guān)的軟件包。
- PackageManager packageManager = context.getPackageManager();
- List applicationInfoList = packageManager.getInstalledApplications(PackageManager.GET_META_DATA);
- for (ApplicationInfo applicationInfo: applicationInfoList) {
- if (applicationInfo.packageName.equals("de.robv.android.xposed.installer")) {
- // is Xposed TODO... }
- }
通常情況下使用Xposed Installer框架都會屏蔽對其的檢測，即Hook掉PackageManager的getInstalledApplications方法的返回值，以便過濾掉de.robv.android.xposed.installer來躲避這種檢測。
② 自造異常讀取棧
Xposed Installer框架對每個由Zygote孵化的App進程都會介入，因此在程序方法異常棧中就會出現(xiàn)Xposed相關(guān)的“身影”，我們可以通過自造異常Catch來讀取異常堆棧的形式，用以檢查其中是否存在Xposed的調(diào)用方法。
- try {
- throw new Exception("blah");
- } catch(Exception e) {
- for (StackTraceElement stackTraceElement: e.getStackTrace()) {
- // stackTraceElement.getClassName() stackTraceElement.getMethodName() 是否存 在Xposed
- }
- }
- E/GEnvironment: no such table: preference (code 1): while compiling: SELECT keyguard_show_livewallpaper FROM preference
- ...
- at com.meituan.test.extpackage.ExtPackageManager.checkUpdate(ExtPackageManager.java:127)
- at com.meituan.test.MiFGService$1.run(MiFGService.java:41)
- at android.os.Looper.loop(Looper.java:136)
- at android.app.ActivityThread.main(ActivityThread.java:5072)
- at java.lang.reflect.Method.invokeNative(Native Method)
- at java.lang.reflect.Method.invoke(Method.java:515)
- ...
- at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
- at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:609)
- at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132) //發(fā)現(xiàn)Xposed模塊
- at dalvik.system.NativeStart.main(Native Method)
③ 檢查關(guān)鍵Java方法被變?yōu)镹ative JNI方法
當一個Android App中的Java方法被莫名其妙地變成了Native JNI方法，則非常有可能被Xposed Hook了。由此可得，檢查關(guān)鍵方法是不是變成Native JNI方法，也可以檢測是否被Hook。
通過反射調(diào)用Modifier.isNative(method.getModifiers())方法可以校驗方法是不是Native JNI方法，Xposed同樣可以篡改isNative這個方法的返回值。
④ 反射讀取XposedHelper類字段
通過反射遍歷XposedHelper類中的fieldCache、methodCache、constructorCache變量，讀取HashMap緩存字段，如字段項的key中包含App中唯一或敏感方法等，即可認為有Xposed注入。
- boolean methodCache = CheckHook(clsXposedHelper, "methodCache", keyWord);
- private static boolean CheckHook(Object cls, String filedName, String str) {
- boolean result = false;
- String interName;
- Set keySet;
- try {
- Field filed = cls.getClass().getDeclaredField(filedName);
- filed.setAccessible(true);
- keySet = filed.get(cls)).keySet();
- if (!keySet.isEmpty()) {
- for (Object aKeySet: keySet) {
- interName = aKeySet.toString().toLowerCase();
- if (interName.contains("meituan") || interName.contains("dianping") ) {
- result = true;
- break;
- }
- }
- }
- ...
- return result;
- }
Native層檢測
由上文可知，無論在Java層做何種檢測，Xposed都可以通過Hook相關(guān)的API并返回指定的結(jié)果來繞過檢測，只要有方法就可以被Hook。如果僅在Java層檢測就顯得很徒勞，為了有效提搞檢測準確率，就須做到Java和Native層同時檢測。每個App在系統(tǒng)中都有對應(yīng)的加載庫列表，這些加載庫列表在/proc/下對應(yīng)的pid/maps文件中描述，在Native層讀取/proc/self/maps文件不失為檢測Xposed Installer的有效辦法之一。由于Xposed Installer通常只能Hook Java層，因此在Native層使用C來解析/proc/self/maps文件，搜檢App自身加載的庫中是否存在XposedBridge.jar、相關(guān)的Dex、Jar和So庫等文件。
- bool is_xposed()
- {
- bool rel = false;
- FILE *fp = NULL;
- char* filepath = "/proc/self/maps";
- ...
- string xp_name = "XposedBridge.jar";
- fp = fopen(filepath,"r"))
- while (!feof(fp))
- {
- fgets(strLine,BUFFER_SIZE,fp);
- origin_str = strLine;
- str = trim(origin_str);
- if (contain(str,xp_name))
- {
- rel = true; //檢測到Xposed模塊
- break;
- }
- }
- ...
- }
Cydia Substrate
原理
Cydia Substrate注入Hook的一個典型流程如下圖所示，在Java層配置注入的關(guān)鍵So庫libsubstrate.so和libsubstratedvm.so。考慮到Java層檢測強度太低，Substrate的檢測主要在Native層來實現(xiàn)。
檢測
動態(tài)加載式檢測
讀取/proc/self/maps，列出了App中所有加載的文件。
上圖為Cydia Substrate在Android 4.4上注入后的進程maps表，其中l(wèi)ibsubstrate.so和libsubstrate-dvm.so兩個文件為Substrate必載入文件。通過IDA Pro分析對其分析。
先來看libsubstrate-dvm.so的導(dǎo)出表，共有9個函數(shù)導(dǎo)出。
當進程maps表中出現(xiàn)libsubstrate-dvm.so，可以嘗試去load該so文件并調(diào)用MSJavaHookMethod方法，它會返回該方法的地址即判定為惡意模塊（第三方程序）。
- void* lookup_symbol(char* libraryname,char* symbolname)
- {
- void *imagehandle = dlopen(libraryname, RTLD_GLOBAL | RTLD_NOW);
- if (imagehandle != NULL){
- void * sym = dlsym(imagehandle, symbolname);
- if (sym != NULL){
- return sym; //發(fā)現(xiàn)Cydia Substrate相關(guān)模塊
- }
- ...
- }
該方式基于載入庫文件的文件名或文件路徑和導(dǎo)出函數(shù)來判斷是否為惡意模塊，如果完全依賴此方式來判斷可能會誤判，但也不失為檢測方式的一個點。
基于方法特征碼檢測
特征碼即用來判斷某段數(shù)據(jù)屬于哪個計算機字段。在非Root環(huán)境下一般一個正常App在啟動時候，系統(tǒng)會調(diào)度相關(guān)大小的內(nèi)存、空間給App使用，此時App的運行環(huán)境內(nèi)產(chǎn)生的數(shù)據(jù)、內(nèi)存、存儲等是獨立于其它App的（即獨立運行在沙箱中）。因為處于運行沙箱環(huán)境中的進程對沙箱的內(nèi)存有最高讀寫權(quán)限，當我們的App進程被惡意模塊附加或注入時，就可以通過對當前進程的PID所對應(yīng)的maps中加載的模塊進行合法校驗。這里的模塊校驗我們可以采取對單個模塊內(nèi)容取樣來判斷是否為惡意模塊，這種方式被定義為“基于方法的特征碼檢測”。
下面對一段程序段中OpcodeSample方法來提取特征碼。
方法原型：
- #define LOGD(fmt, args...) __android_log_print(ANDROID_LOG_DEBUG,LOG_TAG, fmt, ##args)
- void OpcodeSample(int a ,int b){
- int c,d,e;
- c = a + b;
- d = a * b;
- e = a / b;
- LOGD("Hello It's c !%s\n", c);
- LOGD("Hello It's d !%s\n", d);
- LOGD("Hello It's e !%s\n", e);
- return;
- }
通過IDA Pro對其分析。
左側(cè)紅色方框代表為OpcodeSample方法的操作碼，右邊為操作碼對應(yīng)ARM平臺的指令集。我們要在左側(cè)的操作碼中取出一段作為OpcodeSample的定位特征碼，選用__android_log_print方法調(diào)用指令集上下文，來確定特征碼。
第一次取樣："03 20 31 46 42 46 FF F7 ?? EA"
通過第一次取樣，查找結(jié)果有三處相似，再進一步分析。這次我們加入一個常量取樣：
第二次取樣："7E 44 ?? ?? F8 44 03 20 31 46 42 46 FF F7 ?? EA"
繼而得出唯一特征碼，到此，我們對特征碼方法取樣有了初步的了解。下面來把它轉(zhuǎn)為實用的技能——動態(tài)加載式檢測+特征碼結(jié)合。
我們對libsubstrate-dvm.so中導(dǎo)出函數(shù)MSJavaHookMethod來精準定位。
IDA PRO導(dǎo)出函數(shù)表如圖：
第三次取樣："55 57 56 53 E8 CC 14 ?? ?? 81 C3 DB ?? ?? ?? 8D 64 ?? ?? 8B 83 F4 ?? ?? ??"
以上即為對Cydia Substrate的注入檢測識別，通過檢測/proc/self/maps下的加載so庫列表得到各個庫文件絕度路徑，通過fopen函數(shù)將so庫的內(nèi)容以16進制讀進來放在內(nèi)存里面進行規(guī)則比對，采用字符串模糊查找來檢測是否命中黑名單中的方法特征碼。
總結(jié)
在安全對抗領(lǐng)域，相比攻擊方，防守方歷來處于弱勢的一方。上文所提到的Xposed Installer和Cydia Substrate的檢測也僅僅是保障App安全的手段之一。App安全的防御不應(yīng)僅僅依賴于此，應(yīng)該構(gòu)建起整體的安全防御閉環(huán)，盡可能在所有已知的可能攻擊點都追加檢測，再配合代碼加固，將防御代碼隱藏。遺憾的是App防御代碼隱藏再深也終究會被破解，僅僅依賴于客戶端的防御顯然是不足的。移動互聯(lián)網(wǎng)領(lǐng)域的整體安全防御應(yīng)該是走端云結(jié)合協(xié)作之道，共同防御，方能在攻防對抗中占據(jù)優(yōu)勢地位。
【本文為51CTO專欄機構(gòu)“美團點評技術(shù)團隊”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號聯(lián)系機構(gòu)獲取授權(quán)】
