《Deadlock》VAC內部機制全整理 逆向分析反作弊系統、HWID硬體指紋辨識、DLL信任驗證機制下載

《Deadlock》VAC內部機制全整理 快速閱讀精華

• 🎯 100%用戶模式運作：VAC沒有內核驅動，所有反作弊邏輯都在Ring 3完成，透過steamclient64.dll與deadlock.exe協同運作
  
• 🔐 DLL信任驗證機制：採用Windows Autdenticode完整流程，透過CryptCATAdminEnumCatalogFromHash比對.cat目錄檔，搭配WinVerifyTrust驗證簽章，任何未受信任或遭竄改的DLL都會被標記
  
• 🖥️ HWID硬體指紋系統：收集MAC位址（API + WMI雙管道）、硬碟序號（Win32_DiskDrive + Win32_PhysicalMedia）、BIOS/主機板序號、MachineGuid等，建立完整硬體叢集ID用於跨帳號關聯
  
• 🤖 VACnet機器學習：整合CS2相同的信任分數系統（SteamIDTrustBucket），透過GOTV/HLTV錄製完整的對戰數據進行事後分析，異常行為會觸發NETWORK_DISCONNECT_KICKED_VACNETABNORMALBEHAVIOR斷線
  
• ⚠️ 重要提醒：本文內容僅供資安研究與學術逆向分析參考，所有技術細節均來自合法取得的執行檔靜態分析，不涉及任何作弊工具開發或散佈

👉 GM後台版 遊戲 推薦 ⬇️⬇️⬇️ 快速玩各種二次元動漫手遊app

本文章目錄

• 前言介紹
  
• VAC架構深度心得
  
• DLL信任驗證機制
  
• HWID硬體指紋辨識
  
• VACnet機器學習檢測
  
• 核心模組整理
  
• 完整技術文件下載 🔽
  
• 常見問題Q&A

前言：Deadlock反作弊系統全整理

身為Valve最新推出的6v6競技射擊MOBA，《Deadlock》不僅承襲了《反恐精英2》的精緻槍感，更搭載了進化版的VAC（Valve Anti-Cheat）反作弊體系。許多玩家好奇：為什麼有些作弊程式很快被抓，有些卻能存活數週？為什麼換帳號還是會被連鎖封鎖？

這篇文章將帶你深入逆向工程團隊「DMA-runtime」釋出的完整技術文件，從steamclient64.dll到deadlock.exe，逐層心得VAC的運作原理。我們不會教你怎麼作弊，而是讓你瞭解遊戲公司如何保護競技環境，以及為什麼某些「硬體特徵」會讓你即使換帳號也無法逃離封鎖。

VAC架構深度心得：100%用戶模式運作

與許多現代反作弊系統（如Riot的Vanguard或騰訊的TenProtect）不同，Deadlock的VAC完全在用戶模式（Ring 3）運作，沒有載入任何內核驅動程式，也沒有單獨映射的模組。這個設計選擇讓VAC的檢測範圍受限於作業系統提供的API，但同時也降低了與系統驅動相容性問題的風險。

核心模組分工

• steamclient64.dll：負責通用的Steam反作弊層，包含已載入模組列表掃描（透過UserSystemInformation）、硬碟雜湊檢查（CClientJobSendSignatureCheck）以及HWID硬體識別碼收集
  
• client.dll：遊戲客戶端核心，負責呼叫deadlock.exe的5個匯出函數（BSecureAllowed、GetTotalFilesLoaded等），並透過CModuleListSnapshot列舉模組，最後封裝成CUserMessage_DllStatus訊息回傳伺服器
  
• deadlock.exe：實際的掃描器執行檔，包含完整的Windows Autdenticode驗證流程，透過CryptCAT與WinTrust API檢查DLL簽章狀態
  
• server.dll：專用伺服器端，完全沒有掃描能力，僅負責轉發客戶端的UM_RequestDllStatus報告到上游伺服器

檢測流程概覽

整個VAC的運作流程可以簡化為三個階段：

階段	執行位置	檢測內容
1. 初始化收集	steamclient64.dll	收集硬體ID、掃描已載入模組列表、檢查遊戲檔案雜湊
2. 即時驗證	deadlock.exe + client.dll	透過CryptCAT驗證每個載入DLL的數位簽章，檢查信任鏈完整性
3. 伺服器分析	VACnet / GC伺服器	接收客戶端遙測數據，透過機器學習模型分析異常行為模式

