需求來源
在逆向分析中，肯定是越快地定位到目標函數越好，那麼有沒有這樣的一種工具可以快速地輔助分析人員定位到目標函數呢？
最早的一個想法是這樣的：
- 通過某種機制讓APP輸出函數調用時候的日誌記錄。
- APP在運行的時候可能會輸出很多條記錄，而目標函數的調用也會被淹沒在日誌的大海里，如何定位出來？
- 打開APP，但是不執行目標功能，得到日誌記錄A。
- 執行目標功能，這時候得到日誌記錄B。
- 如果把日誌A記錄設置爲白名單，執行過濾，B過濾A，得到日誌A，那麼F可能會有目標函數的調用記錄。
- 如果F中得不到目標函數，說明在得到記錄A時，目標函數可能已經執行過了（線程的方式）。
- 如果過濾後的F日誌仍然是一個海量數據，那麼重複執行目標功能N次，分別得到B2,B3……Bn,並過濾A日誌，分別得到過濾後的日誌F2,F3……Fn，然後再過濾出被剛好執行了N次的函數。那麼這個結果就很可能會比較小了。
可能的方法
- APP插樁法：對APP進行反編譯，把每個函數調用都加入LOG函數，回編譯出新包，安裝運行後這樣每個函數調用時就會有日誌輸出。參考：帶你開發一款給Apk中自動注入代碼工具icodetools(完善篇)、Android中利用icodetools工具快速定位App破解中關鍵點方法
- 安卓內核MOD或HOOK法：修改安卓系統內核，不修改APP本身，在安卓調用函數開始前後打印LOG。
插樁法
- 需要修改APP，針對有加殼保護的無法操作，二次打包有可能會失敗，如果APP有簽名校驗，文件校驗等也會失效。
- 整個過程比較耗時，需要進行反編譯–遍歷插樁–回編譯–簽名。
- 每個APP都需要修改一遍。
- 無法生成調用樹。
內核MOD或HOOK法
- 難度在於需要分析到調用函數代碼處，並加以修改。
- 源碼的編譯比較耗時，工程較爲龐大和複雜。
- 優點是：黑盒處理，無需每次修改APP。
- 一次MOD，終身使用。
- 可以生成調用樹。dvmCallMethod。
DEMO示例
- DEMO運行後界面上有一個Button，Click事件會依次調用F1,F2,其中F1會調用F3，F3會調用F4，F2會調用F5。DEMO運行後就一直有一個線程或定時器在定時地調用F6函數，F6又會依次調用F1,F2。請用上述方法快速定位出Button的Click函數。如果混淆後呢？如果調用的是native函數呢？能不能捕獲到？
- 針對微信，不做逆向分析，請用上述方法快速定位出擲骰子的關鍵函數。
參考
- 帶你開發一款給Apk中自動注入代碼工具icodetools(完善篇)
- Android中利用icodetools工具快速定位App破解中關鍵點方法
- TraceDroid.pdf
- Tracedroid - Dynamic Android app analysis
- android/4.0.3/dalvik/vm/mterp/out/InterpC-portable.cpp
- Dalvik虛擬機的運行過程分析 - 老羅的Android之旅 - 博客頻道 - CSDN.NET
- Dalvik虛擬機進程和線程的創建過程分析 - 老羅的Android之旅 - 博客頻道 - CSDN.NET
- 參考xposed代碼XposedBridge_hookMethodNative函數
- 參考Android源碼/dalvik/vm/interp/Stack.cpp函數dvmCallMethodV，dvmIsNativeMethod判斷函數是否是Native函數。
- NDroid.pdf
- Dynamic Analysis of Android Malware
- Android熱補丁技術—dexposed原理簡析(阿里Hao)
替換方法的關鍵在於native層怎麼影響內存裏的java代碼，我們知道java代碼裏將一個方法聲明爲native方法時,對此函數的調用就會到native世界裏找，AndFix原理就是將一個不是native的方法修改成native方法，然後在native層進行替換，通過dvmCallMethod_fnPtr函數指針來調用libdvm.so中的dvmCallMethod()來加載替換後的新方法，達到替換方法的目的。Jni反射調用java方法時要用到一個jmethodID指針,這個指針在Dalvik裏其實就是Method類,通過修改這個類的一些屬性就可以實現在運行時將一個方法修改成native方法。Profiler control flow
Whenever the original VM’s bytecode interpreter enters of leaves a function, the
methods TRACE METHOD ENTER, TRACE METHOD EXIT and TRACE METHOD UNROLL
(for unrolling exceptions) are called. These functions check for a global boolean
methodTrace.traceEnabled to be true, and if it is, call dvmMethodTraceAdd()
which writes trace data to an output file