360加固之libjiagu.so脱壳及dex dump

       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)