僅限技術討論，不得用於非法途徑，後果自負。
分析中有什麼錯誤歡迎大家指出
Java層分析
快分析完才想起打算用art模式分析的，那就分析下一個殼用art模式分析把
這個是dalvik模式，nexus5 4.4.4
邏輯比較簡單，主要是加載libSecShell.so，和替換原APP的Application,Helper.h的native方法是對華為手機一些設置，手裡沒有華為手機具體native沒有分析
java層有一個DexInstall類，Native層會通過jni方法調用install(ClassLoader loader, String dex_path, String dexDir)方法
一直往下分析，此方法主要作用就是把Native層解密的dex通過反射調用makeDexElements方法把生成的Element數組加入到dexElements數組中
具體過程可以參考android源碼
https://www.androidos.net.cn/android/4.4.4_r1/xref/libcore/dalvik/src/main/java/dalvik/system/BaseDexClassLoader.java
https://www.androidos.net.cn/android/4.4.4_r1/xref/libcore/dalvik/src/main/java/dalvik/system/DexPathList.java
Native方法分析
通過查看.init_array和.finit_array段沒有做具體內容，解密方法應該放在了JNI_OnLoad中，一看就是經過llvm混淆過，正常代碼怎麼會有這種邏輯
f5看一眼，能正常反編譯，大體掃一眼邏輯還是可以接受的沒那麼變態，發現字符串都被加密了，部分方法也被加密了
只能動態分析了，具體就不帖代碼了，最後我會把分析的so文件分享給大家
JNI_OnLoad 4.4.4 dalvik 流程，這裡的反調試並不影響我們分析這個，反調試具體代碼我沒有分析，感興趣的可以分析一遍
Jar解密方法，有興趣的可以還原下，那樣直接把apk的jar解密直接解壓就是原apk的dex文件
脫殼dump
殼只是把原dex加密放到了secData0.jar中，所以直接拿到dex，修復AndroidManifest的application重打包完美運行
dump方法比較多，列舉幾個方法
1.通過還原加密算法，解密secData0.jar，直接解壓解密jar就是原dex（不推薦這種方法，雖然方便，但算法更新太快）
2.殼保存在.cache的classes.dex是加密的，主要通過hook實現，打開時解密，關閉時候加密。
殼hook了open和mmap方法，這裡下斷得到的dex是解密的dex即原dex（調用open，mmap方法可能不只是打開dex，通過文件大小可以篩選出來）
3.在解密jar函數下斷點，執行完得到解密jar，dump出解密jar，解壓出dex
4.殼hook了dvmRawDexFileOpen，在這裡下斷點，得到的dex是解密的dex即原dex（比較推薦這種）
提醒
1. idb用的ida7.0保存的
2. 給switch下斷點注意，一級下的switch，如果沒執行到一級的switch直接下斷點可能會失敗（不知道是ida問題還是？）
總結
別被JNI_OnLoad的流程給唬住，靜下心來分析還是挺簡單的。
感覺這種內存加載dex安全性還是挺低的，只要分析出關鍵代碼dump出原dex那就是分分鐘的事，連修復都不用。
原文鏈接：[原創]【脫殼二】某最新免費殼分析+脫殼-『Android安全』-看雪安全論壇
閱讀更多 看雪學院 的文章
