【安卓逆向】360加固-脱壳修复

最近花了一些时间学习逆向脱壳，这方面一直投入的时间比较少。样本经过某加固宝进行加固，这里简单记录一下脱壳过程和思路，感谢某数字公司对安全加固的无私贡献，让我有机会小小的提高一下这方面的技能。

*安卓逆向交流学习qq：3251901516
vx:13140310004
DUMP classes.dex

打开APK包中的classes.dex看一下：

已经变成了壳代{过}{滤}理，没有一点原APK的代码。在assets中，有两个壳相关的SO：

尝试从内存中DUMP原classes.dex。

考虑到在Dalvik下，360可能会自己实现从内存中加载classes.dex的代码，不容易找到DUMP的点。而ART下，可操作空间就小多了，所以我是在ART下操作的。

具体的，我是在ClassLinker::DefineClass函数处得到dex_file的begin和size，然后DUMP出原来的classes.dex。我看到有人在dex2oat的地方DUMP，但我觉得如果360 HOOK execv，阻止dex2oat对原classes.dex作oat转换的话，会不会就脱不出来了呢？不过我对Android虚拟机不太了解，可能有更好的DUMP点。

成功DUMP出原classes.dex：

但是可以看到，有些方法（图中onCreate）的指令被抽走了，并且改为了native方法。同时，在static代码块中，有一行调用StubApp.interface11(16)。

可以猜测：当该class被加载时，static代码块会首先被执行，这样StubApp.interface11方法就会将onCreate注册到壳SO的某个native方法上。这样，当执行onCreate时，就会执行相应的native方法，该native方法会首先找到onCreate对应的指令，然后解密，最终解释执行。

interface11以及onCreate对应的native方法，以及解释器并没有实现在上图中的libjiagu.so中，而是实现在另一个运行时从内存中加载的SO中（暂且称其为解释器SO）。

DUMP解释器SO

APK运行后，会首先加载libjiagu.so，并执行其JNI_Onload方法。该方法最终会调用到__fun_a_18，这个方法进行了控制流混淆，流程对于我来说是非常复杂的。

刚开始，我以为它用了o-llvm进行混淆编译。但仔细看一下汇编代码，应该不是。应该就是自己在源码中利用while-switch实现了“控制流平坦化”的混淆算法。

怎么破？我没有什么好办法，只有硬看，不断的调试，参考大神们的帖子。

由于我手机是自己编译的系统，对于某些反调试天然免疫，所以遇到的反调并不多。下面简述我是怎么过反调并DUMP出解释器SO的