《EasyAntiCheat》EAC_EOS 核心機制深度拆解 執行階段分析、偵測機制、API混淆技術全解析

《EasyAntiCheat》EAC_EOS 核心機制 快速閱讀精華

• 🔑 核心發現： 別人的分析筆記別照單全收！EAC 會發布多種不同版本，各版本的加密參數、檔案大小和雜湊值都可能不同。
• 🔬 API 混淆技術： 證實採用了高竿的 RSA-style 解析器與雙模數系統來隱藏對 Windows 核心 API 的呼叫，大幅增加逆向工程的難度。
• 🛡️ 五大偵測機制揭密：
  
  • 記憶體掃描： 直接對記憶體分頁進行掃描，而非透過標準 API，讓簡單的 Hook 失效。
  • 頁表遍歷 (Page Table Walking)： 這是大絕招！直接讀取處理器的 CR3 暫存器來走訪分頁表，能抓到任何試圖透過竄改 API 來隱藏的記憶體。
  • 模組雜湊驗證： 透過 SHA-1 演算法檢查自身驅動程式的程式碼區段，任何未經授權的修改或 Patch 都會立刻被發現。
  • 加密黑名單： 內建多張經過不同演算法加密的黑名單，內容並非簡單的檔名，更可能是已知外掛工具的PE特徵碼或程式指紋。
  • 嵌入式檔案偵測： 會掃描記憶體中是否有 PNG 圖檔或嵌入式檔案系統的蹤跡，專門用來打擊實現遊戲內透視的「覆蓋型」外掛。
    
• 💥 高風險行為： 修改驅動程式碼、記憶體中存在可疑檔案（如PNG）、試圖隱藏記憶體、或將程式碼區段設為可寫入，都可能導致立即被標記。
• 📦 執行時虛擬化： EAC 驅動在執行時，其虛擬化區段會從靜態的 21MB 膨脹到 35MB，這代表有大量的程式碼在執行期才解開，增加了靜態分析的難度。
  

本文章目錄

• 前言：從靜態到動態，揭開 EAC_EOS 的神秘面紗
• 版本差異：為何你的分析結果可能不同？
• API 混淆技術驗證
• 深入挖掘：EAC 的核心偵測機制
• - 記憶體掃描 (Memory Scanning)
• - 頁表遍歷 (Page Table Walking)
• - 模組雜湊驗證 (Module Hash Verification)
• - 區段權限驗證 (Section Permission Validation)
• - 加密黑名單 (Path/String Blacklist)
• - 嵌入式檔案偵測 (Embedded File Detection)
• - 程序上下文提取 (Process Context Extraction)
• 一踩就爆！哪些行為會讓你被系統標記？
• 其他發現與待辦事項
• 總結：EAC_EOS 運行時分析重點回顧
• EAC_EOS 驅動程式 Dump 檔案下載 🔽
• EAC_EOS 逆向工程常見問題 Q&A

前言：從靜態到動態，揭開 EAC_EOS 的神秘面紗

各位專注於遊戲安全與逆向工程的朋友們，大家好！
這篇文章是我們之前對 EasyAntiCheat (EAC) EOS 驅動程式進行靜態分析的後續研究。這次，我們將更進一步，直接從核心記憶體中將執行中的驅動程式 Dump 出來，深入剖析它在「執行階段 (Runtime)」的真實行為。

我們的目標是揭露 EAC 在實際運作時所採用的各種偵測機制，特別是一些在靜態分析中難以完全確認的技術。

重要提醒

• 本篇文章內容僅供技術研究與學術探討之用，嚴禁使用於任何非法或破壞遊戲公平性的行為。
• 逆向工程反作弊系統涉及高深的技術知識與潛在風險，操作不當可能導致系統不穩定或帳號被封鎖。
• 內容高度專業，適合具備作業系統核心、組合語言及逆向工程基礎知識的開發者與研究人員閱讀。
  

