標籤:android 脫殼 zjdroid
用ZJDroid給某愛加密加殼的apk脫殼的經過。
本菜鳥雖然編碼的經驗還是有的,但是破解可以說是第一次。這次在用ZJDroid給某個APK脫殼碰到了一些問題,所以記錄下來,如果能給碰到同樣問題的童靴提個醒,就很高興了。所以 高手請繞道,別笑話菜鳥啊 :)
背景
這個APK包名為com.xxx.client包含了一個so檔案,叫libxxx.so
整個包用愛加密加了殼。 典型特徵就是apk的assert目錄下有ijiami.dat檔案
原理
一句話來說的話,就是用ZJdroid的"backsmali"的命令直接dump出來已經脫過殼的dex的內容。Android 安全強化行業分析和破解這個文章對愛加密有個很關鍵的一句話分析
在C層對Dex進行解密並載入,替換記憶體中的Dex 為原Dex,替換自訂的Application的運行環境 為原Application
因此,最簡單的方法就是等愛加密把Dex的內容替換完了,再直接dump出來就可以了。
原理貌似很簡單,可是我這種菜鳥還是花了兩個星期啊,:(
環境準備
已經root的手機一個我開始是想在模擬器上測試的,但是後面碰到root問題,和分區載入順序問題等,太麻煩了,耽誤時間。所以還是搞個真機吧。
我的是小米1s,這裡要注意了,雖然Xposed針對MIUI做了特殊處理,但是在我這個小米1s上還是出了問題,載入資源異常,
所以我給我的小米1s刷了小米提供的原生android版本.參見線刷MIUI及原生4.1教程
安裝Xposed和ZJdroid一切順利,就不特別說明了,記得要激化組件哦。
可以用 adb logcat "Xposed:V *:S"查看Xposed的log,確認一切正常
使用ZJDroid開始破殼這個可以參見Android動態逆向分析工具ZjDroid--脫殼神器
我開始先用“dumpdex” 命令 dump ,結果得到的dex還是愛加密加固後的stub的dex。
但是用"dumpclass" 可以發現dump出來的類是我感興趣的類。那應該記憶體裡確實有已經脫過殼的dex資訊了。
後面看到了”fanqiliang“在看雪的“Android 安全強化行業分析和破解”文章裡對愛加密的分析,就更堅定了我的猜測:
"愛加密是把樁dex載入到記憶體後,在第一次load真正的class時候,把記憶體裡樁dex的內容替換成脫殼後的clas內容"
所以直接dump_dex不行,那就用”backsmali“命令直接反編譯dex的class資料吧。
這個過程中碰到了兩個問題,記錄如下:
坑和規避方法
dvm heap size不夠導致dvm-heap-alloc xxx object failed .
由於我的這個apk有快2000多個類,比較大,
所以"backsmali" 在反組譯碼成smali檔案時,一切順利,但是再把smali檔案組成dex時,由雩都是在記憶體裡完成,估計需要記憶體比較大,因此後面在分配記憶體時失敗了。
解決方案:加大vm hap的記憶體,修改/system/build.prop中的dalvik.vm.heapsize=512m//之前的256m改成512m
重啟,就沒有分配記憶體的錯誤了。
報java.lang.File.finalaze() timeout.
這個問題看起來很奇怪,但是猜測到小檔案這麼多,有可能是檔案控制代碼沒有及時釋放導致的。
所以,修改ZJdroid的src/com/android/reverse/smali/DexFileBuilder.java檔案,及時的關閉開啟的控制代碼 ,編譯,重裝就OK了。
到此終於看到了dexfile.dex了。
現在就要把xxx重新打包,看我們脫殼後的dex是否正常
1. apktools2 d -s xxx.apk, 輸出目錄為xxx
2. 把dexfile.dex替換xxx裡的classes.dex
3. 把xxx/assert裡的ijiami.dat刪除
4. 把xxx/lib/armeabi裡的libexec.so libexecmain.so刪除
5. 修改xxx/AndroidManifest.xml 把application裡的android:name替換回來為"com.xxx.client.MyApplication"。
6. apktools2 b xxx
7. autosing 簽名新產生的apk
安裝,運行,一切正常。
總結
- ZJDroid不愧為脫殼神器啊
- 自己還要多補充系統知識啊。爭取能夠全面理解加殼脫殼的原理 :)
ZJDroid脫 愛加密 的殼的經過