簡介：

調(diào)試手機是Android 6.0的32位的手機。樣本是自己寫的一個demo小程序。加固時間為今年的12月中旬左右。

Java層分析

殼的入口是MyWrapperProxyApplication，繼承了父類 WrapperProxyApplication，并且實現(xiàn)了父類中的方法 initProxyApplication。

我們找到父類WrapperProxyApplication，首先找到最先執(zhí)行的 attachBaseContext 方法。

可以看到首先獲得了 basContext，這個 baseContext 變量會在后面 so 層中獲取，進行 attach 新的 DelegateApplication。然后是給 ????shellApp 賦值，在調(diào)用 initProxyApplication，就是上面圖中 MyWrapperProxyApplication 中實現(xiàn)的 initProxyApplication，可以看到

是為了獲取 libshell-super.2019 的 so 文件路徑進行 System.load 加載。到這里，我們Java層的分析就差不多了，下面進入SO層分析。

2.SO層分析

2.1 總敘

一般的話是先分析.init_array節(jié)區(qū)，再分析JNI_OnLoad。在這里我們先分析.init_array節(jié)區(qū)里的函數(shù)，如圖所示：

從中我們可以看到有很多函數(shù)，那么我們就要考慮這些函數(shù)都做了什么事了。

同時我們可以看一下字符串有沒有被處理，如果被處理的話，那么此部分極可能是做一些初始化工作和解密一些東西。

字符串窗口如圖所示：

可以看出有一部分字符串是解密狀態(tài)的，在這里我們可以用一下elf-dump-fix 工具來dump出字符串被解密的so，然后分析。

此工具來自

接下來我們開始分析JNI_OnLoad，按F5查看函數(shù)的偽代碼，把函數(shù)參數(shù)改為JavaVM *,在這里我們可以看一下它的Graph窗口，如下圖：

從中可以看出，函數(shù)被混淆的比較厲害。分支較多，在這里因為混淆難度不是很高，即混淆是比較死的，不是很靈活，那么是什么意思呢，

它的路徑只有一條，所以直接IDA動態(tài)調(diào)試就可以的，咱們這里就不展開講如何處理混淆了。直接開始重點函數(shù)分析。

首先是 sub_1CA8C 函數(shù)，在這個函數(shù)里面對殼運行環(huán)境數(shù)據(jù)的初始化和獲取，以及最重要的是找到被抽取的 Dex 文件壓縮后的數(shù)據(jù)，

并釋放到內(nèi)存中。

還有一個是sub_CC9C 函數(shù)，它做了很多事情，完成了對系統(tǒng)函數(shù)的 hook，如mmap、fopen等，加載了Dex文件，并進行了對 ProxyApplication

到 DelegateApplication 的替換。

2.2??sub_1CA8C函數(shù)

下面開始說sub_1CA8C函數(shù)，

那么如何定位到sub_1CA8C函數(shù)呢，我這里說一下。

咱們在這里定位v44變量，即JavaVM *，如圖：

在這里可以看到，sub_1CA8C函數(shù)傳進去了JavaVM *，那么此函數(shù)就需要分析一下了。

我們點進去之后可以看到此函數(shù)做了很多事，如下圖：

在這里，初始化了一些環(huán)境信息，比如系統(tǒng)SDK版本、虛擬機類型、殼的一些信息等等，并且把他們都存放到此函數(shù)的第三個函數(shù)里，

那么它的類型應該是一個結(jié)構(gòu)體。當然它的類型可以在IDA中不做修改。

可以對比一下它的原so，即字符串未解密時，如圖：

可以看到，字符串都是被加密了，信息獲取不到。那么我們從內(nèi)存中把so給dump下來，對我們的靜態(tài)分析提供了很大的幫助。

當然，也僅僅是靜態(tài)分析，動態(tài)調(diào)試時，這些字符串都解密了。

接下里，我們接著看這個函數(shù)，

隨后，打開了o0oooOO0ooOo.dat文件，

需要一提的是*(v5 + 151)存的是虛擬機的類型，即 1==dalvik? 2==art。

后面就會根據(jù)這個走對應的分支，如下圖：

