我已参透了符文！。虽迟但到，现在是12月1号，星期日的晚上。本来在中午的时候，就已经破解最后一关。但是下午刚好有钢琴课，只做完DFA的一组，就匆匆下线去上课。最终，上课回来之后也是马不停蹄的接着前面的思路继续做，完成了整个‘破解’过程。这也是我第一次完整分析复杂VM的题目，特此写下此篇，来做个总结。

首先这道题是一个栈虚拟机+JIT，在栈虚拟机中完成白盒AES加密过程。所以做出这道题需要：

总之，要工程量有工程量，要难度有工程量

一个exe程序 接收一个参数（flag）

flag正确输出:)

flag错误输出:(

首先在sub_14009A760中，发现了一个巨大的swicth case，在sub_14009A760调用的前有寄存器保存，后有寄存器恢复，显然sub_14009A760就是vm_dispatcher,在switch中的case就是不同的handler了。

bytecode就相当于VM中的二进制代码一样，而handler就是bytecode的解释器，可以理解为vcpu

下面拿case 0来剖析bytecode的格式

可以看到大switch中还有个小switch，细看小switch中每个case的逻辑都相同只不过操作数的大小不同，其中push_16的代码为：

可以看出来是内存模拟push的操作，最后写入内存的是2字节的数据，所以是push_16其他以此类推。

你可能疑问，为什么没有push8，这里我的理解为：本来x84_64架构中，只有16位/32位/64位，即使在16位下，push 1，实际上也是压入2个字节，即压栈时会根据CPU模式扩展到对应位数

调试查看case 0 + case 3 bytecode的内容为：

op opsize [operand]

在这个例子中 就存在operand 为 20 00 00 00 00 00 00 00，长度为8 byte，与opsize=08对应

存在operand2的例子会在后面讲到，这里先埋个坑。

根据前面的分析。总之，这就是一个push imm的指令，注意这是在栈虚拟机的实现，在虚拟机中有大量的push，pop，这些数push进去后面又pop出来拿来用，翻译x64等效指令就是：

为什么等效？mov reg, imm 其实就是占用一个reg存放imm（reg_index+1），对应于栈虚拟机的栈空间。相应的pop时候，释放栈空间，翻译时reg_index需要减1。（reg_index的动态加减其实就像模拟了rsp的移动）

可以看出时load8/16/32/64的操作，对应的操作可以简化为push(*pop())，所以对应的x64指令为：

case 3，5，6都为store操作，只有细微的差别，这里拿case 5来分析。

操作可以简化为*push() = pop(),翻译为x64指令：

case 7,8,0xb,0xd,0xe,0xf 分别对应add，sub，div，mul，and，or，逻辑类似

这里拿case 7分析，可以看到除了push(pop() + pop())的操作外，还有一系列其他的操作，其实这里是在设置eflags， *(_QWORD *)(a1 + 0x210)存储了虚拟机的eflags。翻译为：

sub，div，mul，and，or 以此类推

乍一看和sub没什么区别，其实不如在case0x12中，v105 = v104 - v103后，并没有push(v105),但是保存了改变的标志位，符合cmp的特征，翻译为：

case 0x15: jmp

可以看到这里会判断不同标志位，进行不同的跳转，这里分析下jmp 的bytecode格式

所以在ture_jmp:中，就是在计算当前的bytecode 的pc与offset的运算，即newpc = pc-offset

在false_jmp:中，直接就是更新pc到下一个bytecode的位置，相当于fall through。

case 0x1b: JIT

到这里会发现代码特别长，有很多陌生函数call，点进去还有一堆call，人工分析难度太大了。这里我是猜出来的，首先看下case 0x1b的bytecode：

然后观察前两行：

结合bytecode的内容，v15 = 3，v16指向了C1所在的地址，然后往后看这两个变量的引用：

发现在memcpy中被使用，所以可以断定v15指定了v16的长度，然后被复制到了内存的某个位置，这里我尝试使用capstone反汇编了一下，发现可以反汇编出来，所以就猜定是JIT了。

ret一目了然

到这里所有handler都知道如何翻译成x64汇编指令，所以可以着手编写parser了，下面是我的parser实现：

有一些要点需要注意：

将产生的parse.s汇编产生的目标文件放入ida中分析：

这里可以看到经典的AES shfit_rows tales(查表法)，并且还有9轮大运算，最后是一个循环将密文拷贝到buf2上。

我们需要找到在VM中state[]所在的内存地址，这里shiftRows我们已经逆出来了，定位哪个是shiftRows其实不难，可以发现这个load操作：

但是知道了光知道state[] = a1->rbp + 22没用，因为我们最终还是要在虚拟机中修改，我们需要知道

a1->rbp + 22在虚拟机中的地址。

这里我采取的找到这一行load的汇编:

所以只需要在load处下断点，但是并不是所有load都需要断下，所以在ida中加入条件断点，就在bytecode存放地址的0x7ed处，经过多次调试的经验，发现bytecode的地址是固定，所以索性将

condition写死：

最后state的地址就是rdi中的值

最佳的patch时机应该在第九次列混淆之前，所以我们需要找到这个时机，完成patch

同样的思路，我们注意到了九次循环，如果我们能断在每个循环上，那么我就可以在循环中寻找patch时机，所以找到这个for循环的汇编的cmp指令，作为每次for循环的检查点：

写入ida 断点的condition：

这样知道patch地址和patch时机就可以开始patch了，如果patch了之后发现改变的字节为1个，那就是晚了一轮，如果改变的字节早了一轮那就是早了，总之在倒数第几轮里确定时机，我没记错的话实在地八次到达断点时，patch就是在第九次列混淆之前，patch之后的结果简直完美，只要两组4种group就可以会恢复出last round key。

接下来，写脚本来进行DFA 攻击

根据上一步恢复出来的last round key，恢复初始密钥：

最后提取密文解密

此题得解。

用了整整一个星期，终于把这道题硬生生啃下来了，其中遇到了很多的问题，如理解reg_index和stack的关系，实现过程中cmp的reg_index少减了一个1导致汇编出来的放入ida中的逻辑对不上，reg中一开始也使用rsp加入parse中但是到ida分析中导致一些信息丢失，因为这个问题出现时cmp的错误还没修复，所以我不是很确定是rsp的问题还是我cmp的问题。汇编出来放入ida反编译提示too big function，一度心灰意冷，搜索解决思路还好容易解决，不然卡在最后一步太难受了。还有就是DFA那里，还算顺利，总之就是耐心，细心。

感谢一些前人做的工作，如AES DFA攻击讲解很好，还有优秀的parser辅助我，导致这篇文章可以问世。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！