某韩国游戏驱动保护使用IDA静态分析方案

本文分享自安全论坛，通过对游戏样本使用IDA静态分析，寻找驱动保护机制，并扩展学习设计模式的思路。

背景说明：

样本XIGNCODE3是为大型多人线上游戏所发行的一款游戏反作弊软体，被用于如新枫之谷（南韩版）、战地之王等网游中。XIGNCODE为wellbia所制作。

下面请和笔者一起分析了整个驱动的流程部分，依次介绍分析过程和思路，在这个样本里不仅可以学习到很多内核编程的知识，也可以借鉴到一些设计模式上的东西。

 那么我们直接开始分析，先从入口点开始。

一、驱动入口点

首先，一般在DriverMain中驱动主要会做几件事：

①初始化系统版本偏移

②注册通信的分发函数

③设置通讯函数

④注册通知和回调

⑤创建进程通知

二、初始化系统版本偏移

本步骤的思路主要是根据不同的系统版本号初始化一些全局变量，这里不做具体分析了：

三、初始化系统版本偏移

3.1 DisPatchCreate和DisPatchClose的分发，因为是默认的分发函数，并没有太多可以分析：

3.2 DispatchWrite函数的分发

3.2.1通讯数据结构的部分分析

这里就比较关键了，可以注意到丢了两个通讯条件，一个是在通讯函数的头部存放了一个长度值，另一个是sysBuffer的值是一个固定值。

由此我们目前可以确定InputBuffer中的前8个字节0x345821AB00000270

前四个字节是长度，后四个字节是固定标识码，用于确认三环程序的身份。

3.2.2 FuncCall分析

由于在上一小节中我们只知道了InputBuffer的前8个字节，直接看IDA分析过后的代码，可以看到while中的条件判断是在判断FuncIndex，函数编号：

我们双击FunCallArray进去看看里面是什么？是标准的8字节排列的对象，由此猜测这很可能是函数数组。怎么确定这个事实？并且也确定FuncIndex就是函数索引的呢？请别急，继续看下一节“设置函数通讯你列表”：

四、设置通讯函数列表（SetKeyDisFuncArray的分析）

我们观察上面的截图，看到第一个140010F88(8字节)和140010F90(4字节)

再看看下方的截图，你发现了什么？它就是一个8字节对齐的全局的结构体数组：

由此我们可以知道3.2.2小节中FuncCall的命名由来，实际上他在根据索引确定函数的调用。

接下来会挑几个个人觉得比较有意思的函数进一步分析：

4.1 ReadProcessMemory

4.2 DisObSetHandleAttribute

可以看到一个附加操作下面，又调用了一个函数，继续跟进发现内部调用了“ObSetHandleAttributes”：

如果在逆向分析时不了解这种函数是做什么的，请尝试打开wrk搜索：

我们继续看一下HandleFlags的结构体类型：

基本可以确定这是一个用于关闭文件的函数，但如果不是十分肯定的话，可以通过搜索引擎进一步确认。

4.3 DispSetWin32kTable

一直跟进可以发现它是在做一些函数全局变量的初始化：

4.4 DetectUserDrawDllHook

可以看到这个函数里的关键部分“CraeteDrawDLLDetectMemory”：

我们继续跟进：

可以发现里面申请了内存，然后把字符串拷贝进去，显然这是在创建需要检测的dll数据。我们能分析得到这驱动会在“dwmcore.dll”、“gdi32.dll”、“user32.dll”上做一些监控。

4.5 DispSetWindowDisplayAffinity

继续跟进：

进入“CreateKernelAndUserDetectThread”，参考图中注释可以看到这个函数在做什么：

五、注册通知和回调

继续分析，我们会发现通知和回调干了两件事，红框圈出来的部分：

我们深入进去看下RegisterCallBack：

六、创建进程通知

我们深入进去看一下：

继续跟进CheckInformationProcess，看到两个关键点：ZwQueryInformationProcess,查询号为27：ProcessImageFileName，然后也出现了ZwClose。

如果你有在这款驱动加载的情况下打开某些调试器的经验，那么大概就是这个函数在生效影响。

本文转自【看雪论坛】，原作者【铜锣湾扛把子】