游戏外挂检测和反检测

关于游戏外挂检测和反检测（真正的防封技术）
在网上找到篇关于游戏外挂检测和反检测的文章拿来跟断点的朋友分享。详细文章见附件，这里写些简介。
    一：内存探测法
        服务器发送个Paket检测游戏内存，然后返回服务器。这对游戏公开的挂威胁大。
        反侦测基本思想是拦截Peket,返回伪装Peket。
    二：DLL扫描
        游戏反外挂系统（Module32First/Module32Next）扫描游戏中的DLL，返回。
        反侦测思想是DLL隐藏。
    三：进程扫描
        游戏反外挂系统（Process32First/Process32Next）扫描用户进程，返回。
        反侦测思想也是进程隐藏（如将外挂进程注入到游戏进程）
    四：窗口扫描
        游戏反外挂系统（EnumWindows）扫描进程窗口，返回。这主要针对有GUI界面的外挂（外挂都有）
        反侦测思想是随机产生窗口类名和窗口名。（现在很多外挂都能做到这点）

暴雪和黑客的战争（游戏外挂与反外挂）BZ加亮
[ sell=5][/sell][ post]如前一篇文章所说，D2X中hacks的发展大约可以分为三个阶段，即前1.10的发展成熟期，1.10的过渡期以及1.11的衰落期。
一直到1.09d（1.10前的最后一个版本）为止，D2X中几乎没有作弊检测机制，这一时期是hacker们最幸福的时期。说没有是因为它没有专门的检测代码，而说几乎没有是因为它有些机制还是可以用来做作弊检测用途的。
一处是它的自动升级机制。在战网上玩过的玩家都知道，每次连到战网的时候，会有一个对话框提示正在检查游戏版本，如果用户本机和服务器端额版本不一致的话，自动进行升级。Diablo的自动升级功能在游戏业界可能是首创，这大大降低了游戏的上手难度。我接触过不少外国玩家，跟国内玩家不同的是，他们中很多人都是一些15岁不到的小孩，让他们自己从网上下载补丁包升级几乎是不可能的事。自动升级的过程如下：
1，玩家连到战网；
2，服务器端发送一个专门用于版本检查的DLL到客户端；
3，客户端在本机保存该DLL；
4，客户端调用LoadLibrary加载DLL
5，客户端调用该DLL导出的一个函数。该函数通过计算几个重要的客户端游戏文件的校验判断版本是否匹配，不匹配则做自动升级。
6，客户端版本检测完毕，调用FreeLibrary卸载DLL并删除文件。

在这个过程中，由于版本检查DLL保存在服务器端，因此显然它可能会被随时修改，增加一些其他功能，如作弊检测。从版本检测相关代码（见文末）调用的Win32 API，LoadLibraryA/GetProcAddress/FreeLibrary/DeleteFileA，可以大致看出这一过程。

另外一处不为人知的机制是，在玩家连上战网后，服务器端有时（不是一定会发，而且发送时机也不确定）会发送一个DLL (Extrawork.dll)到客户端运行，然后把结果返回给服务器端，其工作原理和版本检测机制的工作原理非常类似。显然这个机制也可以用于作弊检测。不过根据很多hacker观测的结果，extrawork.dll一般用于收集玩家的系统配置信息，包括CPU主频、内存容量、操作系统版本等。

虽然这两点机制都可能用于作弊检测，但在1.10以前的时间里，没有迹象表明暴雪利用了这点，因此在这一时期出现的hacks也都没有相应的反检测措施。

版本检测的相关代码：

