一句话概括就是腾讯自家的虚拟化加密壳。把腾讯的安全产品拉入 PE 工具，看到区段中有 .tvm0 那就没跑了。

这次还原用到的demo是前段时间 游戏安全技术竞赛的决赛附加题一个非常好的demo，驱动基本上全vm了。

还要特别感谢 这位大佬放出来的脱壳版，给我节省了许多验证还原效果的时间。

还原脚本项目地址：xx_tvm

文档我也只说明了一些明显的点，还是看代码更加清晰。

然后给你的idapython安装以下的库:

1.

可优化成：

直接特征识别即可，请参考idapython/TVMunicornTrace.py .tvmFunTask.mabe_1()

2.

可优化成：

直接特征识别即可，请参考idapython/TVMunicornTrace.py .tvmFunTask.mabe_2()

3.

可优化成：

直接特征识别即可，请参考idapython/TVMunicornTrace.py .tvmFunTask.mabe_3_4()

4.(类似 3)

可优化成：

直接特征识别即可，请参考idapython/TVMunicornTrace.py .tvmFunTask.mabe_3_4()

去混淆前：

去混淆后：

虚拟机的大致架构如下，非常标准。

实际上tvm有多个handle分发器和多张handleTable，但是它们的作用、内容完全一致，所以我就只画出一个handle分发器，下面也只讲解一张handleTable

使用unicorn 跟一次tvm入口到出口，脚本参考：idapython/TVMunicornTrace.py

初始rsp设置为 0x1800

入口：(已去混淆) 完整文件请查看trace_file/tvm入口到出口 去混淆.log ，

未去混淆的查看trace_file/tvm入口到出口 未去混淆.log

从 1400d2ffc到1400d315f，tvm第一次保存进入虚拟机前的寄存器状态：

接下来是第二次保存进入虚拟机前的寄存器状态：

从1400d3160到1400d30aa，保存状态如下：

接下来保存 虚拟机指令起始点和虚拟机寄存器的起始指针

结构如下：

14006024c这是当前函数的虚拟指令起始点，可以先记住，后面就知道为什么我这么说了。

接下来进入

进call，return地址入栈：

这个函数，它也会保存一下寄存器状态，但是没啥用：

保存的状态如下：

然后会把V_RIP换个位置;

接下来就开始处理虚拟指令了。先把栈空间的格式整理一下：（这个地方非常重要）

其实只需要记住 R10放着V_REG_P 和 [rbp+8] 放着 V_RIP 。

这是一段 tvmhandle的分发(tvmopcode的处理方式)

[rbp + 8] 是 V_RIP，放入r9，然后从[R9] 取出 tvmopcode 放入r8b 然后异或 0x5D，然后 r9 +1(上面是混淆过的，实际效果就是 + 1 )。

R8b - 1 如果大于0xC8，就跳转到1400D9954，说明这是未知的tvmopcode，出错。1400D9954是int3指令。

然后 handleTable 放入 R9，取表项 [R9 + R8 *8]，即为这个handle的偏移，加上基址0x140000000，即为这个handle 的实际处理地址：1400d60f2，通过 jmp r8 跳转过去。

（可以看到 取得第一个 tvmopcode 是 0xe8 ，和上面图中的是一样的）

注意，tvm有多张handleTable，但是里面的内容都是一样的。所以拿到一张表就行了

从 tvmopcode^0x5d - 1 < 0xC8 可以推测一共有 0xc8 ( 0~0xc7 )个 tvmopcode，例：

现在我们知道，tvm的handleTable有0xc8个有效项，我们就可以遍历handleTable，并且静态跟踪出handle。看它是如何处理的：

导出handle代码（idapython/TVMHandleOut.py）

补充：虽然handle有0xc8个有效项，但是很多是重复的，是留作拓展用的，真正有效的handle就 80个：

左边 是 handle处理地址，右边是 tvmopcode

并在在 当前文件夹/handleout 文件夹内，输出全部handle静态跟踪（运行脚本的同时会对handle去简单的混淆）