在開始之前，有一點非常重要：我們這次分析的執行期 Dump 檔，與先前靜態分析的檔案並非同一個版本。它們的雜湊值、檔案大小（38MB vs 23MB）甚至是加密參數都有所不同。這也證實了 EAC 會部署多種變體版本，所以大家在參考分析時，務必確認自己面對的是哪個版本。

版本差異：為何你的分析結果可能不同？

首先我們來看看執行階段的 Dump 檔跟靜態檔有什麼具體差異。最明顯的就是大小，執行時的 Dump 檔大了非常多：

靜態檔案： 23.3 MB, SHA256: 7e7f9cfd...
執行期檔案： 38.4 MB, SHA256: 26da7d4b...

多出來的這將近 15MB，主要是因為它那巨大的「虛擬化區段」在執行時被解開了。原本靜態時佔 21MB 的虛擬化區段，載入到記憶體後直接膨脹到 35MB。這意味著有大量的程式碼是被高度保護，只有在執行時才會現出原形。


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



更關鍵的是，用於 API 解析的硬編碼模數 (Modulus) 也完全不同：

靜態檔案模數： 0x199F07D3B49761CB
執行期檔案模數： 0x8123AD9AFB36519

【小知識】這個模數就像一把解密的鑰匙。如果你拿著 A 版本的鑰匙，想去開 B 版本的鎖，那肯定是行不通的。這再次提醒我們，逆向 EAC 時，不能盲目套用網路上的固定數值。

API 混淆技術驗證

我們在靜態分析中提到的 RSA-style API 解析器，在這次的執行期分析中得到了完全證實。它的運作模式，簡單來說就是透過一套複雜的數學運算（模冪運算）來動態計算出所需 Windows API 的位址，而不是直接寫在程式碼裡。

這套系統仍然使用指數 17，並維持著雙模數的設計。我們找到了超過 200 個呼叫這個解析器的地方。在解析出真正的 API 位址後，還會再套用一次靜態分析中發現的 ROR/XOR 模式來做最後的解密。

底下是其他研究者協助提供的部分 API 導入表，可以清楚看到 EAC 呼叫了哪些核心層級的 Windows 系統功能：

EACOffset: 0x1FC660, Module: ntoskrnl.exe, Import: PsIsThreadTerminating
EACOffset: 0x1FC380, Module: ntoskrnl.exe, Import: PsGetProcessCreateTimeQuadPart
EACOffset: 0x1FC350, Module: ntoskrnl.exe, Import: PsReferenceProcessFilePointer
EACOffset: 0x1FC340, Module: ntoskrnl.exe, Import: ObCloseHandle
EACOffset: 0x1FC330, Module: ntoskrnl.exe, Import: NtSetInformationProcess
EACOffset: 0x1FC320, Module: ntoskrnl.exe, Import: PsGetProcessExitProcessCalled
EACOffset: 0x1FC310, Module: ntoskrnl.exe, Import: SeCaptureSubjectContext
... (由於清單過長，此處省略部分內容以維持版面整潔)
EACOffset: 0x1FB810, Module: ntoskrnl.exe, Import: ExAcquireSpinLockExclusive
EACOffset: 0x1FB800, Module: ntoskrnl.exe, Import: ObOpenObjectByName

從這份清單可以看出，EAC 深入系統底層，監控著程序、執行緒、檔案、記憶體等各種操作，其監控範圍相當廣泛。

深入挖掘：EAC 的核心偵測機制

接下來是重頭戲，我們在執行期 Dump 中發現了好幾套協同運作的偵測系統。

記憶體掃描 (Memory Scanning)

EAC 內建一個逐頁（Page-by-page）的記憶體掃描器。它的特別之處在於，它會先透過 MmIsAddressValid 函數來驗證記憶體位址是否有效，如果有效，再將實體分頁映射進來進行掃描。這種做法比直接讀取虛擬記憶體更底層，能繞過一些簡單的 API Hook。

頁表遍歷 (Page Table Walking)