DLL信任驗證機制：CryptCAT與WinTrust完整流程

這次逆向分析中最重要的發現之一，就是Deadlock採用了Windows完整的Autdenticode驗證流程來檢查載入的DLL。這與Windows驗證驅動程式數位簽章的機制完全相同，代表VAC不僅檢查檔案是否被修改，更驗證其簽章是否來自受信任的憑證頒發機構（CA）。

完整API呼叫鏈

整個驗證流程涉及超過20個crypt32.dll與wintrust.dll的函數，全部透過動態整理（LoadLibrary + GetProcAddress）載入，因此靜態IAT中看不到這些匯入，這也是為什麼早期的分析報告遺漏了這個重要的檢測管道。

完整的函數呼叫順序如下：

CryptCATAdminCalcHashFromFileHandle2 → 對目標檔案計算SHA-256雜湊
↓
CryptCATAdminEnumCatalogFromHash → 在系統目錄中尋找匹配的.cat簽章目錄檔
↓
CryptCATCatalogInfoFromContext → 取得目錄檔的詳細資訊
↓
WinVerifyTrust → 最終驗證信任鏈完整性與憑證有效性

動態整理機制

在deadlock.exe的sub_7FF632897E90函數中，所有20個密碼學函數都透過以下方式動態載入：

• 首先呼叫LoadLibraryA載入crypt32.dll與wintrust.dll
• 透過GetProcAddress逐一取得函數位址
• 將函數指標儲存在全域陣列中供後續呼叫

這種設計有兩個目的：一是避免靜態分析工具直接看到匯入表，二是允許在不同Windows版本中彈性處理函數缺失的情況。

BSecureAllowed函數與安全狀態檢查

在deadlock.exe中，BSecureAllowed函數負責填充一個100KB的CVDiagnostic緩衝區，並回傳遊戲目前是否處於「安全狀態」。這個函數執行以下檢查：

• 檢查5個欄位狀態（包含模組載入計數、信任檢查完成數等）
• 驗證魔術版本標籤（state[+17] == 9）
• 計算綜合簽章值

一旦BSecureAllowed回傳0（不安全），這個標記會變成「黏性」狀態——即使後續檢查通過，客戶端仍會持續回報secure=false，直到遊戲重新啟動。

掃描器執行緒模型

DLL信任檢查採用多執行緒設計：

• 每個待檢查的項目會建立獨立工作者執行緒
• 主執行緒透過OpenThread + GetExitCodeThread輪詢檢查狀態
• 這種設計避免阻塞遊戲主迴圈，但增加了同步複雜度

信任驗證的實際限制

值得注意的是，這個信任驗證機制有一個根本限制：任何由Windows信任CA簽署的DLL都會通過驗證。系統不會區分「Valve簽署」和「其他信任CA簽署」的目錄檔。這意味著理論上，一個由合法CA簽署的作弊DLL在這層驗證中會被標記為「信任」。

HWID硬體指紋辨識系統深度整理

除了軟體層面的DLL驗證，Deadlock的VAC系統還建構了極其詳細的硬體指紋（HWID）收集機制。這個系統的目的是建立「硬體-帳號」關聯，即使玩家更換Steam帳號，只要使用同一臺電腦，系統仍能識別為同一位使用者。

硬體資訊收集範圍

steamclient64.dll中的SystemInfo RPC負責按需收集以下硬體識別碼：

• 網路介面資訊：透過API與WMI雙管道收集MAC位址，並過濾虛擬機器介面（檢查VirtualBox/VMware字串）
  
• 儲存裝置序號：查詢Win32_DiskDrive與Win32_PhysicalMedia取得硬碟序號
  
• 主機板與BIOS資訊：收集BIOS序號與主機板序號
  
• 系統識別碼：讀取HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid
  
• PCI裝置資訊：經過濾的網路介面卡GUID

HWID封裝與伺服器端關聯

所有收集到的硬體資訊會被封裝成三個主要識別碼：

• hardware_id：當前硬體的即時識別碼
• saved_hardware_id：已儲存的歷史硬體識別碼
• hardware_cluster_id：硬體叢集識別碼，用於關聯相似硬體配置

伺服器端維護著一個HWID與帳號的映射表。透過CAccountHardware_QueryAccountsRegisteredToSerial_Response這個RPC，系統可以查詢「綁定到特定硬體序號的所有Steam帳號」。這是Valve偵測小號（Alt Account）的核心機制。

