二、过反调试
jnionload主要是一些反调试，壳反调试变化不大，网上已经给出反调试。在汇编代码的blx lr这些地方下断点，然后去分析。
1.首先是检测rtld\_db\_dlactivity是否为0，主要就是映射linker.so然后遍历符号表找到rtld\_db\_dlactivity然后判断。这儿被下断点时值为0x10de\(小头\)，改成0xc046\(小头\)就可以了。
2. 然后是tracepid的检测，在strtol处下断点，修改返回值为0
3. 然后是时间差检测。每次修改太麻烦，我是hook了time函数，返回值修改为一个固定值。之前还想，会不会猥琐的专门加个一秒半秒的延迟，这样修改成同一个时间也会过不了反调试。还是想多了。
4. 端口检测，用ida跟踪时，就不要用23946端口了
三、第二个so分析
过反调试之后会释放第二个so，第二个so是被处理过的，会进行手动加载，主要就是将linker装载和解析so的过程自己实现。Ida动态调试时直接analyze area释放出来的so也可以识别里面的函数
因为听说壳把oncreat方法变成了native方法，所以提前hook了dvmUseJNIBridge函数，然后获取了oncreat的加载地址
看so发现是一个自己实现的解释器，将加密了的代码解密，操作数不变，然后将操作码按照一张映射表去执行相应指令。感觉就是自己实现了一遍dalvik解释器。
四．脱壳修复
用drizzledump脱的dex。修复oncreate就用上面的原理。听说映射表经常变，还要去写一个基本带所有指令的app加固然后生成映射表。就没继续搞。
五．分析时碰到的一些小问题
1.动态加载so时，ida不知道怎么不会在加载so时停下来。我就直接在dvmUseJNIBridge处下断点。
2.还有有时刚加载完so还没执行init就ida崩溃了。跟踪了半天就发现在rtld\_db\_dlactivity处崩溃，因为rtld\_db\_dlactivity是个空函数，所以直接在跳转到rtld\_db\_dlactivity之前就把这个函数跳转就注释掉就可以了。暂时还没搞懂原因。
3.hook so框架用的libadbi。
总结
感觉壳就是把很多系统实现的功能自己给实现了。Linker装载解析so，dalvik解释器