這部分就非常有趣了。EAC 為了防止更高明的作弊手段（例如透過竄改分頁表來隱藏記憶體），它索性完全繞過了 Windows 的標準 API，直接從處理器的 CR3 暫存器 開始，手動去遍歷整個分頁表結構（PML4 -> PDPT -> PD -> PT）。

【小知識】這就像是警察辦案，不透過大樓管理員（作業系統 API）去詢問住戶資訊，而是直接拿到最原始的住戶登記總表（分頁表）來逐一核對。如果登記總表上顯示某個房間有人，但管理員卻說沒有，那這個房間肯定有問題！這種方式可以揪出任何試圖對作業系統撒謊、隱藏起來的記憶體區塊。

模組雜湊驗證 (Module Hash Verification)

為了確保自身的完整性，EAC 會對自己驅動程式內部的程式碼區段（Code sections）進行 SHA-1 雜湊運算。它內部儲存了一份正確的雜湊值，並在執行時進行比對。

這意味著，任何試圖直接修改 EAC 驅動程式檔案、在記憶體中對其進行 Patch 或 Hook 的行為，都會導致雜湊值不匹配，進而被立刻發現。

區段權限驗證 (Section Permission Validation)

EAC 會解析 PE 標頭來檢查各個區段的特性。以下行為會被標記為異常：

• 可寫的程式碼區段 (.text)： 正常情況下，程式碼區段應是唯讀的，設為可寫入通常是為了 Hook。
• 可執行的資料區段： 資料區段不應該有執行權限，這通常是 Shellcode 注入的特徵。
• 缺少或被修改過的區段標頭。
  

加密黑名單 (Path/String Blacklist)

我們發現了多個經過加密的黑名單資料表，而且每一張表都用了不同的加密演算法，解密後還會被清空，相當狡猾。

在我們解開了五組加密模式後，發現內容並非人類可讀的檔案路徑或字串，而是一堆看似亂碼的二進位資料。我們的推測是，這並不是傳統意義上的檔名黑名單，而是已知作弊工具的 PE 標頭特徵、程式碼指紋或嵌入式浮水印。EAC 透過比對這些二進位特徵來識別已知的作弊程式。

嵌入式檔案偵測 (Embedded File Detection)

這是一個很有意思的偵測點。EAC 會掃描記憶體，尋找特定檔案的「魔法數字 (Magic Number)」，特別是：

• PNG 圖片檔案的特徵碼。
• FAT 或其他磁區結構的特徵。
  

我們猜測，這主要是為了打擊那些將圖示、介面等資源直接嵌入到記憶體中的「覆蓋型 (Overlay)」外掛。

程序上下文提取 (Process Context Extraction)

EAC 具備附加（Attach）到特定程序的能力，透過 KeStackAttachProcess 進入該程序的上下文環境，以提取詳細資訊。這讓它能夠從目標程序的視角來檢查其內部狀態，進行更深入的分析。

一踩就爆！哪些行為會讓你被系統標記？

根據上述的偵測機制，我們整理出哪些行為最可能讓你被 EAC 盯上：

立即被偵測的行為：

• 檔案路徑或名稱符合黑名單中的特徵。
• 驅動程式的程式碼雜湊值不匹配（表示被 Patch 或 Hook）。
• 程序記憶體中被發現嵌入了 PNG 檔案或其他可疑檔案結構。
• 存在「隱藏記憶體」（即頁表遍歷結果與 API 回報不一致）。
• 程式碼區段被設為可寫入，或資料區段被設為可執行。
  

被視為可疑並記錄的行為：

• 使用非標準的 PE 區段名稱。
• 出現不尋常的程序上下文模式。
• 偵測到跨程序的記憶體存取行為。
• 存取敏感的登錄機碼 (Registry keys)。
  

請注意，這只是我們目前分析出的一部分，EAC 的偵測網路遠比這更複雜。

其他發現與待辦事項

在分析過程中，我們也發現 EAC 整合了 Windows 的 WinTrust 功能，這表示它會驗證驅動程式或程序的 Authenticode 數位簽章。

