2022游戏安全技术竞赛-初赛

• PlaneJun ・2022-4-27 13:59

运行效果：

原程序运行后显示ACE，并且许秒后绘制消失。原题则要求如下：

详细分析及实现：

首先创建了一个名为”avoid repeat open”的互斥体，保证程序的单例执行。

然后开始创建窗口，并初始化D3D设备。

随后开始动态获取ZwAllocateVirtualMemory和ZwFreeVirtualMem的函数地址。

调用ZwAllocateVirtualMemory申请一段可执行内存后，开始将两段shellcode写入。

紧接着可以看到通过调用GetTickCount来判断运行时间是否超过4秒，若超过4秒则清空shellcode，即绘制消失。

shellcode的入口为D3D的一些shader初始化。

动态编译shader完毕后开始执行虚拟机。

简单分析了之后，可知每个分支作用如下：

指令	作用
0	寄存器相加。eg：v1+=v2
1	两数相减。eg：v1-=v2
2	寄存器赋值。eg：v1=v2
3	立即数赋值。eg：v1=999
4	计算key。
5	绘制黄色小方块
6	绘制青色小方块
7	函数返回

由于绘制青色方块正常，黄色方块不正常，故猜测黄色方块数据存在污染。

进一步分析DrawFillRect函数，得知前四个参数中，第一第二个为坐标数据，第三第四个为Key。并且在捕获绘制青色方块的数据时发现，第三和第四个参数在参与运算时结果始终为0，反之，黄色方块不为0。

将指令集扣下后使用C++进行模拟流程，并输出操作流程。

经过对比，发现黄色方块在计算Decryp之后，将Table[6]与Table[7]的值进行了互换。直接通过判断互换流程将其修改为Table[3] = Table[1]禁止互换。

修改后发现仍然没有绘制黄色小方块，通过代码调试发现绘制时，Table[4]为负数，而Table[4] = (Table[0] – Table[1]) = 0x32 – 0x3E8。

怀疑0x3E8为故意使坐标计算为负数，故将0x3E8修改为0x0后，黄色小方块显示。

同理，第二个黄色方块的由于没有Key互换，但是对0x1F4计算，将0x1F4修改为0，后方块显示。

经过手动修改后，发现存在0x3E8和0x1F4数据对黄色方块的坐标进行污染，将其修改0，并且禁止key互换后，旗帜显示。

以下为C++修复表部分效果。

修复完毕后会自动运行程序后执行修复表操作。