这是第一篇vmp系列，下一篇估计要很久很久以后。
https://bbs.kanxue.com/thread-270799.htm#msg_header_h1_6
看了一下，目前市面上关于dex vmp还原就我兄弟写的这一个，我不得不佩服他巨强的二级制分析能力。关于dex vmp 他的大部分都写了，但是，他搞的实在是太复杂了，他的分析基本都是基于静态的数据流向分析，这种对于二进制vmp都有杀伤力的，只能说杀鸡焉用牛刀，而且他的牛刀还没发借给我，这是最气的。
另外一个360大佬在看雪峰会上发的关于dex vmp的ppt演讲，他这个我没看得很懂，技术有限。前面都是大佬，一看就会，一学就废。

vmp目前基本可以说是逆向分析中代码混淆的巅峰，顶点，最高里程碑，dex vmp在我看来是比较简单一点的vmp了，所以我们从这里入门。

vmp是一种虚拟机保护壳，如果你第一次听过，估计直接蒙了，他其实就是一个虚拟的执行机器，就比如java虚拟机，他们的原理是一样的。java虚拟机可以叫vmp是保护的意思，所以叫vmp。这种虚拟机一般有两部分：

vmp虽然设计理念上跟别的虚拟机没什么差别，但是他很简陋，基本只有能转换虚拟机的bytecode然后进行运行的能力。写个伪代码示意一下

就是这样一直循环

在vmp执行实体中，可以看到有个bytecode_buff，虚拟机为什么能识别他，因为加固软件将源码，转变成虚拟机的bytecode，然后将虚拟机和bytecode一起打包到需要加固的软件中。

对于一个vmp,我们的目标只有一个，那就是还原，还原成c也好，汇编也好，java也好，反正就是去除vmp化。这就是最务实的目标，所以这篇博客的目的就是如何将dex vmp 还原成java代码。

首先看入口函数，如果看过我上面提到过的dex vmp 你就该知道，这个pro.getxxx，其实就是调用的dex vmp函数的入口，而第一个参数，其实就是代表了当前这个函数，用这个数字来索引已经被虚拟化的代码来执行。

然后再看看这个函数的定义，这个如果你经验丰富，经常写java代码和别的代码的交互，你就会发现，这是一个java 和c的交互代码，写了这么多类型，就是可以从c 层返回任何一种类型的java对象，看不出来也没事。

这个本来不想写的，但是其实其实比较简单，有人多人去hook NativeRegister，很多加固去通过各种奇葩的手段绕过NativeRegister进行注册，但是其实没必要，java方法的native地址根本无法隐藏。分享一个frida脚本寻找native方法的地址。

这个函数是我们主要的分析，怎么寻找native函数，so动态下发分析不讲了，直接找native函数地址开始分析流程

拿到这个包以后，已经找到要逆向的函数，所以直接用上面的frida 脚本找到函数的偏移，然后ida直接附加进程，在这个位置下断点，确实没问题，函数在这里断下来了，trace了一下，程序直接崩溃了，有反调试，无所谓，停掉所有其他的线程trace，这个getobjresult函数有时候能跑完，有时候跑不完。但是trace确实完成了，第一次trace 90w，第二次2700w行。trace代码的长度，流程都不一样。经过代码一段时间的汇编分析（比较简单），我发现出问题代码这个地方开始不一致。

为什么要贴这段汇编那，其实不贴也可以。因为假如你有一天去你想vmp,并且发现这种br x8,这种，不断取x23内容，加上x22地址，是dex vmp，我调研过有几个类似样本都这样。
然后就进入完全看不懂的乱序执行

有很多图，全部都是乱的。开始我以为是混淆，经过分析以后发现，并没有混淆。但是这个执行顺序完全是乱飞，我们一般对于1个函数，或者说c编译的函数，识别的他的方法是开栈和闭栈并且栈平衡，这是一个完整的函数，但是这个函数全是乱的，没有开栈也没有闭栈。

对于一个未知的加固方案，如果你想从汇编完全暴力破解他，把他撸出来，而且还是2700w行汇编，难度太高了。所以第一个是识别他，然后去网上找大神的破解方法来对症下药。如何识别那，不断的运行，进行猜测，这个过程会很久，经过分析我发现他里面有大量的jni函数

很多很多，在运行中分析这些数据发现他调用很多java的代码，各种各样，有很多我甚至都没有用过。

到这里基本破案了，256条指令对应了256个Dalvik 指令的opcode,虽然很多没用。

前面我们说了我们的目标，就是将某一段代码还原。而vmp，还原的方法只能去分析整个vmp的框架,进行功能含义分析，然后通过某一段vm的指令，将他手工转化成java代码。说白了就是一个vmp的反向过程。