HWID封鎖機制

除了傳統的VAC封鎖，Deadlock還存在獨立的HWID封鎖類別。在封鎖原因列舉中，「HWID Set」與「VAC beta」並列，代表即使帳號本身沒被VAC，硬體指紋也可能被單獨標記為不信任。

in-game VAC狀態檢查

遊戲內的IsVACBanned檢查並非在client.dll中直接執行，而是透過跨程序管道RPC呼叫steam.exe。真正的檢查在Steam客戶端程序中執行，遊戲只是接收結果。這種設計防止了記憶體修改工具直接篡改VAC狀態。

隱形威脅：手動映射DLL

值得注意的是，tier0.dll使用的CModuleListSnapshot並非使用傳統的K32EnumProcessModules，而是採用dbghelp!EnumerateLoadedModules64。然而，手動映射（Manual-map）並從PEB斷開連結的DLL對這兩種枚舉方式都不可見。這是目前VAC在用戶模式下的根本限制。

VACnet機器學習與伺服器端檢測機制

雖然客戶端DLL構成了VAC的前線防禦，但真正的檢測大腦位於伺服器端的VACnet系統。這是一個基於機器學習的行為分析引擎，透過分析玩家的操作數據來識別異常模式。

VACnet整合證據

在Deadlock的程式碼中，明確存在專屬於VACnet的斷線原因：NETWORK_DISCONNECT_KICKED_VACNETABNORMALBEHAVIOR。當Valve的機器學習系統在對戰中途標記玩家行為異常時，系統會立即斷開該玩家連線並顯示此原因。

已定罪帳號處理

對於已被VACnet或其他系統定罪的帳號，存在專屬的斷線原因NETWORK_DISCONNECT_KICKED_CONVICTEDACCOUNT。當這些帳號嘗試加入遊戲時，伺服器端閘道會直接拒絕，防止已知作弊者重新進入配對池。

SteamID信任分桶機制

Deadlock實作了與CS2相同的信任分數系統，相關變數命名為Source2PlayStats_SteamIDTrustBucket與SteamIDTrustBucketMin。玩家會根據歷史行為、帳號年齡、HWID關聯等因素被分配到不同的信任分桶，用於配對池的分隔，確保高信任度玩家不會與可疑帳號配對。

開發者即時封禁系統

程式碼中發現了分類化的開發者封禁相關控制變數：citadel_ban_account_aim_assist、_vision_assist、_movement_assist，以及對應的k_EMsgClientToGCDevBan RPC。這些標記為FCVAR_RELEASE（僅限開發者使用），允許Valve員工從即時分析工具直接發出封禁，並標記具體的作弊類別（瞄準輔助、視覺輔助、移動輔助）——這就是VAC-Live工作流程的實作。

GOTV與HLTV錄製基礎設施

Deadlock保留了完整的GOTV/HLTV錄製管線（CDemoSaveGame、CEngineGotvSyncPacket、CSVCMsg_HltvReplay等），與CS2的VAC-Live系統相同。這些錄製檔案會被用於賽後機器學習分析，讓VACnet能夠回顧檢視可疑玩家的完整操作軌跡。

遊戲內作弊投票與遙測

客戶端存在CCitadelPlayerController::ReportAsCheater與CCitadelUserMsg_CallCheaterVote功能，允許玩家在對戰中發起即時作弊投票。這些投票會計入cheater_report_score指標，與其他遙測數據一起傳送到遊戲協調器（GC）。

客戶端持續透過CMsgClientToGCAggregateMetrics發送單指標遙測，並由GC透過k_EMsgGCToClientAggregateMetricsBackoff進行節流控制。此外還有CMsgClientToGCRecordClientEvents事件日誌，以及GC主動發起的CMsgGCToClientPollFileRequest檔案雜湊輪詢。

核心模組功能整理與檢測盲點

理解每個DLL的具體分工，有助於理解VAC的能力邊界——也就是理論上「檢測不到什麼」。

steamclient64.dll：通用Steam層

這是VAC的基礎設施層，負責：

• 維護已載入模組列表（透過K32EnumProcessModules）
• 執行用戶系統資訊查詢（UserSystemInformation）
• 發送簽章檢查任務（CClientJobSendSignatureCheck）
• 收集硬體ID並打包成SystemInfo RPC

client.dll：遊戲客戶端中介

作為遊戲邏輯與反作弊掃描器之間的橋樑，client.dll：