：（刚好80个不相同的handle，文件名用 tvmopcode）

一共有80个不同功能的tvmopcode，为节省篇幅，我这里挑一个常见的讲解，全部的handle分析，其余的全部放在（handle_out/）

（那个特别多的是int3，应该是预留以后更新用的）

我静态跟踪handle是以 jnb 为结尾的（就是判断是否大于0xc8后的jnb），所以跟踪文件后半段有一些不用看。

我对 tvmAsm的命名规则：

我这里直接将全部tvmAsm展示出来：（参考 idapython/deTvm.py . tvmHandleTableInit()）

解释：

TVMTABEL.append 第一个参数是我给tvmAsm取的名字，第二个参数就是 tvmopcode，第三个参数是：如果这个handle要取虚拟寄存器，就必须通过 这个值解密取得虚拟寄存器，就像是我上文中解释的：

这里再挑几个特殊说明一下：

把tvm的跟踪规则写好后，就可以跟踪导出这个函数的虚拟化控制流：跟踪参考

idapython/deTvm.py . traceTask.track()

这是我挑的一个短的函数：0x140001250 参考trace_file/sub_0x140001250.log

使用函数traceTask.track(0) + traceTask.traceOut(),输出如下

可能会好奇这些 PO_reg 怎么来的，其实这是我对 traceCode的优化：

正常的取 虚拟机寄存器 都是 [r10 + xxx]，r10 就是 V_REG_P，前面说过了，看下面这一段（前面也出现过）。

例如 PO_r8 其实就是 [r10 + 0x48]

所以 tvmAsm对 PO_reg 操作 可以理解为对虚拟机外的真实寄存器操作。

这里我使用了 标记working + 赋值表记录 的方法，将所有有意义的 tvmAsm找出来。

先说哪种tvmAsm会被标记为 working：（标记为working表明至少可以还原出一条原始Asm）

只要标记好这几个点，就能还原出全部的Asm。参考（idapython/deTvm.py . traceTask.track()）

那么我们标记好后，这段 tvm指令就如下:

箭头指着的就是标记为working的TraceCode。那么接下来要干嘛，就很清晰了，把相关的traceCode找出来（变量溯源）。

例子1:

这一句被标记为working，我们找他使用的参数的赋值语句，直到 找到 整数 或 PO_reg

我们把 [r10 + 0xa8]的赋值语句找出来(往上找):

这一句用到了 [r10 + 0xb8]，找它的赋值语句：

又是 [r10 + 0xb8]，再往上找：

用到 [r10 + 0xb0] 和 [r10 + 0xa0]，往上找：

[r10 + 0xa0]找到尽头了，[r10 + 0xb0]还没找到尽头，继续网上找[ r10 + 0xa8 ]的赋值语句：

找到尽头，是将 PO_rsp 放入。我们把这些 traceCode放在一起：

参考 idapython/deTvm.py . traceTask.VRegRecord()

这样也有点不好看，用变量传播优化一下：

参考idapython/deTvm.py . tvmToAsm.optimize()

这一些 traceCode，就可以还原出一句 Asm:（以下我们对这一段可还原成Asm的TraceCode集合统称为一个 tvmToAsm 结构）

于是这一段就可以还原成：

为什么是 sub rsp,0x28而不是 lea rsp,[rsp - 0x28]是有讲究的：

看traceCode中的一句 v_add_oregll_iregll_iregll_oregl，他是有输出 rflag的，并且放入的位置就是 PO_rf，说明这一句ASM是会影响标志位，而 lea 是不影响标志位的，所以将它还原成 sub。

我们顺势对这个函数的所有被标记为working 的traceCode进行变量溯源+优化，那么最后就可以得到：tvmToAsmAll

一个函数内的所有 tvmToAsm 组成一个 tvmToAsmAll ，下图中一段一段的就是 tvmToAsm

看，真正有效的就这一些，其余的都可以看作花指令。所以这个函数的原始ASM就是：（手动还原）

