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)