• 呼叫deadlock.exe的5個匯出函數進行實際掃描
• 透過CModuleListSnapshot列舉模組（使用dbghelp!EnumerateLoadedModules64，而非K32EnumProcessModules）
• 封裝CUserMessage_DllStatus訊息，包含欄位8/21/22/23/24/25/29的計數與ID
• 回應伺服器發送的UM_RequestDllStatus請求

deadlock.exe：實際掃描引擎

這是VAC的核心掃描器，包含：

• 完整的CryptCAT/WinTrust驗證鏈（動態整理超過20個API函數）
• BSecureAllowed狀態檢查（100KB CVDiagnostic緩衝區）
• 5個匯出函數：BSecureAllowed、GetTotalFilesLoaded、CountFilesNeedTrustCheck、CountFilesCompletedTrustCheck、CountItemsToReport
• 多執行緒掃描架構（每個項目獨立工作者執行緒，主執行緒輪詢狀態）

tier0.dll：基礎工具函式庫

提供底層支援：

• CModuleListSnapshot類別（使用dbghelp!EnumerateLoadedModules64）
• Capture()函數用於模組快照
• 注意：手動映射且從PEB斷開連結的DLL對此枚舉方式同樣不可見

server.dll：被動接收端

重要發現：server.dll完全不具備掃描能力。它：

• 沒有BSecureAllowed函數
• 沒有CryptCAT或WinVerifyTrust相關字串
• 僅攜帶protobuf定義，用於向客戶端發送UM_RequestDllStatus並轉發回報到上游

檢測盲點總結

基於以上分析，以下活動對目前的用戶模式VAC完全不可見：

技術	原理	檢測難度
DMA攻擊	透過PCIe直接記憶體存取，完全繞過CPU執行的反作弊程式	目前完全無法檢測
PCILeech	利用DMA硬體讀取/寫入系統記憶體	無NtQuerySystemInformation探測
Kmbox等硬體模擬	在USB層模擬滑鼠/鍵盤訊號，作業系統層看不到差異	無IOCTL探測機制
漏洞驅動利用	透過有漏洞的合法驅動程式（如ASUS、Gigabyte驅動）在覈心層執行代碼	未實作反IOMMU檢查
手動映射DLL	將DLL手動載入記憶體並從PEB（Process Environment Block）斷開連結	K32EnumProcessModules與EnumerateLoadedModules64都無法看到
純記憶體修改	不修改磁碟上的遊戲檔案，僅在記憶體中修補代碼	檔案雜湊檢查無法發現
虛擬機器	在VMware/VirtualBox中執行遊戲	僅檢查VirtualBox/VMware字串以跳過VM網路卡，無CPUID/MSR/RDTSC檢查

完整技術文件與執行檔下載

本次分析的完整技術文件包含超過700行程式碼反組譯註解、虛擬位址（VA）參考、以及5個執行時期傾印的模組（steamclient64.dll、client.dll、deadlock.exe、tier0.dll、server.dll）。所有二進位檔案均已修復PE表頭，可直接在IDA Pro或Ghidra中載入分析。



所有站內附件皆會附上安全掃描報告
請會員查看純淨度百分比後判斷使用



相關檔案須知：
取得檔案前，請先詳細閱讀文章內容
避免不必要錯誤與誤會發生。
也可多參考文章討論樓層內容
了解附件檔案相關討論資訊。

【此文章部分內容隱藏中】    解除隱藏說明教學點擊下方 繼續閱讀文章 後
請仔細觀看文章內容 並依照指示進行下一步
最後完成解除隱藏後
系統會回到此文章自動顯示隱藏內容~

繼續閱讀

常見問題Q&A

Q：Deadlock的VAC會不會像Riot Vanguard那樣安裝內核驅動？

完全不會。根據這次逆向分析的結果，Deadlock的VAC是100%用戶模式（Ring 3）運作，沒有載入任何內核驅動程式，也沒有單獨映射的模組。所有的檢測邏輯都分佈在steamclient64.dll、client.dll和deadlock.exe中，透過Windows標準API執行。這與Riot的Vanguard（需要核心層驅動）或騰訊的TenProtect有著根本的架構差異。

Q：為什麼我已經換了Steam帳號，還是被標記或封鎖？

這就是HWID（硬體識別碼）系統在作用。Deadlock的VAC會收集你電腦的多個硬體特徵，包括：

