不混淆so文件_浅尝ollvm轻度混淆后的加密算法分析
本文為看雪論優(yōu)秀文章
看雪論壇作者ID：Avacci
該題源自看雪高研3W班9月第三題。
目標(biāo)app只有一個很樸素的界面。點擊“CHECK”按鈕會在下方不斷打印加密后的字符串。目標(biāo)就是分析整個加密流程。
由于Yang神手下留情，整個加密流程其實并不復(fù)雜，但是由于使用了ollvm的字符串混淆及控制流平坦化，為靜態(tài)分析增加了不少難度。這種時候就要善于借助各種其他工具和技術(shù)來加快分析過程。
很多時候，我們并不需要弄清一個變量的值在運行時被解密的具體細節(jié)，可以直接在運行時hook出其解密后的值即可。也往往不需要分析明白一個關(guān)鍵加密算法函數(shù)中的每個子函數(shù)的作用，如果發(fā)現(xiàn)了某種常用算法的特征(不一定要完全匹配，可能是變種)，就應(yīng)該大膽猜測并及時做重放測試(CyberChef真的很方便)。畢竟猜錯了沒什么損失，猜對了可能挽回幾年陽壽。
先將apk拖入GDA中，定位到點擊按鈕的處理函數(shù)：
uUIDCheckS0為點擊CHECK按鈕后生成的值，生成算法包含在函數(shù)UUIDCheckSum中，傳入?yún)?shù)是由RandomStringUtils.randomAlphanumeric(36)生成的一個36個字符的隨機字符串。
可以利用Log確定每次調(diào)用UUIDCheckSum的入?yún)⒑头祷刂怠?/p>
由于UUIDCheckSum是native函數(shù)，其實現(xiàn)在so中。將apk解壓后把唯一的so文件拖入ida。
在函數(shù)窗口搜索，定位到UUIDCheckSum具體實現(xiàn)。
本來想先定位返回值再回溯，結(jié)果發(fā)現(xiàn)ida f5識別出來的方法沒有返回值。猜測函數(shù)沒有被正確識別，比如函數(shù)尾部被截斷了之類的。
回到匯編代碼，查看并定位到函數(shù)尾部。
結(jié)果發(fā)現(xiàn)函數(shù)尾部接著的是一段.datadiv_decode開頭的代碼，之前學(xué)習(xí)視頻里有提到這是一段解密用的代碼段。
看了下調(diào)用位置，在.init_array中：
觀察了一下該段代碼反匯編后的結(jié)果，
看起來是對幾個字符串解密，比如stru_37010，byte_37090, byte_370A0, stru_370B0。可以用frida hook得到解密后的值，看看哪些比較有用。
比較感興趣的是stru_37010解密后字符串:
0123456789-_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
看到這串排列整齊的字符序列，首先想到會不會是用到了某種base64編碼。先去定位下用到這串字符串的位置。
兩處定位看反編譯的結(jié)果都比較詭異，可能是因為加密的值被優(yōu)化了。
但看匯編代碼，確實是在這里調(diào)用的。
根據(jù)調(diào)用棧逐層往上找，發(fā)現(xiàn)是在UUIDCheckSum中的sub_F9B8方法里用到。
那么，猜測一下，這個sub_F9B8是以0123456789-_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
為編碼表的base64加密函數(shù)？需要驗證一下
我先用frida寫了兩個hook函數(shù)，一個hook了sub_F9B8函數(shù)，還有一個hook 在sub_F9B8之前調(diào)用的sub_FCB4函數(shù)。因為sub_FCB4以之前生成的隨機數(shù)作為輸入，很可能sub_FCB4會用到處理后的結(jié)果。
Hook函數(shù)的實現(xiàn)：
Hook上后點擊按鈕，得到了結(jié)果。
生成的隨機數(shù)：
經(jīng)過sub_FCB4處理后的中間結(jié)果：
sub_F9B8的第二個傳入?yún)?shù)：
打印出的最終結(jié)果(Logcat)
到CyberChef上驗證猜想。由于猜測sub_F9B8是base64，所以將中間值
2n5ixhQ{-oLqe-4nEi-Xr3dv-u6Rq4uo`ga3作為輸入，設(shè)定下編碼表。發(fā)現(xiàn)結(jié)果果然符合最終結(jié)果。
運氣不錯，驗證成功！
接下來就只要研究sub_FCB4就行了。粗略地觀察了一下反匯編后的代碼，是對傳入的隨機字符串進行逐字節(jié)處理。
先取一次運行的輸入輸出值，放在010editor中做下參照。
輸入：
輸出：
由于函數(shù)不太復(fù)雜，打算先靜態(tài)分析下。首先：
?
輸出的第23個字節(jié)是輸入的第24個字節(jié)，然后定位到代碼。
如果index 不為8、13、14、18、24則結(jié)果就是原字節(jié)異或1(除最后兩個字節(jié)外)。
如果是14：
輸出字節(jié)為52。
其他的第8、13、18、24字節(jié)值都為45。
還剩最后兩個字節(jié)，在函數(shù)尾部處理。
這里v14和v16的值不太好看出來，決定用ida trace看看。?
在trace的log中定位到處理最后兩個字節(jié)的位置。
先看最后一個字節(jié)：
這個字節(jié)是通過一個字符串指定偏移處的值得到，偏移值存在X8寄存器中。
逐步往前跟蹤X8寄存器值的來源，定位到：
也就是是W20^W21。
W20是之前處理的輸入字符串的最后一個字節(jié)。而W21來源于[SP,#0x50+var_44]。這個位置也是異或后結(jié)果保存的地方。所以猜測可能之前處理過程中也會不斷將輸入的字節(jié)逐一異或處理。
搜索了一下，果然有很多。
第一次用0xFF異或輸入字符串的第一個字節(jié)，將結(jié)果與第二個字節(jié)異或，以此類推。
然后之前那些特殊位置的字節(jié)不參與處理。獲取最終結(jié)果的低四位值。
同理發(fā)現(xiàn)倒數(shù)第二個字節(jié)的來源是將輸入的字節(jié)逐個相加。
獲取最后的和的低四位值。
至此，分析結(jié)束。
- End -看雪ID：Avacci
https://bbs.pediy.com/user-home-879855.htm
?*本文由看雪論壇 Avacci 原創(chuàng)，轉(zhuǎn)載請注明來自看雪社區(qū)。
?安卓應(yīng)用層抓包通殺腳本發(fā)布！
《高研班》2021年3月班正在火熱招生中！?
* 戳圖片了解詳情
#?往期推薦
一個緩沖區(qū)溢出復(fù)現(xiàn)筆記
Sandboxie循序漸進
【逆向解密】WannaRen加密文件的解密方法
使用unicorn來trace還原ollvm混淆的非標(biāo)準(zhǔn)算法
fart的理解和分析過程
球分享
球點贊
球在看
總結(jié)
以上是生活随笔為你收集整理的不混淆so文件_浅尝ollvm轻度混淆后的加密算法分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 最全的BAT Google等团队技术博
- 下一篇： linux系统rc路由配置_详解Cent