Android安全交流群：478084054
0x00序
最近花了一些时间学习逆向脱壳，这方面一直投入的时间比较少。样本经过某加固宝进行加固，这里简单记录一下脱壳过程和思路，感谢某数字公司对安全加固的无私贡献，让我有机会小小的提高一下这方面的技能。
0x01 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）。
0x02 DUMP解释器SO
APK运行后，会首先加载libjiagu.so，并执行其JNI_Onload方法。该方法最终会调用到__fun_a_18，这个方法进行了控制流混淆，流程对于我来说是非常复杂的。
刚开始，我以为它用了o-llvm进行混淆编译。但仔细看一下汇编代码，应该不是。应该就是自己在源码中利用while-switch实现了“控制流平坦化”的混淆算法。
怎么破？我没有什么好办法，只有硬看，不断的调试，参考大神们的帖子。
由于我手机是自己编译的系统，对于某些反调试天然免疫，所以遇到的反调并不多。下面简述我是怎么过反调并DUMP出解释器SO的，因为这个混淆算法应该每个版本都有所变化，所以这个流程并不一定适用别的样本。
第一处反调，来自case 37：
继续执行：
来到这个位置，看到R3保存的是rtld_db_dlactivity符号的地址，我担心它是要作SIGTRAP信号反调，所以手动将R3的值修改为0。
继续执行。当第4次进入case 32时：
继续执行，来到下面的位置：
注意此时R1的值，要将600B0010修改为200B0010，否则会执行R4地址处的代码。
R4地址处的代码是什么？看一下：
就是终止进程的代码。
过了此处反调之后，继续执行，来到case 31：
继续，来到如下位置，这里就是加载解释器SO的函数了。
注意，这里不是通过调用dlopen函数来加载解释器SO的，而是自己实现的类似于linker的加载代码。
其实linker的工作原理并不复杂，简单来说就是将目标SO文件的LOAD段映射内存，解析文件格式，做好符号重定位，再调用init/init_array方法等等。
继续执行，来到解密ELF Header的地方：
解密完毕：
根据R3的值，将ELF Header先DUMP出来。
继续执行，来到解密Program Header的地方：
解密完毕：
将Program Header也DUMP出来：
继续执行，来到如下位置：
这个方法是要将解释器SO的LOAD段映射到内存，然后完成整个加载过程。
根据so_addr和so_size将整个SO DUMP出来，但这里DUMP出来的SO是没有ELF Header和Program Header的，但这两个头前面已经DUMP出来了。最后三者拼在一起，就是完整的解释器SO了。
0x03还原onCreate
有了解释器SO，就可以继续分析了，核心的内容都在这个SO里面。
由于我编译的系统，加了很多日志，所以在执行到前面的onCreate方法时，看到如下日志：
就像前面猜测的那样，当执行该onCreate方法时，先执行class的static代码块，调用interface11方法，该方法将onCreate注册到了一个地址为0x75c74e2d的native方法上。该native方法就实现在解释器SO中。用0x75c74e2d减去load_base，可知是解释器SO中的sub_10E2C方法。
跟踪并分析该方法。
继续动态调试，在解释器SO中偏移0xFAAE处下断点：
观察此时R1寄存器的值为0xBE027450，跳到该处内存，并得到0xBE027458处的值为0x75EA5418。
跳到0x75EA5418内存处。
观察0x75EA5418内存处的值，得到本次解释执行的方法是：com.xxx.xxxActivity->onCreate。
继续，在解释器SO中偏移0x35C80处下断点：
观察此时R7寄存器的值为0x75E96A10，在Hex View中，跳到0x75E96A10内存处：
观察此时0x75E96A18地址处存储的值为0x7699C61C，在Hex View中跳到0x7699C61C内存处：
在0x7699C61C内存处存储的就是DexCode结构，DexCode的结构定义如下：
由此可知“com.xxx.xxxActivity->onCreate”方法的insns指令数组大小是0x93*2=294个字节，指令数据流是：
这个指令数据流是经过加密的，解密key存储在0x75E96A2C地址处，值为0x3B。
继续调试的话，就是执行switch型的解释器了。这个解释器和Dalvik解释器类似。在android 2.x版本中曾有2种形式的C实现的解释器，一种goto的，一种switch的。后来谷歌把switch型解释器去掉了，因为执行效率没有goto的好。再后来就有了ART，貌似把C语言实现的解释器都去掉了。再再后来到了7.0，goto和switch型的C解释器又都回来了。
简单来说，就是解释执行整个onCreate方法的指令数据流，每条指令在执行前会解密。那怎么将这些指令还原回原本的dalvik字节码指令，达到脱壳目的呢？可以根据每个case的实现，来得到当前执行的opcode对应dalvik字节码指令中的哪一条，然后对应还原。
比如，这里的0xAE，在解释执行时，跳转到case 174处执行。假设拿case 174处的代码对比分析Dalvik解释器，发现case 174执行的是invoke-static指令，那么这条指令就还原出来了。
这样有点麻烦。
有一个好点的办法就是：自己在onCreate方法中将所有的dalvik指令，一共200多条全部写出来。然后用360加固，动态调试，总结出每条dalvik指令对应的360解释器的case处理指令的偏移，最后得到一张指令映射表。这样，后续在脱壳的时候，就可以根据解释执行代码的偏移，还原出原来的指令。当然，360解释器也是在不断变化的，所以，这个表也是要跟着变化的。
那能写自动脱壳机吗？只要这张指令映射表是有效的，脱壳就可以自动化完成。
那如果指令映射表失效了，能通过代码自动生成新的指令映射表吗？仔细分析解释器，每个指令的处理逻辑没大变化的，也许可以。
扯远了，下图是某个onCreate方法还原前后：
0x04后序
由于时间和水平都有限，很多地方还没仔细分析，本篇笔记只是简单记录一下本次操作的大致过程和一些思路。
最后，感谢论坛中各大神的分享，让我学习到了很多东西。
End