oacia大佬的APP加固dex解密流程分析，已经基本把它翻个底朝天了，但众所周知要彻底攻破该加固，仍有dex vmp这最后一道堡垒横在面前。在此之前拜读过爱吃菠菜大佬的某DEX_VMP安全分析与还原以及Thehepta大佬的vmp入门(一)：android dex vmp还原和安全性论述，了解到dex vmp的原理是对dalvik指令进行了加密和置换，这里参照大佬们的方法对oacia大佬的样本复现了一遍，记录一下历程。

既然是vmp，按照vmp常规的分析流程，必然要先拿到trace，以这次的经历来看，拿到trace就已经成功了一半了。参考了很多大佬的文章，大致有以下几种方法：ida trace、unidbg/AndroidNativeEmu、frida stalker、frida qbdi、Dobby Instrument、unicorn 虚拟CPU。

开始打算用maiyao的ida trace脚本，但遇到以下问题：
1.ida附加上后每次执行到linker加载壳so加载到一半就退出了，单步发现是跑到rtld_db_dlactivity里的BRK指令会直接退出，但加载其他so时并没有这个问题（why?)。这里手动把它跳过了。
2.trace了一下JNI_Onload，结果发现每当进入mutex_lock就会卡死在那无限循环……这个没能解决，只好弃用。

补java环境有点累，尤其是补到后面发现可能会有很多代理类，没坚持补下去……

从oacia那篇文章来的肯定少不了尝试一下stalker，结果发现和ida相似的问题——每当进入mutex_lock就会卡死在那无限循环。

尝试用yang的frida-qbdi-tracer，但每当trace到一些跳转的时候就会崩溃，查阅资料发现qbdi好像确实存在这样的bug。

这个我是后面才看到的，感觉将来可以尝试一下，详见KerryS的指令级工具Dobby源码阅读。

爱吃菠菜那篇文章的中的方法，没完全搞明白，感觉大意应该是把unicorn作为一个so文件注入到app中，用frida hook住目标函数，当发生调用时把环境补给unicorn来trace。

经过不断尝试，最终还是使用frida stalker，通过hook mutex_lock函数，在OnEnter中跳过stalker，再在OnLeave中恢复stalker的方法，在经过无数次崩溃之后，终于拿到了dex vmp的trace……

拿到trace指令流后，就可以着手分析了。可以看到，onCreate函数被注册到的地方，使用DebugSymbol.fromAddress没有打印出任何符号，应该是一块动态申请的内存区域：

函数并不大，里面也基本全是位置无关代码，应该只是一个跳板，很快，便来到了主elf中的函数sub_137978。

sub_137978这个函数就大了，该函数内的指令流数量占了全部的99%，然而在ida F5中却不那么好分析，因为它全程用跳转表实现：




ida倒是具备跳转表修复的功能，在Edit->other->specify switch idiom中，可以参考c48K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6o6K9r3W2F1j5f1&6#2K9$3g2Q4x3V1k6o6K9r3W2F1j5f1&6#2K9$3g2Q4x3X3g2Y4K9i4c8Z5N6h3u0Q4x3X3g2A6L8#2)9J5c8X3u0D9L8$3u0Q4x3V1k6E0j5h3W2F1i4K6u0r3x3U0l9J5x3g2)9J5c8U0l9^5i4K6u0r3f1%4m8W2j5$3W2X3P5g2)9J5k6s2y4%4K9i4c8U0K9q4)9J5k6s2y4@1j5i4c8W2L8h3g2F1N6q4)9J5k6r3W2F1i4K6u0V1d9f1c8m8i4K6u0V1f1s2u0G2i4K6u0r3K9h3&6V1k6i4S2Q4x3X3g2Z5N6r3#2D9 （原博文已挂，这里的备份需要下载下来看）
我按照它的讲解修复了一下，不过效果也不是太好，估计是没搞清start of switch idiom和input register。
也尝试过用数据流分析来回溯跳转表，然后转化为bcond addr1、b addr2来修复，不过因为可能会涉及指令重排的问题，而且有的块的前驱没有分析出来会导致数据流中断，懒得再用迭代了……这里直接从trace中找到这些BR X8的后继，然后在ida中用idc.add_cref(ea, next_ea, idc.fl_JF)添加上引用，姑且在汇编分析了。

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！