android安全分析师,乐固分析-Android安全-看雪论坛-安全社区|安全招聘|bbs.pediy.com...
簡(jiǎn)介：
調(diào)試手機(jī)是Android 6.0的32位的手機(jī)。樣本是自己寫(xiě)的一個(gè)demo小程序。加固時(shí)間為今年的12月中旬左右。
Java層分析
殼的入口是MyWrapperProxyApplication，繼承了父類(lèi) WrapperProxyApplication，并且實(shí)現(xiàn)了父類(lèi)中的方法 initProxyApplication。
我們找到父類(lèi)WrapperProxyApplication，首先找到最先執(zhí)行的 attachBaseContext 方法。
可以看到首先獲得了 basContext，這個(gè) baseContext 變量會(huì)在后面 so 層中獲取，進(jìn)行 attach 新的 DelegateApplication。然后是給 ????shellApp 賦值，在調(diào)用 initProxyApplication，就是上面圖中 MyWrapperProxyApplication 中實(shí)現(xiàn)的 initProxyApplication，可以看到
是為了獲取 libshell-super.2019 的 so 文件路徑進(jìn)行 System.load 加載。到這里，我們Java層的分析就差不多了，下面進(jìn)入SO層分析。
2.SO層分析
2.1 總敘
一般的話(huà)是先分析.init_array節(jié)區(qū)，再分析JNI_OnLoad。在這里我們先分析.init_array節(jié)區(qū)里的函數(shù)，如圖所示：
從中我們可以看到有很多函數(shù)，那么我們就要考慮這些函數(shù)都做了什么事了。
同時(shí)我們可以看一下字符串有沒(méi)有被處理，如果被處理的話(huà)，那么此部分極可能是做一些初始化工作和解密一些東西。
字符串窗口如圖所示：
可以看出有一部分字符串是解密狀態(tài)的，在這里我們可以用一下elf-dump-fix 工具來(lái)dump出字符串被解密的so，然后分析。
此工具來(lái)自
接下來(lái)我們開(kāi)始分析JNI_OnLoad，按F5查看函數(shù)的偽代碼，把函數(shù)參數(shù)改為JavaVM *,在這里我們可以看一下它的Graph窗口，如下圖：
從中可以看出，函數(shù)被混淆的比較厲害。分支較多，在這里因?yàn)榛煜y度不是很高，即混淆是比較死的，不是很靈活，那么是什么意思呢，
它的路徑只有一條，所以直接IDA動(dòng)態(tài)調(diào)試就可以的，咱們這里就不展開(kāi)講如何處理混淆了。直接開(kāi)始重點(diǎn)函數(shù)分析。
首先是 sub_1CA8C 函數(shù)，在這個(gè)函數(shù)里面對(duì)殼運(yùn)行環(huán)境數(shù)據(jù)的初始化和獲取，以及最重要的是找到被抽取的 Dex 文件壓縮后的數(shù)據(jù)，
并釋放到內(nèi)存中。
還有一個(gè)是sub_CC9C 函數(shù)，它做了很多事情，完成了對(duì)系統(tǒng)函數(shù)的 hook，如mmap、fopen等，加載了Dex文件，并進(jìn)行了對(duì) ProxyApplication
到 DelegateApplication 的替換。
2.2??sub_1CA8C函數(shù)
下面開(kāi)始說(shuō)sub_1CA8C函數(shù)，
那么如何定位到sub_1CA8C函數(shù)呢，我這里說(shuō)一下。
咱們?cè)谶@里定位v44變量，即JavaVM *，如圖：
在這里可以看到，sub_1CA8C函數(shù)傳進(jìn)去了JavaVM *，那么此函數(shù)就需要分析一下了。
我們點(diǎn)進(jìn)去之后可以看到此函數(shù)做了很多事，如下圖：
在這里，初始化了一些環(huán)境信息，比如系統(tǒng)SDK版本、虛擬機(jī)類(lèi)型、殼的一些信息等等，并且把他們都存放到此函數(shù)的第三個(gè)函數(shù)里，
那么它的類(lèi)型應(yīng)該是一個(gè)結(jié)構(gòu)體。當(dāng)然它的類(lèi)型可以在IDA中不做修改。
可以對(duì)比一下它的原so，即字符串未解密時(shí)，如圖：
可以看到，字符串都是被加密了，信息獲取不到。那么我們從內(nèi)存中把so給dump下來(lái)，對(duì)我們的靜態(tài)分析提供了很大的幫助。
當(dāng)然，也僅僅是靜態(tài)分析，動(dòng)態(tài)調(diào)試時(shí)，這些字符串都解密了。
接下里，我們接著看這個(gè)函數(shù)，
隨后，打開(kāi)了o0oooOO0ooOo.dat文件，
需要一提的是*(v5 + 151)存的是虛擬機(jī)的類(lèi)型，即 1==dalvik? 2==art。
后面就會(huì)根據(jù)這個(gè)走對(duì)應(yīng)的分支，如下圖：
此圖為dalivik分支
此為art分支
在sub_1BF80中就會(huì)找到被抽取加密的dex文件，并對(duì)它進(jìn)行解密，即下面這個(gè)文件，
在此函數(shù)中有一下三個(gè)關(guān)鍵點(diǎn)，如圖：
打開(kāi)文件，然后映射，sub_1BF20函數(shù)解密。
IDA動(dòng)態(tài)調(diào)試視角如下：
到此為止，sub_1CA8C函數(shù)的分析到此結(jié)束。
2.3??sub_CC9C函數(shù)
下面進(jìn)行sub_CC9C函數(shù)的分析。
咱們先看此函數(shù)的第一個(gè)重點(diǎn)，如圖：
同樣是先判斷虛擬機(jī)類(lèi)型，咱們直接看art的。
緊接著判斷sdk版本，我這里走的是sub_AD24分支。接著看這個(gè)函數(shù)干了什么事。
此函數(shù)里面同樣會(huì)調(diào)用sub_5110函數(shù)，此函數(shù)完成了非常重要的工作，調(diào)用 Java 層的的 installDexes 方法裝載 Dex 文件。
最后進(jìn)行hook了幾個(gè)方法，即mmap、open等，同樣我們會(huì)發(fā)現(xiàn)導(dǎo)出函數(shù)窗口里有mmap函數(shù)。如下圖：
Hook mmap函數(shù)的目的就是在系統(tǒng)調(diào)用ClassLoader加載dex文件的時(shí)候，在mmap函數(shù)里返回映射后已經(jīng)解密的被抽取的dex文件地址。
如下圖窗口：
到這里sub_AD24函數(shù)分析完了，咱們接著分析sub_CC9C函數(shù)。
接下來(lái)，到了重要的分支，如下圖：
根據(jù)*(v3+152)的值判斷走哪個(gè)分支，執(zhí)行的邏輯區(qū)別并不是很大，都是要把抽取的函數(shù)指令給還原到原始dex中。
但是sub_17FFC中沒(méi)有混淆，邏輯比較清晰，而sub_10B8C中存在混淆，當(dāng)然混淆程度也不是很高。
在sub_10B8C函數(shù)中，會(huì)解壓被加密的函數(shù)指令數(shù)據(jù)，然后進(jìn)行填充到dex中。
sub_288F4函數(shù)為解壓函數(shù)，需要解壓兩部分?jǐn)?shù)據(jù)，即indexdata和bytecode。
sub_FB64函數(shù)實(shí)現(xiàn)指令填充，如圖：
v4即為dex起始地址，當(dāng)此函數(shù)執(zhí)行完之后，從此地址處可以dump出完整的dex文件。
接下來(lái)就是完成 ProxyApplication 到 DelegateApplication 的替換過(guò)程。如下圖：
緊接著調(diào)用WrapperProxyApplication類(lèi)中的onCreate方法，如圖：
onCreate方法中調(diào)用了一個(gè)動(dòng)態(tài)注冊(cè)的方法，如圖：
我們?cè)赟O中找到其地址，在這里直接來(lái)到.data節(jié)區(qū)，找到其函數(shù)地址，如下圖：
函數(shù)sub_472C，如下圖所示：
那么它完成了API層所有的Application引用替換和ContentProviders替換。
最后回到用戶(hù)的Application。
到此為止，對(duì)于此殼的分析全部完成了。
3.混淆處理
在此so中出現(xiàn)了大量的混淆，可以這樣說(shuō)，但凡是比較重要的函數(shù)都被混淆了。那么我們?cè)撛鯓尤ヌ幚砟?#xff0c;即如何提高逆向分析的效率？
我們可以采用這兩種方式，IDA調(diào)試記錄指令和模擬執(zhí)行記錄指令，其目的都是記錄指令，然后用腳本進(jìn)行patch修復(fù)。
在這里分享一些大佬反arm混淆的帖子：
4.閑談
相信大家應(yīng)該注意到本文沒(méi)有提到反調(diào)試，是的，在分析過(guò)程中我并沒(méi)有碰到反調(diào)試。或許會(huì)有斷點(diǎn)陷阱、時(shí)間反調(diào)試等，但我并沒(méi)有走到
那里。當(dāng)然還有必備的簽名校驗(yàn)。那么我覺(jué)得最大的難點(diǎn)就在于混淆，其他的還好。
通過(guò)分析，收獲良多。希望看完此貼的伙伴們也能有所收獲！！
最后于 2020-12-23 17:20
被[軍]編輯
，原因：
上傳的附件：
lg.rar
(1.99MB，53次下載)
總結(jié)
以上是生活随笔為你收集整理的android安全分析师,乐固分析-Android安全-看雪论坛-安全社区|安全招聘|bbs.pediy.com...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 下载python开发环境
- 下一篇： android 蓝牙数据分包_Andro