我签名写的这个，就是vmp简单的执行示意，它必然需要不断的循环运行，来执行基本单元指令，除非基本单元指令退出，否则会无线循环。
但是实际分析过程中，我发现没有while循环，也没有这种wile里读指令，然后根据不同的指令跳转到不同的vmp基本单元指令。（猜测失败的代价就是对自己的技术产生怀疑）
然后我去研究了一下trace，看一下他这个指令之间是如何关联起来的，上一条指令如何跳转到下一条指令。（研究过多条指令，很长的函数还没有间隔，完全不知道出口在哪里，但是很幸运的是有比较短的）

不多贴了，他们的尾部都是一样的，x20 当前指令，x22 data_rel，x23 指令数据表。他是通过上一条指令的内容计算下一条指令的地址，然后读取数据数据，和指令处理的地址，用x8跳过去，他不是一个while模式。写个运行的伪代码的例子

这样一旦开始执行，除非遇到退出指令，否则函数会一直执行下去。android dvm虚拟机以前读源码的时候见过这种模式，这种计算指令长度的方式，davlik也确实可以这样搞。他每个指令长度都是可以提前写死的，没有变长的可能。

我们知道了他的基本单元指令，以及基本单元指令的函数，这个时候我们对基本单元指令进行一个一个的分析，然后将某一个vmp化的java函数vmp指令进行反向转化。

以前听说360还原用的是对照表。但是逆向到我这个地步，写对照表已经属于浪费时间了，而且对照表还要对着opcode一个一个的改，懒得搞了。我直接写了一个小型的opcode 转smali语言的ida脚本，将vmp指令转变为smali指令，然后写道对应的dex中反编译的smali工程中，进行回编译。直接贴脚本，这是一个的半自动化+手工来进行指令还原的脚本，扔给你们做参考吧。

效果图，我就不贴
大致讲一下这个脚本原理思路和使用

这个脚本需要在vmp已经装载完成以后调用，找到还原的dex和对应的vmp指令地址，可以直接循环翻译成smali指令。具体的指令是有具体的长度写在代码里的。smali函数结束都有smali指令的返回指令（return类指令），可以随便找个smali工程看一下，函数结束都有一个return类指令.也有可能是其中的一个返回，通过跳转指令结合分析

dex vmp 虽然跟二进制vmp的原理一样，但是他的逆向难度和vmp却不是一个量级的。为什么会出现这种情况

这个已知保护措施是dex vmp在可被逆向的情况下，如果提高一些安全性

分析vmp指令，对他进行还原的时候，并没有非常具体的写。在这里一切写，这是一些写davlik指令，或者说反编译分析davlik的一些经验。
davlik指令是非常容易分析的，基本不太存在保护的价值，因为一般的防护扛不住静态分析工具的分析，这个他的设计是有很大关系的。

dalvik中的部分指令有很强的关联性。比如

前面这个invoke-static ,如果有返回值，必会跟这后面这条指令，甚至可以说他们是一条指令

变量在定义之后，有大概率在下一条就会使用，当然不是绝对

这是new一个对象的代码，会立即调用init方法

函数结束必有return指令，当然遇到return不一定是结束。但是进行人工还原的时候通过上下文分析函数结束位置，还是非常有价值的。

有很多操作相同，但是操作类型却不同的指令

这一条aget指令，针对于各种不同的类型有不同的指令。在指令中有个对应的索引，我们甚至可以直接查看这个类型来反向推理这个指令操作的是什么类型。这种设计也从侧面给说明了，dalvik一个指令只有一个解释，没有歧义性，不想汇编，c，不知道类型，更不知道操作具体是什么，只是数据进行了操作。即使是一些虚函数，java中你可能分不出来他具体调用的是那个类的，但是在dalvik中，这个类的类型已经写死在索引中了。

虽然dalvik号称256个opcode，但是有很多不用的，还有一些是同一个功能，但是不同类型

这是smali解析的dalvik指令，就上面这些功能，不算多。

dalvik的指令如果想要运行，必须在一个method里，不可能超出一个函数的范围，更不可能先汇编语言那样全局的大跳，动态跳转地址，每一个函数都是一个密封的黑盒，当然可能会有一些类变量什么的，但是就代码含义分析这一块基本没问题。

一般在这个位置都是要吹牛逼的，但是我发现牛逼可能成真，就留个悬念。

如果真的觉得可以就关注一下公众号吧。也不发图推广了。
哦，对了，我这脚本配合人工半自动换，是可以做到一个函数一个函数还原的，我经过测试了，图，就不贴，怕人找，虽然目前没人找过。
我随便找的其中的某个样本，发的照片，很多样本好像都差不多，都是这个逆向思路