Android相比iOS，安全问题往往比较突出，各种漏洞和破解层出不穷。对破解方法的了解，能在开发中进行预防，加强应用的安全性。本系列文章会对Android应用的破解和保护两方面做个探讨，给开发的同学一些借鉴。Andoid开发的同学可能会遇到需要做竞品分析的情况，APK加固常常会成为分析的障碍。360渠道做为Android应用分发的最大渠道，很多apk都使用了360加固。本文就来聊聊如何过掉这个坑。360加固后的apk，在arm设备上首先会将assets目录下的libjiagu.so拷贝到files目录下,然后通过libjiagu.so动态解密并加载原始dex
要对apk脱壳，首先要分析libjiagu.so实现。而该so做了二进制加壳。那么现在首先要做的事就是先把so的壳给脱了。通过010Editor查看libjiagu.so结构可知，其init_proc和init_array都无实质功能，真正的解密放在JNI_OnLoad里面。
JNI_OnLoad函数里有非常多的垃圾跳转指令干扰分析，后面还会有动态解密的函数运行，如果检测到调试器，会把动态函数置成非法代码，使程序CRASH
1b0c404这个位置就会跑飞。这样分析比较累人。换个思路，对一些关键函数进行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_shoff0x30 e_shnum0x32 e_shtrndx接下来的工作就是对这个残缺的内存进行修复了，通过分析上面三个数据，dlopen其实都没有用到，其值对elf运行没有影响。经过修复后的文件可以替换掉原来的libjiagu.so，重新签名后使apk正常运行，用于IDA动态调试分析。下面是经过修复后的libjiagu.so用ida分析的流程图片段
360在dex加载的时候，并没有调用dvmDexFileOpenPartial，而是自实现了此函数的功能，因此直接在这个函数上下断点是不能脱壳的。它的实现方式基本是照抄了bionic源码
如上面源码所示，使用dex所在内存的时候都会使用memcmp校验MAGIC是否为dex,所以只要hook memcmp，然后在过滤函数里校验是否为dex，然后dump出来即是原始的dex。把hook框架搭好，实现如下的memcmp过滤函数，就可自动将原始dex dump下来。
前面的都搞定后，整个脱壳过程就可以自动化了。APK启动瞬间即会自动脱壳。点击启动APK，会输出如下LOG
LOG里的第3个dmp即为原始dex，已经自动写入到指定目录。
该脱壳器可应用于目前所有360加固，只需指定APK包名即可在启动时秒脱