那CTF,那VMre,那些事(一)
vm虚拟机保护逆向,是一种利用了虚拟机技术的一种特殊加花指令方式。目前比赛中,虚拟机题目特点是核心算法不是很复杂,虚拟机本身没有反调试和代码加密混淆的加入。大部分题目的思路都是考察分析switch语句及其分支。
0x00前言
最近做题刷到了2020网鼎杯一道vm虚拟机保护的re题目,遂决定系统的学习一下vm虚拟机保护逆向的相关知识。毕竟vm逆向在各大比赛中势头正盛。
题目附件在文章末尾。需要的大佬可以下载学习一下。
0x01什么是虚拟机?什么是vm?
学习虚拟机逆向,首先要了解什么是虚拟机。按照我之前的粗浅理解,虚拟机是寄生于宿主电脑上的一台虚拟电脑,来满足使用者关于多个操作系统配合、危险软件隔离分析等等需求的技术。当然这是个人理解,仅供参考。而在大佬博客中,我看到了如下精彩的定义:
虚拟机:自己定义一套指令,在程序中能有一套函数和结构解释自己定义的指令并执行功能。
上述定义将虚拟机的原理讲的很透彻了。接下来我们说说什么是vm。首先给出官方定义
vm(虚拟机保护)是一种基于虚拟机的代码保护技术。他将基于x86汇编系统中的可执行代码转换为字节码指令系统的代码。来达到不被轻易篡改和逆向的目的。
简单来说就是出题人通过实现一个小型的虚拟机,把程序的代码转换为程序设计者自定义的操作码(opcode)然后在程序执行时通过解释操作码,执行对应的函数,从而实现程序原有的功能。
下图是一个一般虚拟机结构
对于上图出现的概念的解释:
VMRUN:虚拟机入口函数
dispatcher:调度器,用于解释opcode,并选择对应的Handler函数执行,当Handler执行完后会跳回这里,形成一个循环。
opcode:程序可执行代码转换成的操作码
Handler:各种功能对象模块
当然这里的虚拟机并不是指VMWare\VirtualBox之类的虚拟机,它更像是一个用于解释系统函数的一个小型模拟器。
0x02出题人如何实现vmre小型虚拟机
想要搞清楚虚拟机保护re首先要搞清楚用于保护的虚拟机是如何实现的。
要想实现虚拟机的话需要完成两个目标:
1.定义一套opcode
2.实现opcode的解释器
初始化虚拟寄存器、opcode存放
1 | typedef struct |
r1-r3用来传参或者是存放返回值,eip指向opcode的地址
定义opcode
opcode只是一个标识,可以随便定义
1 | typedef struct |
关联opcode和对应handler函数
1 | void *vm_init() |
虚拟机入口函数
1 | void vm_start(vm_cpu *cpu) |
解释执行器编写
1 | void vm_dispatcher(vm_cpu *cpu) |
具体执行函数实现
这里实现 mov xor read 三个简单的指令 其中read指令用于读取数据 在题目中用于读取flag。具体题目中根据题目要求实现不同的函数功能即可。所以说虚拟机类re题目很好的考察了参赛选手的代码能力
1 | void xor(vm_cpu *cpu) |
定义opcode字符集
定义opcode字符集,每个字符对应一个函数功能模块
1 | unsigned char vm_code[] = { |
至此,一个简化版的小型虚拟机就实现完了。该虚拟机实现了对输入字符串简单的异或加密,并将加密后的值存储到指定位置。
用gcc编译一下就可以在ida上自己逆着玩(没想到意外的学会了vmre怎么出题)
0x03 ctf vm逆向思路
了解了上述知识,下面我们来梳理一下ctf中vm逆向的思路
这里借用一位大佬的总结
解题一般步骤:
分析VM结构->分析opcode->编写parser->re算法
VM结构常见类型:
基于栈、基于队列、基于信号量
opcode:
与VM数据结构对应的指令 :push pop
运算指令:add、sub、mul
0x04 ctf实战
纸上得来终觉浅,掌握了vm虚拟机保护的核心科技。做几个ctf题目来实践一下。先来看看南邮CTF经典的两道vm逆向( WxyVM1 WxyVM2)
WxyVM1
先查壳,文件为无壳64位文件 反编译main函数
1 | __int64 __fastcall main(int a1, char **a2, char **a3) |
main函数逻辑非常简单 flag经过sub_4005B6的处理之后 与dword_601060[i] 进行匹配。
那么我们只需要把sub_4005B6研究明白就可以了
1 | __int64 sub_4005B6() |
sub_4005B6()函数里也有一个已知数组byte_6010C0,byte_6010C0数组三位为一组,第一位指示操作,第二位指示输入的哪一位进行操作,第三位指示操作数。观察发现byte_6010C0数组第一位只有1, 2, 3,所以只会存在前三种运算,即加减异或,这都是很好逆的算法。由于byte_6010C0数组过大,我们选择不导出直接利用idapython的方式直接re
1 | from idc_bc695 import * //IDA7.5+需要引入该库不然会报错 |
运行得到flag
WxyVM2
考察去花指令
同样的无壳64位。这次反编译main函数的时候出问题了
百度搜索了一波找到了解决方案
1 | 修改ida中的cfg文件夹下的hexrays.cfg中的 |
耐心等待…让子弹飞一会儿。进去会看到大量的伪代码。千万不要被这两万多行的代码吓住了(确实很吓人)我们仔细观察一下末尾的循环发现,由于的循环长度只有24,dword的地址远远超出了这个范围。所以dword数据的计算,其实影响不到最后的结果。byte的计算才是我们这题真正的算法所在。
接下来可以使用ida脚本去花。只保留byte的相关计算
1 | import os |
也可以使用文本编辑器,这里推荐emeditor 正则匹配的功能相当完善。处理大批量数据不卡顿。最后将处理过的数据输出即可
1 | arr = [4294967232, 4294967173, 4294967289, 108, 4294967266, 20, 4294967227, 4294967268, 13, 89, 28, 35, 4294967176, 110, 4294967195, 4294967242, 4294967226, 92, 55, 4294967295, 72, 4294967256, 31, 4294967211, 4294967205] |
[网鼎杯 2020 青龙组]singal
前两道题目感觉还是缺点vm的味道。应该是题目简单的原因吧。接下来网鼎杯的这道题目才真的开始有内味了。
1 | int __cdecl main(int argc, const char **argv, const char **envp) |
反编译一下main函数。发现本题是一道标准的vm逆向。先根据我们总结过的vm逆向思路,写个脚本提取出operad_code
1 | from idc_bc695 import * |
整理一下获取的数据
1 | op_code=[10,4,16,8, |
接下来分析 vm opread部分。是典型的VM switch结构
1 | int __cdecl vm_operad(int *a1, int a2) |
分析一下这些case 我们发现可以分为三类
第一类:验证类
1 | case 7: |
其实就是把输入的字符串经过一系列操作之后存到了opcode
中
第二类:字符处理
1 | case 2: |
第三类:其他操作
1 | case 1: |
进一步分析我们发现:v5 v6 v7 v8是数组的索引,v4为操作的返回值.这样switch就分析的很明了了。下面回过头来看一看op_code。发现在比较操作数7第一次出现的位置之后,都是一些无效指令(大于12),所以,加密运算应该是在操作数7第一次出现之前完成。因此有效的opcode应该是
1 | a=[10, 4, 16, 8, 3, 5, 1, 4, 32, 8, 5, 3, |
分析剩余的部分。既然case7是对数据进行验证。那么7后面跟着的就是加密后的字符。
1 | 7,34,7,63,7,52,7,50,7,114,7,51, |
整理后开始写re脚本。由于本题逆向来写的话实现操作比较复杂所以我们采取正向遍历的思路去试出flag
1 | encrypts = [0x22, 0x3F, 0x34, 0x32, 0x72, 0x33, 0x18, 0xA7, 0x31, 0xF1, 0x28, 0x84, 0xC1, 0x1E, 0x7A] |
0x05后记
在我看来,vm虚拟机保护逆向,是一种利用了虚拟机技术的一种特殊加花指令方式。目前比赛中,虚拟机题目特点是核心算法不是很复杂,虚拟机本身没有反调试和代码加密混淆的加入。大部分题目的思路都是考察分析switch语句及其分支。当然,随着整体CTF水平的不断进步,未来虚拟机逆向难度只会越来越高。
这两天应该会写出系列的第二篇文章,围绕vm虚拟机逆向进阶操作。以及网鼎杯题目的更多解法思路讨论(利用angr)敬请期待
0x06参考链接
https://www.cnblogs.com/nigacat/p/13039289.html
https://www.freebuf.com/column/174623.html
https://blog.csdn.net/weixin_43876357/article/details/108570305
https://blog.csdn.net/weixin_45055269/article/details/105940348
https://blog.csdn.net/lhk124/article/details/108946313
https://blog.csdn.net/xiangshangbashaonian/article/details/78884187