XXXX45A3                 lea     ecx, [esp+124h]
XXXX45AA                 push    ecx             ; IX86ver0.dll
XXXX45AB                 call    ds:LoadLibraryA
XXXX45B1                 mov     ebp, eax
XXXX45B3                 test    ebp, ebp
XXXX45B5                 jz      loc_6FF046F1
XXXX45BB                 push    offset aCheckrevision ; "CheckRevision"
XXXX45C0                 push    ebp             ; hModule
XXXX45C1                 call    ds:GetProcAddress
XXXX45C7                 mov     esi, eax
XXXX45C9                 test    esi, esi
XXXX45CB                 jnz     short loc_6FF045DF
XXXX45CD                 push    offset aErrorFailedT_0 ; "<ERROR: Failed to execute Versioning DL"...
XXXX45D2                 call    nullsub_1
XXXX45D7                 add     esp, 4
XXXX45DA                 jmp     loc_6FF046EA
XXXX45DF loc_XXXX45DF:
;......
XXXX46E6                 call    esi             ; CheckRevision
XXXX46E8                 mov     ebx, eax
XXXX46EA
XXXX46EA loc_XXXX46EA:                           ; CODE XREF: DownloadAndRunVersioningDLL+15A j
XXXX46EA                 push    ebp             ; hLibModule
XXXX46EB                 call    ds:FreeLibrary
XXXX46F1
XXXX46F1 loc_XXXX46F1:                           ; CODE XREF: DownloadAndRunVersioningDLL+F3 j
XXXX46F1                                         ; DownloadAndRunVersioningDLL+11E j ...
XXXX46F1                 mov     eax, [esp+430h+hArchive]
XXXX46F5                 pop     ebp
XXXX46F6                 test    eax, eax
XXXX46F8                 jz      short loc_XXXX4700
XXXX46FA                 push    eax             ; hArchive
XXXX46FB                 call    Storm_252_SFileCloseArchive
XXXX4700
XXXX4700 loc_XXXX4700:                           ; CODE XREF: DownloadAndRunVersioningDLL+278 j
XXXX4700                 push    32h             ; dwMilliseconds
XXXX4702                 call    ds:Sleep
XXXX4708                 mov     esi, ds:DeleteFileA
XXXX470E                 push    offset g_szVersionDLLName ; lpFileName
XXXX4713                 call    esi ; DeleteFileA
XXXX4715                 mov     al, [esp+42Ch+FileName]
XXXX471C                 test    al, al
XXXX471E                 jz      short loc_XXXX472A
XXXX4720                 lea     eax, [esp+42Ch+FileName]
XXXX4727                 push    eax             ; lpFileName
XXXX4728                 call    esi ; DeleteFileA

暴雪在WOW开发的后期，终于能够腾出人手来升级持续了2年之久的D2X 1.09d。由于1.09d时期hacks泛滥，暴雪觉得有必要打击一下这种嚣张的气焰，于是加入了hacks检测机制，这就是在1.10时期经常提起的packet 64/65检测。

何谓packet？packet即网络数据包，D2中服务器端和客户端之间的交互是通过互相发送packet进行的。D2中的packet又分为out-of-game（进入游戏前）packet和in-game（游戏内）packet两种，这里提到的都是in-game packet。in-game packet的第一个字节为packet ID，指示该packet的含义，接着的是相应的（可变长）参数。比如ID 01代表walk命令，长度为5字节，ID后面跟两个16位参数，指示walk的目的坐标，因此它的格式为：01 [WORD x] [WORD y]。需要注意的是D2中不同patch版本的packet ID含义是不一样的，不能通用。1.10中的一个比较完整的in-game packet列表可以在这里找到：http://www.edgeofnowhere.cc/viewtopic.php?t=303771

跟hacks检测有关的是packet 64和65。packet 64长度是9字节，格式为：64 [DWORD address 1] [DWORD address 2]，后面的两个DWORD是服务器端想检测的两个内存地址；packet 65长度为1字节（没有参数），检查4个最有可能被patch的地址。packet 64/65的检查结果经过简单的混淆处理（增加sniffer抓包分析的难度）后发送回服务器端，如果被检测地址里的指令或数据被改过，检测结果自然就和原先的不符，因此暴雪就知道你在用hack。这种检测方法就是所谓的memory probe，即内存探测法。那暴雪怎么知道应该检测哪些地址呢？hack的detour patch（旁路点）是固定的，像maphack和d2jsp这种著名的公开发行的hack，暴雪当然会拿来研究因此也会知道它们patch了哪些地方。至于那些自己开发自娱自乐的，暴雪是没法知道的，因此相对安全点儿。但是如果你的patch点正好和maphack、d2jsp这些相同，那还是有可能不幸中标。

以下为packet 64检测中的相关代码片断，其中eax和ecx分别为两个待检测的内存地址，检测结果分别存入局部变量var_result1和var_result2中随后发送回服务器端：

.text:XXXXF362 $CHECK_RESULT1: ; CODE XREF: CheckDetectionResult+87 j
.text:XXXXF362 cmp eax, esi ; not zero
.text:XXXXF364 jz short $CLEAR_RESULT1 ; Jump if Zero (ZF=1)
.text:XXXXF366 mov [ebp+arg1], esi
.text:XXXXF369 mov eax, [eax]
.text:XXXXF36B mov [ebp+var_result1], eax
.text:XXXXF36E mov [ebp+arg1], -1
.text:XXXXF375 jmp short $CHECK_RESULT2 ; Jump

.text:XXXXF39B $CHECK_RESULT2: ; CODE XREF: CheckDetectionResult+A5 j
.text:XXXXF39B ; CheckDetectionResult+C4 j
.text:XXXXF39B cmp ecx, esi ; Compare Two Operands
.text:XXXXF39D jz short $CLEAR_RESULT2 ; Jump if Zero (ZF=1)
.text:XXXXF39F mov [ebp+arg1], 1
.text:XXXXF3A6 mov ecx, [ecx]
.text:XXXXF3A8 mov [ebp+var_result2], ecx
.text:XXXXF3AB mov [ebp+arg1], -1
.text:XXXXF3B2 jmp short $SEND_DETECT_RESULT ; Jump

