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動態除錯分析。

  下面是經過修復後的

360在dex載入的時候，並沒有呼叫dvmDexFileOpenPartial，而是自實現了此函式的功能，因此直接在這個函式上下斷點是不能脫殼的。它的實現方式基本是照抄了原始碼

如上面原始碼所示，使用dex所在記憶體的時候都會使用memcmp校驗MAGIC是否為dex,所以只要hook memcmp，然後在過濾函式裡校驗是否為dex，然後dump出來即是原始的dex

  (建立了一個Android逆向分析群，歡迎有興趣的同學加入，群號碼:376745720)