此圖為dalivik分支

此為art分支

在sub_1BF80中就會找到被抽取加密的dex文件，并對它進行解密，即下面這個文件，

在此函數(shù)中有一下三個關(guān)鍵點，如圖：

打開文件，然后映射，sub_1BF20函數(shù)解密。

IDA動態(tài)調(diào)試視角如下：

到此為止，sub_1CA8C函數(shù)的分析到此結(jié)束。

2.3??sub_CC9C函數(shù)

下面進行sub_CC9C函數(shù)的分析。

咱們先看此函數(shù)的第一個重點，如圖：

同樣是先判斷虛擬機類型，咱們直接看art的。

緊接著判斷sdk版本，我這里走的是sub_AD24分支。接著看這個函數(shù)干了什么事。

此函數(shù)里面同樣會調(diào)用sub_5110函數(shù)，此函數(shù)完成了非常重要的工作，調(diào)用 Java 層的的 installDexes 方法裝載 Dex 文件。

最后進行hook了幾個方法，即mmap、open等，同樣我們會發(fā)現(xiàn)導出函數(shù)窗口里有mmap函數(shù)。如下圖：

Hook mmap函數(shù)的目的就是在系統(tǒng)調(diào)用ClassLoader加載dex文件的時候，在mmap函數(shù)里返回映射后已經(jīng)解密的被抽取的dex文件地址。

如下圖窗口：

到這里sub_AD24函數(shù)分析完了，咱們接著分析sub_CC9C函數(shù)。

接下來，到了重要的分支，如下圖：

根據(jù)*(v3+152)的值判斷走哪個分支，執(zhí)行的邏輯區(qū)別并不是很大，都是要把抽取的函數(shù)指令給還原到原始dex中。

但是sub_17FFC中沒有混淆，邏輯比較清晰，而sub_10B8C中存在混淆，當然混淆程度也不是很高。

在sub_10B8C函數(shù)中，會解壓被加密的函數(shù)指令數(shù)據(jù)，然后進行填充到dex中。

sub_288F4函數(shù)為解壓函數(shù)，需要解壓兩部分數(shù)據(jù)，即indexdata和bytecode。

sub_FB64函數(shù)實現(xiàn)指令填充，如圖：

v4即為dex起始地址，當此函數(shù)執(zhí)行完之后，從此地址處可以dump出完整的dex文件。

接下來就是完成 ProxyApplication 到 DelegateApplication 的替換過程。如下圖：

緊接著調(diào)用WrapperProxyApplication類中的onCreate方法，如圖：

onCreate方法中調(diào)用了一個動態(tài)注冊的方法，如圖：

我們在SO中找到其地址，在這里直接來到.data節(jié)區(qū)，找到其函數(shù)地址，如下圖：

函數(shù)sub_472C，如下圖所示：

那么它完成了API層所有的Application引用替換和ContentProviders替換。

最后回到用戶的Application。

到此為止，對于此殼的分析全部完成了。

3.混淆處理

在此so中出現(xiàn)了大量的混淆，可以這樣說，但凡是比較重要的函數(shù)都被混淆了。那么我們該怎樣去處理呢，即如何提高逆向分析的效率？

我們可以采用這兩種方式，IDA調(diào)試記錄指令和模擬執(zhí)行記錄指令，其目的都是記錄指令，然后用腳本進行patch修復。

在這里分享一些大佬反arm混淆的帖子：

4.閑談

相信大家應該注意到本文沒有提到反調(diào)試，是的，在分析過程中我并沒有碰到反調(diào)試?；蛟S會有斷點陷阱、時間反調(diào)試等，但我并沒有走到

那里。當然還有必備的簽名校驗。那么我覺得最大的難點就在于混淆，其他的還好。

通過分析，收獲良多。希望看完此貼的伙伴們也能有所收獲！！

最后于 2020-12-23 17:20

被[軍]編輯

，原因：

上傳的附件：

lg.rar

(1.99MB，53次下載)

總結(jié)

以上是生活随笔為你收集整理的android安全分析师,乐固分析-Android安全-看雪论坛-安全社区|安全招聘|bbs.pediy.com...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。