packet 65的检测代码和packet 64类似，除了它检测的是几个固定地址。

packet 64/65的memory probe机制，结合前一篇介绍过的已有的version-checking.dll和extrawork.dll，就构成了暴雪在Diablo II 1.10 patch中采用的hacks检测机制。

下图显示了d2jsp 1.2.0中使用的部分旁路点（d2jsp 1.2.0用于Diablo II 1.11b，但意思是一样的）。

暴雪在1.10补丁中加入hack检测机制，在某种程度上直接导致了原本和谐的D2X游戏黑客社群的分裂。一部分出于对检测机制的顾虑，停止更新自己的作品，如d2hackit；另一部分则把他们的hack具有的反检测功能当成卖点开始收费，如d2maphack和d2jsp；还有一部分黑客出于不满开始制作这些收费hacks的替代品，如d2hackmap，C3PO，d2bs等；甚至有些黑客出来破解这些收费hacks。

如前一篇文章所说，暴雪在1.10中加入packet 64/65检测。最早公布packet 64被用作hack检测的是jhj。当然Mousepad在jhj之前就已知道这一点，但是他当时正打算对maphack收费，反检测是一大卖点，因此一直没有公布。在jhj公布了他的发现后，我检查了相关代码，又发现了packet 65也被用作hack检测。

如前文的分析，packet 64/65检测用的都是memory probe方法，那么memory probe该怎么对付呢？一种简单的想法是在客户端截获packet 64/65检测，不让它返回检测结果。截获packet 64/65检测思路是对的，但不返回检测结果其实也是一种信息，暴雪完全可能根据这点判断你在使用hacks，最不济也会把你踢下线，显然不是好的做法。对付memory probe，更好的做法是伪造检测结果。这需要截获packet 64/65检测，然后根据要检测的内存地址返回该地址被修改前的数据（如果已经被修改了的话），这样无论检测哪个地址，检测结果都和没有使用hacks时的一样。

具体到实现方法，大约又有三种。

一种是hack在安装旁路点时，先保存原先的数据，这样在遇到检测时就能知道patch前的数据。使用这种方法的有d2maphack、d2jsp等。这种方法最简单，实现起来也容易，占用额外内存也不大。缺点只能保护自己，不能保护其他hacks。

第二种方法由jhj实现，其原理是在加载任何hack之前，先对游戏中用到的重要的dll做备份，这样就获得了这些dll干净的副本。然后截获 packet 64/65检测入口，根据检测地址，从干净的副本中返回相应的数据。这就是jhj在 1.10时期发布的antidetection.dll。这种方法最大的优点是通用，可以保护其它hacks－其他hack不需要有任何反检测措施就能避开检测。但是这种实现也有不小的缺陷。其一是它必须抢在其他所有hack之前加载，否则无法获得干净副本－如果无法获得干净副本这种方法就完全失去意义－这在有些情况下是不容易做到的，比如无人职守的BOT。其二是所有重要的dll都要备份，这会额外消耗不少内存，对机器配置差或者多开BOT的玩家有很大影响。其三是antidection.dll只备份了它认为重要的dll，而不是所有dll，这样如果有的hack修改的dll不在它的保护范围，还是有可能被抓到。

第三种方法由我实现，称之为模块重建法（module re-construction），首先在d2hackmap中实现，后来ABin升级d2hackit时请我帮忙实现anti-detection模块，因此我又把它集成进了d2hackit 2.00版本中。这种方法的思路是截获packet 64/65检测入口（显然所有反检测方法都需要这一步），根据检测地址判断出目标模块名称和其在硬盘文件路径，然后从该模块的硬盘文件开始重建一份干净的副本，最后从干净的副本中返回相应的数据。这种方法在没有检测活动时（其实1.10时期packet 64/65检测很少出现）不会消耗额外内存，可保护所有dll，也无需抢先加载。我个人觉得是一种比较理想的方法。当然，模块重建法的难点在于如何从一个 dll文件重建一份和已加载模块被修改前完全一样的副本（其实是代码段和只读数据段完全一样，读写数据段无所谓），这在以后的文章中应该有机会介绍到。

另外，除了packet 64/65检测，别忘了1.10以前一直就有的version-checking.dll和extrawork.dll机制。虽然它们在前1.10时期从未被用作hack检测，但是显然暴雪在1.10时期开始重视打击hacks，因此也不得不防。回想一下这两处机制，由于这两个dll都存放在服务器端，必要时发送到客户端运行并返回结果。不让它们运行显然是不行的。并且显然它们的检测手段也是无限、未知的，伪造检测结果也不可行。那该怎么办呢？

