【CSGO游戏分析】VAC反作弊系统分析

老实说,我不喜欢在其他领域特别是与网络安全或者对抗无关领域显露出自己其他的身份因为这是我以前做的所谓的原则问题.

不过介于现在很多高中没毕业的挂壁还是逛B站的而且考虑到我还是想要一点粉丝(吸粉)的

所以在B站写一下这篇文章吧.   : )

首先是某B乎的打脸视频:

最近又想打CSGO了,于是去打了一把。如你所料,又遇到的挂逼.不过这次挂逼倒是"有点知识",不光转起来了,边转还边"科普"他认为正确的那一套"CSGO反作弊与作弊器的原理".而且还振振有词的说道什么csgo was die（对的就是csgo was die）.

老实说,他的那一套"理论"局外人可能认为很高级,但是在我看来完全就是一个不懂的人强行装成好像CSGO是他开发的CSGO作弊器也是他开发的(不包括那种去国外论坛粘贴源码的人).

所以今天抽空写一下CSGO的VAC反作弊系统的简易分析以方便下次遇到类似的人的时候不会向他一样误导大众:

大部分图片来自TX安全实验室因为我太懒了懒得打开IDA与OD之类的东西重新走一遍流程了

首先我们要知道一些基本对抗作弊的手段:

静态保护：

程序壳 加壳后增加分析难度

代码混淆 让作弊开发很难分析

动态对抗：

驱动保护： 利用ObRegisterCallbacks等手段来锁死内存页保护进程不被打开之类的

反调试： 防止自己被OD等工具调试

调试检测： 同上

模块检测：检测是否有非法模块在自己的内存里面

窗口检测：检测一些特定的作弊器窗口

进程检测：检测一些特定的进程

线程检测：检测是否有作弊器的线程存在

堆栈检测

内存检测

其他：

API处理

多种调试器检测

多种堆栈检测

游戏状态检测

那么CSGO有哪些手段呢:

静态保护：

n 壳：所有PE文件未加壳

n 代码混淆：无代码混淆

 动态对抗：

n 驱动保护：未发现

n 反调试：简单异常干扰

n 调试检测：简单调试检测

l 模块检测：

n 窗口检测：未发现

n 进程检测：有枚举进程模块行为

n 线程检测：有感知线程创建行为

n 模块检测：未发现

n 堆栈检测：有堆栈回溯检测

n 内存检测：未发现

l 其他：

n API：关键API

n VAC2.DLL：存放安全方案预埋，但未在CS:GO中加载

n 未开启检测：

u 发现多种调试器检测

u 发现多种堆栈检测

u 发现有对游戏状态检测

分析:

CSGO中的所有的程序都是没加壳的（加壳会影响性能,所以才不加,不像PUBG那种加了盗版TMD后FPS直线下降）:

VAC并未对游戏关键模块进行加壳，加花等常见PE保护

动态保护分析

反dump

未做反dump处理，游戏模块可以直接dump

反注入

未做反注入处理，游戏内可以随意注入模块

反调试器附加

未对常见断点类API处理，调试器可以任意附加，没有关于附加上的对抗

驱动保护及检测：

Pchunter未检测到游戏有VAC相关驱动加载

Pchuner未检测到内核hook

遍历目录未发现相关驱动文件

Hook ZwCreateFile，未发现有驱动文件创建

Hook NtLoadDriver，未发现驱动载入

Hook DeviceIoControl，未发现有驱动通信

综上，VAC并没有使用驱动对游戏做保护，也没有使用驱动进行检测。

调试器检测

常用api检测

hook IsDebuggerPresent，CheckRemoteDebuggerPresent，感知到游戏有基础检测，触发模块在tier0.dll, tier0_s.dll

游戏确实有通过调用简单的api进行检测，但是这对于32位拥有众多插件的OD来讲，这种检测的意义和效果并不大

Hook NtGetContextThread，NtSetContextThread，NtContinue，KiUserExceptionDispatcher，未发现对dr寄存器进行相关检测

文本暴力搜索IDA， ollydbg，windbg，CE，_Plugingetvalue

, _ODBG_Plugininit等字符搜索……暂未发现对应文本

1. ToolsHelp接口枚举：Hook api：CreateToolhelp32Snapshot, Process32First，Process32Next，发现有steamclient.dll每隔一段时间，就会枚举一次进程

2. Psapi接口枚举：hook EnumProcesses，EnumProcessModules, GetModuleFileNameEx：

Steamclient.dll会进行进程枚举

3. Wtsapi32接口枚举：hook WTSOpenServer， WTSEnumerateProcess

未获取到相关函数调用

4. NativeAPI枚举：hook NtQuerySystemInformation，ZwQuerySystemInformation

跟踪至steamclient中模块中enumprocess调用

句柄枚举进程

1． 暴力句柄枚举，OpenProcess+GetProcessImageFileName

未监控到相关调用

2． 普通枚举，ZwQuerySystemInformation

监控跟踪至steamclient，同enumprocess

3． 其他进程枚举句柄，OpenProcess+ GetProcessImageFileName/GetProcessId

未监控到来自游戏模块的可疑调用

驱动枚举

