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