360加固後的apk，在arm設備上首先會將assets目錄下的libjiagu.so拷貝到files目錄下,然後通過libjiagu.so動態加載原始dex
libjiagu.so的init_proc和init_array都無實質功能，真正的解密放在JNI_OnLoad裏面
JNI_OnLoad函數裏有非常多的垃圾跳轉指令干擾分析，後面還會有動態解密的函數運行，如果檢測到調試器，會把動態函數置成非法代碼，使程序CRASH
51b0c404這個位置就會跑飛。這樣分析比較累人。換個思路，對一些關鍵函數進行hook,進行hook log分析
Hook dlopen和dlsym LOG打印出libjiagu.so的加載基址和大小
可以看到JNI_OnLoad的地址還是在libjiasu.so內存範圍內的
Hook RegisterNatives函數，打印如下LOG
這個LOG可以看到RegisterNatives有被調用，註冊了一個interface7函數,函數地址是51e2f211,仔細看這個地址發現，這個地址已經是thumb指令集了，跟libjiagu.so使用的arm指令集不太相符，而且可以看到函數地址已經超出了libjiagu.so內存範圍了.
libjiagu.so的基址是51b3b000,大小是46000,最大內存地址是51B81000
那麼，基本可以確定，它在內存中加載了另一個so
從/proc/%pid%/maps裏找到函數地址所在的內存塊，把周圍連續的內存一起dump出來
在這片內存裏找到如下一塊內存
這其實就是elf heaer了，不過一些elf結構信息已經被抹掉了。除了基本的結構信息還缺失
如下三個數據：
0x20 e_shoff
0x30 e_shnum
0x32 e_shtrndx
接下來的工作就是對這個殘缺的內存進行修復了，通過分析上面三個數據，dlopen其實都沒有用到，其值對elf運行沒有影響。
經過修復後的文件可以替換掉原來的libjiagu.so，重新簽名後使apk正常運行，用於IDA動態調試分析。
下面是經過修復後的libjiagu.so用ida分析的流程圖片段
360在dex加載的時候，並沒有調用dvmDexFileOpenPartial，而是自實現了此函數的功能，因此直接在這個函數上下斷點是不能脫殼的。它的實現方式基本是照抄了dalvik源碼
如上面源碼所示，使用dex所在內存的時候都會使用memcmp校驗MAGIC是否爲dex,所以只要hook
memcmp，然後在過濾函數裏校驗是否爲dex，然後dump出來即是原始的dex
(創建了一個Android逆向分析羣，歡迎有興趣的同學加入，羣號碼:376745720)