VAC未加载驱动，此种类型检测可能性不大

触发式枚举

VAC未安装全局钩子，此种类型检测可能性不大

综上，和之前dota2中安全方案类似，VAC通过感知模块创建，最后调用ZwCreateFile和GetFileInformationByHandle进行文件信息上报

1. 传统模块枚举：hook CreateToolhelp32Snapshot，Module32First，Module32Next， Heap32First，GetModuleBaseName

未发现相关调用

2. 遍历PEB模块，hook ZwQueryInformationProcess，未发现来自游戏模块的直接调用

线程枚举

Hook线程枚举的常用api- CreateToolhelp32Snapshot ，Thread32First，Thread32Next，检测未发现

DLL_THREAD_ATTACH感知

新线程创建时，系统会通过DLL_THREAD_ATTACH告诉进程累的dll。Hook ZwQuerySystemInformation，ZwQueryInformationThread。发现有来自steamclient的模块调用

进一步定位到代码

进一步分析得知，VAC通过GetModuleHandleEx和GetModuleFileName获取模块名字，最后通过CreateFile和GetFileInformationByHandle进行上报

交叉引用分析，确定来自于DLL_THREAD_ATTACH的事件感知

API回溯

Hook RtlCaptureStackBackTrace，检测到来自游戏模块的调用

紧接着进行了调用链的分析，游戏会检测是否为正常的调用链关系

TLS/ThreadFrame检测

Hook RtlPushFrame，RtlGetFrame，RtlPopFrame，未拦截到来自游戏的直接api调用

分析结论上来看，游戏自身模块有对关键点做基本的堆栈回溯检测，但是检测频率不高，而这里也只简单的分析了下堆栈回溯常用的api调用，不排除游戏内存在策略代码会检测返回地址的合法性和参数地址的合法性。

游戏内有大量API处理，获取了大量关键API的地址，在一定程度上可以绕过API检测工具，进行一些暗桩检测

在游戏目录下..\\resource\\ sourceinit.dat实际为vac2.dll

目前分析情况来看，依然发现这个dll并没有加载到内存中

为尽可能避免分析过程带来的被检测被封号，笔者多采用了单机游戏和离线分析，游戏的检测策略并没有全部开启，仅仅静态分析tier0.dll和tier0_s.dll，就可以发现大量检测和监控的代码，如对标志位的检测

对堆栈的检测如下图

选取函数跟进分析，调用了RtlCaptureStackBackTrace，但是这些api并没有被我们hook监控到有调用

进一步分析貌似，游戏对堆栈的一些检测还不止与此，采用了不同的校验方式

分析了其他的函数，发现函数貌似除了这些常规检测外，还有对游戏自身的状态进行检测

从分析结论上来看，VAC在CS:GO上目前能感知到的只有简单的特征上报，可能考虑到CS:GO还采取了视频监管和实名认证等安全方案，故没有采取更多的对抗和监控策略，但确实能够看到VAC仍然有不少预埋的检测逻辑，可能会在特定业务场景下，配合动态方案开启。

是不是很晕.很正常,因为我最讨厌的就是分析报告了.简单来说,VAC里面本身就有很多的检测代码没有开启(没有在特定情况下).普通情况下只是做简单的上传内存信息的报告没有做其他的检测.

但是如果一旦Gabe缺钱了，

VAC就会做一些小的更新:

File: vac_module_0_4034d3e194a4d269c43e889593b00bcb.dll

Size: 29KB

Export TimeStamp: 13/05/2017 4:07:59 AM

Debug TimeStamp: 13/05/2017 4:07:59 AM

.text hash: 70E41F8439001066DE3FFFB00B1CDE52A0BF9E6F

File: vac_module_0_125e53d20a0cbe4849b7ff5f0130a2bf.dll

Size: 29KB

Export TimeStamp: 16/05/2017 4:59:39 AM

Debug TimeStamp: 16/05/2017 4:59:39 AM

.text hash: 3AD50243148A16042AA035749A1AEC049FCEA2A3

这些小的更新足以检测到V社想要检测的作弊器.

比如:

另外纠正一下TX安全实验室的一些错误:

VAC会扫描USN和DNSCACHE,嗯,B某平台也用了:

Vac2在CSS后作为备用方案(VAC3加载不成功时启用)就不启用了,CSGO的是启用VAC3.

VAC3加载是steamservice用manually mapped的方式加载,没有调用LoadLibrary所以也看不到模块

VAC3还能检测到未知的Call(在在线情况下):

这种方法虽然能检测到绝大部分作弊器,但是误报率也是很高的,而且这种方法专门处理一下也是可以成功绕过的.所以VAC只是记录并且上传而不全靠这个方法来检测(怕误封).

顺便说一下,国内B某平台的反作弊也用了检测未知call + 用ObRegisterCallbacks 来锁CSGO内存页 的方法来充当 "反作弊",并且认为很厉害.

呵呵。

对了如果你是像素画画得好的或者对音乐制作很有了解的而且对游戏制作感兴趣的,不妨私信一下我.UP本人在开发独立的2D游戏,但是美术和音乐真硬伤 所以可能要找一些小伙伴。

新年快乐 

: )