• 網路卡的MAC位址（透過API和WMI雙重收集）
• 硬碟序號（查詢Win32_DiskDrive與Win32_PhysicalMedia）
• BIOS和主機板序號
• Windows的MachineGuid（儲存在登錄機碼中）
• PCI裝置的GUID

這些資訊會被雜湊打包成hardware_id、saved_hardware_id和hardware_cluster_id。Steam伺服器會維護「硬體序號→帳號列表」的映射表，當你使用新帳號登入時，系統會發現這臺電腦已經與被標記的帳號關聯，因此新帳號也會被標記為高風險或直接被視為小號（Alt Account）。

Q：什麼是「手動映射DLL」？為什麼VAC檢測不到？

手動映射（Manual-map）是一種進階的DLL注入技術，其流程如下：

• 使用自行撰寫的載入器（而非Windows的LoadLibrary API）將DLL內容手動映射到目標程序的記憶體空間
• 手動修復匯入表（Import Address Table）和重定位（Relocation）
• 執行DLL的入口點（Entry Point）
• 關鍵步驟：從PEB（Process Environment Block，程序環境區塊）的已載入模組列表中移除該DLL的記錄

VAC使用了兩種方式列舉已載入模組：

• K32EnumProcessModules（Windows標準API）
• dbghelp!EnumerateLoadedModules64（Debug Help Library）

這兩種方式都依賴PEB中的模組列表。一旦DLL從PEB斷開連結，這些枚舉函數就「看不見」這個DLL，因此VAC的「已載入模組列表掃描」和「DLL信任檢查」都會完全跳過這個手動映射的DLL。

Q：DLL信任驗證具體是怎麼運作的？為什麼有時候合法的修改會被標記？

Deadlock使用Windows完整的Autdenticode驗證流程，具體步驟如下：

1. CryptCATAdminCalcHashFromFileHandle2：對目標DLL檔案計算SHA-256雜湊值
2. CryptCATAdminEnumCatalogFromHash：在系統的Catalog Database中尋找匹配此雜湊的.cat目錄檔
3. CryptCATCatalogInfoFromContext：取得目錄檔的詳細資訊，包含簽章憑證鏈
4. WinVerifyTrust：最終驗證整個信任鏈的完整性，確認憑證未被撤銷且路徑有效

這個機制會檢查：

• 檔案內容是否與原始簽署時一致（任何位元組修改都會導致雜湊不符）
• 簽章憑證是否來自Windows信任的CA
• 憑證是否在有效期內且未被撤銷
• 信任鏈是否完整（中間憑證、根憑證都存在且有效）

常見的合法修改被標記情況：

• 使用自製修改（Mod）替換了遊戲DLL，即使功能無害，檔案雜湊也會改變
• 使用了未正確簽署的第三方DLL（例如某些螢幕錄影軟體或覆蓋層工具）
• 系統缺少必要的根憑證更新，導致WinVerifyTrust無法驗證某些較新的憑證鏈

Q：什麼是DMA攻擊？為什麼VAC對它完全無效？

DMA（Direct Memory Access，直接記憶體存取）攻擊是一種硬體層級的攻擊方式，使用專門的硬體裝置（如PCIe Screamer、M.2轉接卡、或Thunderbolt裝置）直接連接到目標電腦的PCIe匯流排。

運作原理：

• DMA裝置直接讀取/寫入系統實體記憶體，完全繞過CPU
• 作業系統和應用程式（包括VAC）在CPU上執行，無法察覺PCIe匯流排上的DMA傳輸
• 攻擊者可以在另一臺電腦上執行作弊程式，透過DMA裝置即時讀取遊戲記憶體（敵人位置、血量等），並模擬滑鼠輸入

為什麼VAC無法檢測：

• VAC沒有呼叫NtQuerySystemInformation(SystemModuleInformation)或EnumDeviceDrivers來列舉DMA裝置
• 沒有檢查IOMMU（Input-Output Memory Management Unit）狀態，這是防止DMA攻擊的硬體級保護機制
• 所有VAC程式碼都在Ring 3（用戶模式）執行，而DMA攻擊發生在硬體層級，完全在作業系統可見範圍之外

這是目前所有用戶模式反作弊系統（包括VAC、Easy Anti-Cheat的用戶模式部分）的根本限制。要檢測DMA攻擊，必須在覈心層級（Ring 0）執行驅動程式，監控PCIe裝置列舉和DMA映射操作。