【原創】簡單嘗試脫“愛加密”官網加固的DEX殼

雙刃劍客發表於2017-01-03
加密

轉：http://bbs.pediy.com/showthread.php?p=1459603#post1459603

 

0x00 序
第一次嘗試脫dex殼，樣本是在“愛加密”官網上免費加固的，非商業版。

 

本文只是做些簡單的筆記，給像我一樣的逆向新手們提供點思路，高手們不要見笑。

0x01 加固包和原包對比

 

加固後的classes.dex檔案變大了，脫到JEB裡面發現多了一些殼程式碼和一些垃圾類（jpvbhn、cioub、flsye…）。

原包中，很多類方法的指令被抽空了，如下面的onCreate。

將assets目錄下的libexec.so脫到IDA中，發現個別方法被加密，並且用了o-llvm進行混淆編譯。匯出表中的那些x、y開頭的變數就是o-llvm在編譯過程中，新增混淆控制流（-bcf）時建立的。

ptrace注入，從記憶體中dump出來一個libexec.so，看一下字串表：

在字串表中看到一些關鍵詞（dvmResolveClass.c、HOOK:%s() write dex!），
瞎猜愛加密可能是抽取dex中的方法指令，然後hook dalvik/art 關鍵函式，在
執行時載入該類時再解密指令。所以用DexHunter試一下。
https://github.com/zyq8709/DexHunter
ps：從字串表也可以看到，愛加密為了“防模擬器”，
判斷了好多系統屬性（ro.product.model、ro.product.device…）。

0x02：利用DexHunter還原dex
DexHunter的大致原理是在某dex的第一個類被載入時，遍歷該dex檔案的所有的class_def_item，
主動載入所有的class（呼叫dvmDefineClass），並初始化（呼叫dvmIsClassInitialized和dvmInitClass），
讓殼自己完成方法指令的解密，然後再做必要修復並dump。
編譯帶DexHunter的dalvik，刷機之後試了一下，在脫殼過程中apk程式死了。

愛加密有點意思，應該是在libexec.so或libexecmain.so被載入之後，
在native程式碼中判斷了“/data/”目錄下是否存在dexname檔案
（這也算DexHunter的一個特徵），如果有則自退。
修改DexHunter原始碼，把dexname這個檔名改掉：

再試一次，還是掛了，這次貌似是呼叫com.cioub類的clinit方法導致的。

看一下com.cioub類的clinit方法的實現就明白了，上面提到的那些垃圾類（jpvbhn、cioub、flsye…），
都是愛加密為了“防DexHunter”新增的。

先用笨方法解決一下，通過一個名單檔案，將這些“防DexHunter”類pass掉。

再試一次，脫出了whole.dex，這實際是一個odex檔案，利用baksmali和smali將其轉換為dex檔案，
拖到JEB中看一下：

之前被抽空的onCreate方法成功還原了，去掉那些垃圾類和shell程式碼應該就差不多了。

0x03 後序
1、使用DexHunter脫完之後，如果還有方法沒有還原，那加固廠商可能做了函式級加解密，
在方法呼叫時再解密方法指令。
2、定位native方法指令在記憶體中的位置

這3個native方法是愛加密加固之後的3個核心方法，但libexec.so的JNI_Onload貌似加密了，
並且匯出函式的名字也混淆了（採用RegisterNative動態註冊），找出對應的native函式有點費勁。
可以在dvmCallJNIMethod函式中加點log，其實這個函式中本來有log，只不過注掉了。放開的時候，
要進行一下過濾，否則打出的日誌太多會淹沒其它有用的資訊。


3、愛加密應該已經有直譯器殼了，猜測愛加密商業版以後可能會是“類抽取＋直譯器殼”的形式，
因為所有指令都解釋執行的話，應該會對效率影響較大，所以二者結合是個不錯的選擇。 


相關文章