上文说过，tvm不能模拟全部的Asm，所以有些Asm需要暂时退出虚拟机执行，然后再返回虚拟机：

我们到0x1400c7588，然后往下跟(中间是还原真实寄存器)，

直到出现 mov rsp,[rsp] ，之后的下一句就是真实需要执行的ASM了。即为 call sub_140005E38。

接下来会重新进入虚拟机，步骤和上文进入虚拟机的步骤大致相同。

所以 v_jmp_ll 是最容易还原成 Asm 之一的 tvmAsm了。

参考idapython/deTvm.py . tvmToAsm.vjmp_handle()

关于如何找到workingTraceCode的相关traceCode，我的方案如下：（如果你有其他方案，可以不用看这一段）

把全部traceCode的赋值语句找出来，然后给相关虚拟机寄存器添加赋值记录，形成一张赋值表，例如：

我就可以得到这么一张表：

当需要检索这一句traceCode的相关traceCode时：

就可以直接查表，先找到[ r10 + 0xa8 ]的赋值记录栈traceTaskRegList，然后通过地址找到最近的一次赋值traceTaskReg，然后traceTaskReg记录了这一句traceCode，就可以找到了。

于是就找到了相关traceCode:

因为是将 PO_reg 赋值给它，所以到此检索完毕，如果不是，则按照相同的方法继续往上找。

相关代码参考：idapython/deTvm.py . traceTask.VRegRecord()

例如有两个连续的 tvmToAsm，导出的相关traceCode如下：

我们可以发现，有两段相关traceCode是相同的，这就出现问题了：

第一个tvmToAsm可以翻译成 xor edi,edi，那么第二个tvmToAsm能翻译成什么呢？

如果我们人为识别，就可以将其翻译成 mov ecx,edi，因为 [r10 + 450]在前面已经放入了 PO_rdi，下面又取它放入 PO_rcx。

于是我们可以进行优化，如果 有一句 v_mov_iregx_iregx(PO_reg , xxxx)那么我们就可以将 xxxx的上一次赋值标记为PO_reg，

还是以上面的那一段代码为例：

[r10 + 0x450]上一次赋值语句为：

我们可以将其标记为 PO_rdi，那么当其他的workingTraceCode向上进行查找赋值表的时候，就可以找到PO_rdi，于是就优化为了：

实现代码参考：idapython/deTvm.py . traceTask.VRegRecord()

push:

这是两个连续的 tvmToAsm，

如果按照一般的分析方式，那么这两句可以翻译为：

乍一看没什么问题，就是将 push r13分开成两句执行，可是如果是pop，那么情况就有点不同了：

pop:

如果按照一般的分析方式，那么这两句可以翻译为:

这就出问题了，这两句并不等于 pop r13 指令，那么问题出在哪呢，我们取消掉变量传播优化再看看：

问题就出在，这两句 workingTraceCode在进行变量溯源时，都找到了 0x14004dca7 这一句，

将 PO_rsp 放入虚拟机寄存器 [r10 + 0xa8]，并且在第一句workingTraceCode中，又更改了 PO_rsp的值，所以导致出错。

幸运的是这种情况只会出现在 push 和 pop 中（参考idapython/deTvm.py . tvmToAsmAll.outerror()），

所以我们要对 push 和 pop 特殊处理，请参考：idapython/deTvm.py . tvmToAsmAll.findPushAndPop()

特殊处理，优化后的 push 和 pop：

push:

pop:

这就清晰很多了。

前置知识：

各个标志位的位置：

tvm巧妙的利用了and sub setz je 这四种指令模拟一个jcc，例如：

(v_je 的跳转是通过 加减 V_RIP 实现的，我这里直接优化成 绝对地址，省了我们去计算)

上面的代码，先保留 rflag 的zf位，然后再减去zf位，如果结果为0，那么 V_RIP 就变成 v_je 的第二个操作数 0x14003c274否则 V_RIP变为0x14003c1fe

于是，上面这段tvmasm可以翻译为：

第一个tvmToAsm：

