關于游戲外掛檢測和反檢測（真正的防封技術）
在網上找到篇關于游戲外掛檢測和反檢測的文章拿來跟斷點的朋友分享。詳細文章見附件，這里寫些簡介。
????一：內存探測法
????????服務器發送個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 檢測機制尚不具備快速變形、頻繁運行的能力。

總結

以上是生活随笔為你收集整理的游戏外挂检测和反检测的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。