不過，仍有幾個部分我們尚未完全摸透：

• 物件回呼 (Object callbacks) 的具體實作。
• 迷你過濾驅動 (Minifilter) 到底過濾了哪些 IRPs。
• 核心層與使用者層之間的 IPC 通訊機制。
• 遙測 (Telemetry) 回傳的資料封包確切格式。
  

這些都需要透過更深入的動態偵錯或完整的驅動程式模擬來進一步研究。

總結：EAC_EOS 運行時分析重點回顧

• 多版本策略： 不同遊戲、不同時期的 EAC 版本，其加密參數可能完全不同，分析時切勿刻舟求劍。
• 頁表遍歷是王牌： 這是 EAC 對抗記憶體隱藏技術的殺手鐧，傳統的 API Hook 在它面前無所遁形。
• 完整性自我檢查： 透過 SHA-1 雜湊驗證，確保自身驅動程式未被竄改。
• 黑名單進化： 不再是簡單的字串比對，而是採用多層加密的二進位特徵碼比對，偵測更精準。
• 虛擬化技術： 大量程式碼被虛擬化，執行時才在記憶體中展開，對靜態分析造成極大阻礙。
  

總體來說，EAC_EOS 是一個設計精良、防護層層堆疊的反作弊系統，其工程師在混淆與偵測技術上確實投入了大量心血。

EAC_EOS 驅動程式 Dump 檔案下載 🔽

我們在此提供本次分析所使用的執行期 Dump 檔案，供有興趣的研究者下載。請注意，此檔案僅供學習與研究用途。

點此下載 EasyAntiCheat_EOS.zip 檔案

EAC_EOS 逆向工程常見問題 Q&A

• Q：為什麼我按照網路上的教學分析 EAC，但數值或位址都對不上？
  A：因為 EAC 會針對不同遊戲或時間點發布不同編譯版本。本篇分析也證實了，不同版本的驅動程式，其內部加密參數、雜湊值和檔案大小都可能不同。你必須針對你當前分析的版本進行獨立研究，不能直接套用舊資料。
  
• Q：EAC 真的能偵測到我用特殊手法隱藏的記憶體嗎？
  A：是的，機率很高。EAC 使用了「頁表遍歷 (Page Table Walking)」技術，它不依賴 Windows API，而是直接讀取 CPU 的 CR3 暫存器來走訪實體記憶體分頁表。任何在分頁表層級可見，卻被 API 層級隱藏的記憶體，都會被視為異常。
  
• Q：EAC 的黑名單只是簡單的檔名或路徑列表嗎？
  A：根據我們的分析，並非如此。它的黑名單是經過多重不同演算法加密的，解密後得到的並非可讀字串，而是二進位數據。我們推測這更可能是已知外掛的 PE 標頭特徵碼或程式碼指紋，比單純的檔名比對要高明得多。
  
• Q：為什麼 EAC 要掃描記憶體中的 PNG 圖片檔？
  A：這很可能是為了打擊「覆蓋型 (Overlay)」外掛。這類外掛會將自己的介面、準心、透視圖等圖形元素（通常是 PNG 格式）直接繪製在遊戲畫面上方。偵測到記憶體中有異常的 PNG 檔案，就可能是這類外掛存在的跡象。
  
• Q：我可以直接用工具 Patch EAC 驅動程式的記憶體來繞過偵測嗎？
  A：基本上行不通。EAC 會對自身的程式碼區段進行 SHA-1 雜湊驗證。一旦你修改了它的任何一個位元組，雜湊值就會改變，EAC 在自我檢查時會立刻發現並觸發反作弊機制。
  
• Q：分析 EAC 最大的挑戰是什麼？
  A：最大的挑戰在於其大量的「虛擬化 (Virtualization)」程式碼。許多核心邏輯被包裹在一個虛擬機中執行，你在靜態分析時看到的只是一堆無法理解的位元組碼。必須透過動態分析、偵錯或模擬執行，才能逐步還原其真實的行為邏輯。