对付这种手段的一种比较有效的方法是，截取并保存尽可能多的从服务器端传过来的dll，逐一分析，标出安全的和不安全的，并对每个dll建立签名（signature）。这样在每次客户端接收到dll时，先计算出其签名然后和已事先分析过的所有dll签名比较，这样就可知道该dll安不安全（即能否检测出我的hack），如果安全则让它执行，如果不安全则hack会自己卸载，然后再让该dll执行。这样就不会被它抓到。另外对于未知模块（即该 dll的签名不在列表里），应该把它保存下来以供事后分析，同时为保安全hack自己卸载，在以后分析后再把它标识为安全或不安全。当然对于不安全的模块还应进一步研究反检测方法然后把它标为安全模块。d2maphack、d2jsp采取的都是这种策略。d2hackmap由于我后来没有太多精力人工分析这些模块，因此只在配置文件里设置开关变量，指示d2hackmap遇到这些模块时如何处理（有忽略、卸载自身、保存模块文件并卸载自身三种选择）。至于 jhj的AntiDetection.dll是没有这方面的反检测保护的。事实证明这种策略是比较有效的。一个可能的原因是由于设计所限，这种发送dll 检测机制尚不具备快速变形、频繁运行的能力。

游戏外挂检测和反检测相关推荐

游戏里的多开-检测和反检测
一.从生命周期的角度看游戏的多开检测 0x0 事前检测当你启动第二个游戏的瞬间阻止你这个行为,防患于未然. 特点:不会涉及到封号,这是人为的一个功能. 0x1 事中检测在游戏运行的过程中进行悄咪咪 ...
Root检测与反检测
0x00背景需要在手机上构建一个环境对root过的设备进行伪装,让设备里面的应用将该设备当成未root的设备. 0x01 Root检测手段 1.检查已安装的APK包: SuperSU应用程序或者一键 ...
恶意软件反检测技术简介：反调试技术解析
本文中,我们将向读者介绍恶意软件用以阻碍对其进行逆向工程的各种反调试技术,以帮助读者很好的理解这些技术,从而能够更有效地对恶意软件进行动态检测和分析. 一.反调试技术反调试技术是一种常见的反检测技术 ...
vivo 游戏黑产反作弊实践
作者:vivo 互联网安全团队 - Cai Yifan 在数字化.移动化的浪潮下,游戏产业迅速发展,尤其疫情过后许多游戏公司业务迎来新的增长点. 游戏行业从端游开始一直是黑灰产活跃的重要场景.近年来, ...
恶意软件反检测技术简介：模拟器超限技术
恶意软件是一种招人恨的代码,因为它们专干坏事,如泄漏个人隐私.造成数据丢失,等等.而杀毒软件公司则不断想办法检测并阻止恶意软件.如此一来,猫和老鼠的大戏从此开演了.一般来说,杀毒软件要想防御某种恶意软 ...
unity3D 如何提取游戏资源（反编译）+代码反编译【P.M.出品】
转自:https://blog.csdn.net/LANGZI7758521/article/details/52291564 首先感谢雨松MOMO 的一篇帖子教我们怎么提取 .ipa 中的游戏资 ...
简单说一下 Steam平台常用游戏的EAC反调试保护 WIN7X64
内核层:3个内核线程用于不停的恢复THREAD PROCESS-CALLBACK 直接1字节anti会开启不了驱动这里比以前的TP好点儿 CALLBACK里面抹去了句柄的读写内存权限导致OD看不见 ...
游戏是通过什么检测脏话的?Python带你搞清原理！
在游戏中聊天功能几乎是必备的功能,这样的功能存在一定的问题那就是会导致世界频道很乱,经常会有一些敏感词,或者一些游戏厂商不愿意看到的聊天,之前我们游戏中也有这样的问题,我们公司做了举报和后台监控,今天 ...
多家国产独立游戏厂商发布反淘宝盗版联合声明
本文转载自IT之家 IT之家 8 月 18 日消息今日晚间,多家国产独立游戏厂商发布了<国产独立游戏反淘宝盗版联合声明>. IT之家了解到,声明称淘宝平台未经审查擅自允许侵权商家私自上架 ...
不同游戏的不同反作弊引擎
介绍不同游戏使用的不同反作弊引擎反作弊引擎: Advanced ProtectoR (Discontinued) BattlEye BlackBox CleanDoD (Discontinued) ...

游戏外挂检测和反检测

游戏外挂检测和反检测相关推荐

最新文章

热门文章