如果 zf = sf = of = 0，则V_RIP = 0x1400369ec ，否则 V_RIP = 0x140036ac6 (其实就是下面那一段，因为优化了所以地址对不上)

第二个tvmToAsm：

如果 zf = 0 且 sf = of = 1，则V_RIP = 0x1400369ec，否则 VRIP = 0x1400368ef

于是，上面这段tvmasm可以翻译为：

JE 的特征 0x40 0x40 （看上图你就知道是什么特征了）

JG 的特征 0x8c0 0x0 0x8c0 0x880（看上图你就知道是什么特征了）

全部的jcc特征：（代码参考idapython/deTvm.py . tvmToAsm.vjcc_handle()）

上面我说JBE JNA 的特征是0x41 0x1 0x41 0x40这其实是错误的：

因为 这只是 jmp if ZF != CF，真正的 JBE JNA 是 jmp if CF = 1 or ZF = 1，

对应的特征应该是 0x41 0x1 0x41 0x40 0x41 0x41，在这个版本的 tvm 中 ，它将 JBE JNA错误处理成了jmp if ZF != CF

我逆了较新版本的 tvm ，JBE JNA这里的bug就被修复了，就是0x41 0x1 0x41 0x40 0x41 0x41。

(看来ACE部门用的tvm版本不够新啊)

参考idapython/deTvm.py . tvmToAsmAll.AllTvmAsmToAsm()

push 和 pop 在上文已经识别出来了，

jcc 在上文也识别出来了，

tvm没有模拟的Asm，也可以通过跟踪 v_jmp_ll 得到，上文也说了。

一些明显的 tvmAsm也可以直接识别原本的AsmOpcode:

如果tvmToAsm中的traceCode的tvmAsm含有以上的字符串，

那么可以直接将这个tvmtoAsm的AsmOpcode设置为对应项，例如：

可以直接将Asm的Opcode 设置成 xor，如果要翻译成Asm的话，就翻译成了 xor edx,edx

以上部分，参考代码：idapython/deTvm.py . tvmToAsm.setASMOpcode_1()

识别 lea mov add sub ，这部分比较复杂，如果是人为识别就简单。

我们先对每一个tvmToAsm内的traceCode再进行一次变量分析，列出一个赋值表，类似于上文赋值表的结构。

除此之外，我们还要对其进行标记设置，例如：

标记的结构：[handle,tvmPara,IsUseRflag]，依次是处理手段、虚拟机寄存器、是否使用(输出)标志位

有了这些标记，再加上14004a507这一句指令，我们就可以识别这个tvmToAsm的AsmOpcode了：

有了这些标记，再加上14006280b这一句指令，我们就可以识别这个tvmToAsm的AsmOpcode了：

有了这些标记，再加上14004a82c这一句指令，我们就可以识别这个tvmToAsm的AsmOpcode了：

有了这些标记，再加上140062837这一句指令，我们就可以识别这个tvmToAsm的AsmOpcode了：

以上部分都只是一些简单例子，关于更加严格的 sub add lea mov 分类，参考代码：

idapython/deTvm.py . tvmToAsm.record_tage() 负责跟踪标记

idapython/deTvm.py . tvmToAsm.setASMOpcode_2()负责分类 sub add lea mov

到这里的时候，全部 tvmToAsm 的 AsmOpcode都已经全部识别。

首先介绍一个工具函数 ：GetAsmPara可以将标记转换成Asm操作数的格式。

例子和上图是一样的。转换为标记如下：

看到140062837这一条workingTraceCode：

v_mov_iregb_iregb ( iregb :PO_rax ,iregb :[ r10 + 0x90 ] );

代码参考：idapython/deTvm.py . tvmToAsm.mov_handle()

例子和上图是一样的。转换为标记如下：

看到14004a82c这一条workingTraceCode：

v_mov_iregll_iregll ( iregll :PO_r8 ,iregll :[ r10 + 0xa0 ] );

代码参考：idapython/deTvm.py . tvmToAsm.lea_handle()

用上面add的例子，但是进行GetAsmPara的是红框框起来的这两个：（对于sub的处理是一样的）

对红框的两个参数进行GetAsmPara：

代码参考：idapython/deTvm.py . tvmToAsm.add_sub_handle()

以下都是 对 红框框框起来的 tvmPara 进行GetAsmPara

代码参考：idapython/deTvm.py . tvmToAsm.push_handle()

代码参考：idapython/deTvm.py . tvmToAsm.pop_handle()

cmp:

test:

代码参考：idapython/deTvm.py . tvmToAsm.cmp_test_handle()

举例如果 opcode是 movzx ：

其余的一样，取 opcode 对应的 第二个参数，然后 workingTraceCode的第一个参数进行GetAsmPara

代码参考：idapython/deTvm.py . tvmToAsm.movzx_movsx_movsxd_handle()

取 tvmAsmOpcode内含有 "not"字符串的那一句traceCode，取第二个参数进行 GetAsmPara

代码参考：idapython/deTvm.py . tvmToAsm.not_handle()

取 tvmAsmOpcode含有 上述opcode 的traceCode，取第三个参数进行 GetAsmPara

取workingTraceCode的第一个参数进行GetAsmPara，以xor为例:

代码参考：idapython/deTvm.py . tvmToAsm.xxx_handle()

上面我们已经获取了 jcc的类型，和它的两个跳转地址，虽然都是 V_RIP，

我们对这两个V_RIP往下找第一个 workingTrace，它所在的 tvmToAsm 就是对应的跳转地址，

我们可以给这个地址的的Asm打上跳转目的地标签，例如:

可以翻译为:

参考代码：idapython/deTvm.py . tvmToAsm.jcc_handle()

这部分略，比较简单，就是通过keystone库函数将Asm编译成十六进制机器码，然后再创建一个段，把内存写进去。详情参考：idapython/deTvm.py . tvmToAsmAll.WriteHex()和main0函数。

值得一提的是，我发现了keystone的一个bug，你们可以试一下：

输出的结果是:

将其转换成 ASM，是

这明显是错误的，0x1400ef00a+0x7+0x4000d250 != 0x14000d250

就能输出正确的字节码。

所以我采用的方法是一句一句将Asm转换成HEX，如果遇到 mov reg,qword ptr[xxx],

就把格式改成 mov reg,qword ptr[rip + yyy]，详情参考代码:

idapython/deTvm.py . Asm.AsmToHex()

main0是对全部ida识别的函数进行特征分析，如果符合tvm函数特征，就对它进行还原。

可以算是一键还原全部tvm函数了，有可能有些tvm函数不符合特征，你也可以手动添加还原函数。

例如：

你知道一个函数0x140001250它是被vm的，那么你这么写，脚本就会自动特征识别V_RIP。

如果你这个被vm的函数不符合我写的特征，但它确实是tvm的函数，那么可以这么写，自己设置V_RIP:

traceOut(0)输出的结果如下:( 基本没做处理)

如果想看 对标记working的traceCode进行变量溯源的结果，你可以这么写:

输出：

如果想进一步的进行变量传播优化还有 push、pop 优化，可以这么写:

输出:

如果想看还原成 ASM是什么样的，可以这样写:

输出:

如果想看 tvmToAsm和Asm对应起来的输出，可以这样写:

输出:

总所周知 ACE-BASE.sys 的DriverUnload函数是被vm了的，那么我们就用它来看看还原效果:

不错，很符合我对DriverUnload的想象。

左边 命名为 icxxx 的函数均为还原成功的函数。

还原脚本项目地址：xx_tvm

这个脚本只适用于这个版本的 tvm (ACE用的版本)。

新一点的tvm，虽然用的是同一套虚拟化指令集，但它会对整数进行加密，读取时进行简单的xor解密，并且新增了一些 虚拟指令。

而且 进入虚拟机的特征也有点不一样，不过对脚本进行简单的修改即可兼容。

ACE你快用新版的tvm，你现在用的版本是有bug的(JBE JNA的模拟是错的)。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课