《Marvel Rivals》NEProtect Lite 核心驅動逆向分析 技術研究 網易反作弊架構整理、驅動載入機制與通訊協定分析

《Marvel Rivals》NEProtect Lite 快速閱讀精華

• 🔍 六大核心組件整理：深入分析 NEProtect 核心驅動（NEProtect_Lite）與五個使用者模式 DLL（RoostX、libenvsdk、NtUniSdkProtocol、Pharos、NtUniSdkBase）的架構與互動關係
• 🛡️ 核心驅動機制：心得 ObRegisterCallbacks（物件回呼）、PsSetLoadImageNotifyRoutine（映像載入通知）、ZwQuerySystemInformation（系統資訊輪詢）以及 CI.dll 數位簽章驗證等關鍵功能
• 📡 通訊與遙測架構：揭露 NetEase 後端伺服器（pharos.*、protocol.*、tpsl.*、gsf.*、unisdk.*）的 HTTPS/HTTP2 通訊路徑，以及 Canary 遠端設定、DNS-over-HTTPS（DoH）與 Anycast 更新機制
• 🔧 驅動攔截與傾印技術：詳細記錄利用 %LOCALAPPDATA%\TempEPxxxxxx 暫存檔案的時間差競爭條件（Race Condition），實現驅動檔案攔截與傾印的方法
• 🧩 受保護程式碼區域：標記 .nep0、.cdata0、.cdata1 等尚未完全整理的受保護區段，總計約 10.9 MB 的加密或壓縮程式碼待進一步逆向分析

本文章目錄

• 前言與分析範圍
  
• NEProtect 核心驅動分析
  
• 驅動載入與攔截機制
  
• NtUniSdkRoostX 傳輸層
  
• libenvsdk 環境掃描器
  
• NtUniSdkProtocol 協定層
  
• Pharos 日誌與診斷
  
• NtUniSdkBase 基礎功能
  
• 整體架構總覽
  
• 實驗與驗證狀態
  
• 常見問題Q&A

前言與分析範圍

這篇文章整理了我對《Marvel Rivals》中 NetEase（網易）NEProtect Lite 反作弊系統的逆向工程分析。分析範圍涵蓋一個核心驅動程式（NEProtect_Lite）以及五個使用者模式 DLL（NtUniSdkRoostX.dll、libenvsdk.dll、NtUniSdkProtocol.dll、pharos.dll、NtUniSdkBase.dll）。

這些模組提供了從核心層次系統監控到使用者層次 HTTP 傳輸、環境掃描、日誌聚合等完整功能。需要特別注意的是，部分關鍵程式碼區域（特別是 .nep0、.cdata0、.cdata1 等區段）仍然處於加密或壓縮狀態，尚未完全整理。

NEProtect 核心驅動程式分析

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


核心驅動程式 NEPenk*.sys（NEProtect_Lite 版本）是整個反作弊架構的基礎層。以下分析基於靜態逆向工程與部分動態觀察。

PE 區段結構

驅動程式的區段分佈顯示了明顯的保護特徵：

區段名稱	大小	屬性	說明
.text	16 KB	RX	啟動 stub + 混淆控制流程
.rdata	7.5 KB	R	常數資料
.data	8 KB	RW	全域變數
.pdata	4 KB	R	SEH 異常資料
PAGE	12 KB	RX	分頁程式碼
INIT	4 KB	RX	DriverEntry + API 名稱字串表
.nep0	468 KB	RX	受保護區域（待整理）

.nep0 區段大小約為 .text 的 29 倍，強烈暗示這是加密或壓縮的主要保護載荷。

入口點與控制流程

DriverEntry 是標準的包裝器：

NTSTATUS DriverEntry(DRIVER_OBJECT* drv, UNICODE_STRING* reg) {
    __security_init_cookie();
    return sub_140001480(drv, reg);  // 跳轉至 .nep0
}

sub_140001480 包含嚴重的控制流程混淆，包含如下的不透明分支：

mov rdx, 0E0232F03A982FDB9h
sub edx, 83AE2916h
mov rdx, 3B2141305A246A93h
js  loc_1400014F9

這些序列包含旗標保存/恢復以及明顯的不透明分支，需要實際追蹤指令和旗標狀態，不能僅依賴反編譯器輸出。

匯入表與動態 API 整理

驅動程式大量使用 ntoskrnl.exe 的 API，部分透過靜態匯入，部分透過 MmGetSystemRoutineAddress 動態整理。

核心 API 清單包括：

• ObRegisterCallbacks / ObUnRegisterCallbacks（物件回呼註冊）
• PsSetLoadImageNotifyRoutine / PsRemoveLoadImageNotifyRoutine（映像載入通知）
• ZwQuerySystemInformation（系統資訊查詢）
• MmCopyMemory（記憶體複製）
• CiCheckSignedFile / CiValidateFileObject（程式碼完整性驗證）

六大核心功能區域

目前已識別的功能區域（非完整實現）：

1. 物件回呼與行程控制代碼過濾
透過 ObRegisterCallbacks 註冊 PsProcessType 的回呼。系統執行緒常式 sub_140002FF0 以約一秒間隔重試註冊。過濾路徑會移除 Marvel-Win64-Shipping.exe 相關控制代碼的 VM_READ、VM_WRITE、VM_OPERATION、PROCESS_CREATE_THREAD、PROCESS_DUP_HANDLE 和 PROCESS_SUSPEND_RESUME 權限。

2. 映像載入通知
透過 MmGetSystemRoutineAddress 動態整理 PsSetLoadImageNotifyRoutine。處理常式位於 .nep0 區段，本體尚未還原。預期的回呼簽章為 (PUNICODE_STRING FullImageName, HANDLE ProcessId, PIMAGE_INFO ImageInfo)。

3. 行程列舉
sub_1400021B0 呼叫 ZwQuerySystemInformation(SystemProcessInformation)，遍歷回傳項目並使用 PsLookupProcessByProcessId。路徑整理序列包含 PsReferenceProcessFilePointer 和透過 sub_1400025D4 的 IoQueryFileDosDeviceName。

結果路徑到達 .nep0 區段的 sub_140003264。運作中的解釋是雜湊或查詢階段，但轉換和比較資料仍未整理。輸出使用 272 位元組項目和 pool 標記 'PROL' (0x4C4F5250)。

4. 驅動程式/模組列舉
sub_14000BD78 使用 ZwQuerySystemInformation(SystemModuleInformation) 並配合緩衝區增長重試機制。筆記識別出包含 8 位元組基底位址或 272 位元組 RTL_PROCESS_MODULE_INFORMATION 項目的輸出形式。分配標記為 'AuxK' (0x4B787541)。

5. CI.dll 整理
sub_140002A34 列舉已載入模組，使用區分大小寫的 strstr 呼叫搜尋 "CI.dll"，並整理以下函式：

• CiCheckSignedFile（磁碟上的 Autdenticode 驗證）
• CiFreePolicyInfo（清理）
• CiValidateFileObject（已載入檔案物件的驗證）

同時設定 byte_140007A88 作為就緒旗標。相關的 pool 標記為 'CIFN' (0x4E464943)。這支援數位簽章驗證機制的存在，但確切的呼叫者和執行決策需要進一步追蹤才能描述完整策略。

6. 裝置物件安全性設定
sub_14000A2C0 透過 IoCreateDevice 建立裝置物件，透過 ObOpenObjectByPointer 取得控制代碼，並透過 ZwSetSecurityObject 套用安全性描述元。

建立與後續安全性更新之間的間隔值得調查。然而，僅憑該順序並不能證明任意行程可以完整存取開啟裝置。初始描述元、命名空間暴露、時間安排和產生的存取檢查都很重要。在描述允許哪些安全性主體之前，還需要解碼描述元。

驅動載入與攔截機制

這個章節說明如何攔截 NEProtect 驅動程式的載入過程，以便進行靜態分析。

暫存檔案載入序列

在分析的序列中，NEP 將驅動程式寫入 %LOCALAPPDATA%\TempEPxxxxxx，其中 "NEP" 後有六個可變字元。初始開啟請求 GENERIC_WRITE 並帶有 FILE_SHARE_READ，但不帶 FILE_SHARE_DELETE。控制代碼在稍後的 GENERIC_READ 開啟之前關閉。

這種關閉-重新開啟序列在暫存檔案不再被開啟時提供了移動或刪除該檔案的機會。在本機測試中，缺少檔案的條件導致重試，最終導致明顯的載入失敗。這些測試期間沒有觀察到立即踢除。這並不確定沒有日誌記錄、稍後執行或伺服器端回報。

傾印工具實作

傾印工具使用兩個並行的監視器：對 %TEMP% 的 ReadDirectoryChangesW 和對 C: 的 USN-journal 監視器。它對以 "NEP" 開頭的新增名稱做出反應，嘗試使用 MoveFileExW 移動到 desktopep_dumped\，並回退到 DeleteFileW。移動會保留樣本；刪除則不會。對於重新命名路徑，相同磁碟區的假設很重要。

筆記中的一個本機時間數字約為 140 微秒。如果沒有對開始和結束事件的精確定義、試驗次數和結果分佈，這應該被視為初步測量，而不是可重現的基準。

這在載入期間捕獲了驅動程式檔案；這不是已載入核心映像的傾印。傾印專案包含 source 和 build.bat，應該伴隨任何發布的重現套件。

NtUniSdkRoostX — HTTP 傳輸與設定層

RoostX 模組（NtUniSdkRoostX.dll，11.6 MB）是 NetEase SDK 的 HTTP 傳輸層，同時整合 Canary 用戶端功能。

建置路徑與符號資訊

建置路徑字串顯示了 CI/CD 流程：

C:\GitLab-Runner\builds\2LntixHHK\2\unisdk_pc\roosttUniSdkRoostX\src\...

此模組在 RTTI 和其他字串中暴露了大量可讀的類型/函式名稱資訊。這使得導航更容易，雖然這不等同於擁有完整的 C++ 符號表或恢復的呼叫圖。

核心類別與功能

記錄在筆記中的範例包括：

• NtUniSdkRoostX::Canary::CanaryControlImpl::registerSDK
• NtUniSdkRoostX::Canary::CanaryControlImpl::isFeatureEnabled
• NtUniSdkRoostX::Canary::CanaryControlImpl::buildCanaryConfigSnapshot
• NtUniSdkRoostX::Http::GlobalDoH::Resolve
• NtUniSdkRoostX::Http::AnycastUpdate::checkAndUpdate
• NtUniSdkRoostX::Http::SessionBase::SetUrl
• NtUniSdkRoostX::Http::SessionBase::SetBody

可見功能主要指向一般 HTTP/設定元件：

• GlobalDoH：DNS-over-HTTPS 支援
• AnycastUpdate：備援位址獲取、請求競速與快取端點選擇
• Canary：遠端功能設定功能
• SessionBase：請求設定、URL 處理與備援邏輯

模組包含 curl、OpenSSL 和 spdlog 相關功能。這識別了相依性，而非排除了周圍的自訂程式碼。

RoostX 匯出介面

Pharos 包含使用 LoadLibrary 和 GetProcAddress 進行 RoostX 動態載入的路徑。記錄的匯出介面清單包括：

RoostX_Session_CreateInstance / RoostX_Session_Destroy
RoostX_Session_SetUrl / RoostX_Session_SetTimeout
RoostX_Session_SetBody / RoostX_Session_SetParameters
RoostX_Session_SetFallback / RoostX_Session_SetDoh
RoostX_Response_GetStatusCode / RoostX_Response_GetText
RoostX_Response_GetHeader / RoostX_Response_GetElapsed
RoostX_Header_UpdateByData / RoostX_Header_Get
RoostX_GlobalConfig_SetProp

RoostX_Session_SetBody 是檢查使用此介面路徑上請求主體的實用邊界候選。它不應被描述為對所有遙測的通用可見性：其他元件具有網路功能，且在 TLS 之前提供的主體可能已經在應用層被編碼、壓縮或加密。

Canary 設定端點

https://cfg.cdn.unisdk.netease.com
https://cfg.cdn.unisdk.easebar.com

名稱 CANARY_CONFIG_FILE_PATH 也出現作為設定檔覆寫。它的存在值得記錄，但提供的檔案是否被接受、驗證、替換或在此建置中受限，需要單獨的行為測試。這並不確定可以透過環境變數停用任意安全功能。

libenvsdk — 受保護的環境相關功能

libenvsdk.dll（17 MB）是環境完整性掃描器，包含大量受保護的程式碼區域。

建置路徑與區段佈局

建置路徑字串：

F:\temp\EnvSDKv2A_r165439\

區段佈局記錄：

區段	大小	屬性	說明
.text	3.5 MB	RX	程式碼區域；角色尚未完全還原
.rdata	1.5 MB	R	常數資料
.data	60 KB	RW	全域變數
.pdata	156 KB	R	SEH 異常資料
.idata	12 KB	R	IAT（在傾印中被破壞）
.00cfg	4 KB	R	CFG 表
.cdata0	3.6 MB	RX	受保護/未整理區段 #1
.cdata1	980 KB	RX	受保護/未整理區段 #2
.idata（重複）	2 KB	RX	重複的 .idata，標記為可執行
.cdata1（另一個）	6.3 MB	RX	另一個 .cdata1，最大的區塊

值得進一步調查的特徵包括：

• 重複的區段名稱：.cdata1 和 .idata 各出現兩次
• 可執行的 .idata 區段
• 第一個 .cdata1 區段內的入口點
• .cdata 區段總計約 10.9 MB，相較於 .text 的 3.5 MB
• 檢查素材中極少可識別的純文字 API 名稱字串

這些共同支援調查封裝或其他保護。它們並不能唯一識別內部封裝器，排除商業保護，或證明 API 雜湊。傾印的匯入表條件也限制了從中可以推斷的內容。

可見功能（未整理區域外）

• re2：模組包含正則表達式相關功能。遠端可設定的比對規則是一種可能的用途，但單獨捆綁的正則表達式支援並不能確立伺服器推送的偵測管道或簽署的規則包。
• mbedTLS 和 curl：這些暗示了獨立於 RoostX 的網路功能。實際使用和請求路由仍有待追蹤。
• 類別名稱：envsdk::EnvSDKManagerPrivate 出現在類型相關素材中。其他可見名稱包括編譯器生成的 lambda 類型。
• 序號字串：這些是可能的識別碼收集線索，但其來源和使用仍未解決。
• GetTickCount64：這是與計時相關的線索，而非反偵錯的證明。確立該目的需要檢查回傳值如何影響控制流程。

實際的偵測邏輯仍然是一個重大缺口。在提出全面的掃描器描述之前，需要對受保護區域進行進一步分析。

NtUniSdkProtocol — 協議與 SDK 回報

NtUniSdkProtocol.dll（4.2 MB）負責使用者協議與 SDK 回報功能。

建置路徑與功能範圍

建置路徑字串：

D:\windowstUniSDK_unicode\tdird_party\temp\...

觀察到的內容表明「Protocol」在此指的是使用者協議，與中文術語「協議」一致，而非必然指網路協定實作。

參考端點

https://protocol.unisdk.netease.com/api/config_v2            主要設定 API
https://protocol.unisdk.easebar.com/api/config_v2            備份
https://protocol.unisdk.netease.com/api/template/v89/latest.json
https://protocol.unisdk.netease.com/tpsl/pc_class
https://tpsl.nie.netease.com/api/v1/class/upload
https://g0.gsf.netease.com/feature2                           GSF 功能旗標
https://whoami.nie.netease.com/v6                             身份回傳

直接查詢這些端點的響應：

• template/v89/latest.json 回傳使用者協議和隱私權政策內容，包含編輯者識別碼（lilijie、wshn0640）和版本控制資訊。
• config_v2 回傳區域/語言特定的協議路由，包含新加坡（SG）、香港（HK）、中國（CN）等地區的設定。
• tpsl/pc_class 回傳簡短清單：NtUniSdkEpic、NtUniSdkSteam、webview_support_helper，暗示第三方 SDK 清單回報（TPSL = Third-Party SDK List）。

Pharos — 日誌與診斷系統

Pharos.dll（1.3 MB）是日誌聚合與診斷功能模組。

建置路徑與核心功能

建置路徑字串：

D:\work\project\pharos\src\core\

Pharos 公開 PharosSetClientLogHook 和 PharosSetLogHook，包含遠端日誌、快取和診斷功能。它還有 RoostX 載入路徑。

候選的日誌流程（未驗證）：

Candidate libenvsdk logging patd (unverified)
  -> PharosSetClientLogHook captures
     -> pharos remote_logger batches
        -> RoostX_Session_SetBody (request-body boundary; encoding unresolved)
           -> HTTP + DoH + anycast
              -> pharos.netease.com

參考端點與診斷字串

https://pharos.netease.com                                      主要
https://pharos.easebar.com                                      備份
https://dual.pharos.netease.com                                 雙通道
https://dual.pharos.easebar.com                                 雙通道備份
https://sigma-pharosv3-patdn.proxima.nie.netease.com/v3         v3 端點
https://sigma-pharosv3-patdn.proxima.nie.easebar.com/v3         v3 API 備份

有趣的診斷字串：

PharosFW: rule '%s' missing and process not elevated; code=%d

這是規則/權限相關程式碼路徑的證據。組態金鑰 disable_roostx_log 建議控制 RoostX 日誌通道。

NtUniSdkBase — 基礎功能模組

NtUniSdkBase.dll（6.3 MB）是基礎功能模組，包含 HTTP、SQLCipher、Canary 執行階段等。

建置路徑與 HTTP 功能

建置路徑字串：

D:\windowstUniSDK_unicode\tdird_party\temp\...

nbase::Http 字串表示 libcurl 包裝器。記錄的選項名稱包括：

CURLOPT_URL, SSL_VERIFYPEER, POST, FOLLOWLOCATION, WRITEFUNCTION, WRITEDATA, TIMEOUT, HTTPHEADER, RESOLVE, IPRESOLVE, CAPATH, COPYPOSTFIELDS, WRITEHEADER

工作者類別

• NtUniSdkBaseImplWorker：通用作業執行者
• NtUniSdkBaseImplLogWorker：日誌批次處理 + 刷新
• NtUniSdkBaseImplDrpfWorker：未知 - "Drpf" 代號未公開
• NtUniSdkBaseImplClientLogWorker：用戶端日誌批次處理
• NtUniSdkBaseImplIOWorker：檔案 I/O（資料庫、設定、日誌檔案）

NtUniSdkBaseImplDrpfWorker 仍未整理。類別名稱是一個導航線索；發明 "Drpf" 的擴展不會確立其目的或將其連接到作弊遙測。

SQLite / SQLCipher 相關功能

字串 hexkey、hexrekey 和 rekey 建議支援加密的 SQLite 功能。筆記還包含這些 SQL 片段：

SELECT k, v FROM %Q.'%q_config'
REPLACE INTO %Q.'%q_config' VALUES(?,?)
DROP TABLE IF EXISTS %Q.'%q_data';
DROP TABLE IF EXISTS %Q.'%q_idx';
DROP TABLE IF EXISTS %Q.'%q_config';

可用的字串未確定哪些資料庫檔案被加密、此建置中是否啟用加密，或任何金鑰如何取得。特別是，尚未證明對裝置識別碼的依賴。

識別碼相關字串

unisdk_stable_udid_v1 建議在某個定義範圍內的穩定識別碼。其生成演算法、儲存、生命週期和與硬體的關係仍未整理。

潛在用途調查包括：

• 與伺服器端記錄的關聯
• 與本機持續性的關聯
• 跨日誌或 SDK 元件的關聯

這些是研究問題，而非已確認的用途。"Stable" 並未確立在作業系統重新安裝後仍然保留。還發現了 unisdkJfExtCid，其確切角色仍然開放。

核心/使用者模式通訊：仍未解決

最初預期在 Base 中找到直接的 NEP IOCTL 包裝器。搜尋約 31,000 個字串未識別出預期的 CODE-ENGINE 名稱、NEP 裝置路徑或明顯的包裝器。字串搜尋無法確定通訊路徑的缺失，特別是在多個模組和受保護區域之間。

目前已識別的機制：

區域	機制 / 目前觀察
核心	ObRegisterCallbacks 前置操作控制代碼過濾
核心	PsSetLoadImageNotifyRoutine 註冊
核心	ZwQuerySystemInformation 列舉
UM -> KM	Base 中未識別直接包裝器；不排除
KM -> 後端	獨立回報路徑尚未確立

物件回呼和映像通知是核心機制；列出它們並不證明與使用者模式程式碼的訊息通道。相反，在 Base 中未識別 IOCTL 包裝器並不能證明驅動程式是自主的，或兩者從不通訊。

也尚未確定核心驅動程式是否獨立向後端傳送回報。其本機執行與使用者模式回報之間的關係仍然是一個開放問題。

整體架構總覽

以下是六個組件的運作模型（非完整驗證的呼叫圖）。特別是使用者模式元件之間的路由，以及缺少本機核心通訊通道，仍然是開放問題。

                       NetEase 伺服器
                       pharos.* | protocol.* | tpsl.* | gsf.* | unisdk.*
                                        ^
                                        | HTTPS/HTTP2
          +--------+   +----------+   +----------+   +-----------+
          | RoostX |-->| Pharos   |-->| Protocol |   | libenvsdk |
          | HTTP   |   | log aggr |   | EULA +   |   | (PACKED)  |
          | +DoH   |   | +diag    |   | SDK list |   | scanner   |
          +--------+   +----------+   +----------+   +-----+-----+
               ^            ^              ^               |
               +------------+---->+--------+--------+<-----+
                                  | NtUniSdkBase    |
                                  | nbase::Http     |
                                  | SQLCipher       |
                                  | Canary runtime  |
                                  | stable_udid_v1  |
                                  +-----------------+

            [核心元件；通訊路徑未整理]
            +----------------------------------------------+
            | NEProtect 核心驅動程式 (NEPenk*.sys)       |
            |  - ObRegisterCallbacks (控制代碼剝離)        |
            |  - PsSetLoadImageNotifyRoutine (動態)      |
            |  - ZwQuerySystemInformation 輪詢           |
            |  - CI.dll 簽章驗證                         |
            +----------------------------------------------+

此處的範圍是六個組件：一個核心驅動程式和五個使用者模式 DLL。其中幾個 DLL 提供一般 SDK 功能而非專用的反作弊邏輯，因此將所有五個稱為「反作弊」過於寬泛。

實驗與驗證狀態

早期的草稿將幾個想法評為可行的繞過方法。這誇大了證據。以下區分在於本機觀察與仍需驗證的想法之間，而非保證停用堆疊的方法排名。

核心端項目

• 暫存檔案競爭：在本機設定中觀察到驅動程式載入序列的成功攔截/幹擾。可重現性、稍後執行和跨建置行為仍有待記錄。
• 手動對應：不是完整堆疊繞過的證明。避開一個載入或通知路徑並不能確立對其他機制的不可見性。
• 物件回呼取消註冊：RegistrationHandle 是分析地標。筆記未確立完整、穩定的繞過或缺少後續完整性檢查。
• 前置操作回呼修改：相關的受保護回呼實作和後果尚未完全驗證。這仍然是修改假設而非已證明的結果。
• 已載入模組與相關狀態操作：原始筆記提及 PsLoadedModuleList、PiDDBCacheEntry 和「MMU」。這些參考不是此樣本的已證明隱藏方法，且「MMU」縮寫需要澄清。
• CI 函式指標修改：找到 CiValidateFileObject 相關狀態並不能證明變更它會停用所有簽章執行。相關的呼叫路徑和產生的行為仍有待驗證。

使用者模式項目

• RoostX_Session_SetBody 觀察：檢查 RoostX 請求路徑上主體的實用候選。覆蓋範圍和應用層編碼仍有待測量。
• nbase::Http 觀察：單獨的候選請求邊界。不應假設它能在沒有驗證呼叫路徑的情況下捕獲 libenvsdk 的獨立網路。
• 網路封鎖：封鎖已知端點是連通性實驗，而非證明回報被消除或遊戲隨時間保持不受影響。備援、排隊上傳和稍後執行仍然是相關的未知數。
• JF_CLIENT_LOG_URL 覆寫：需要確認其有效範圍和接受度的設定線索。
• Canary 快取變更：canary.conf 的行為、快取驗證和伺服器故障處理尚未充分確立，無法聲稱本機提供的設定停用偵測。
• RoostX 替換/代理：原始提案假設了尚未證明的介面相容性、模組接受度和傳輸覆蓋範圍。
• libenvsdk 移除/替換：啟動行為、相依性檢查和執行後果仍然未知。這不是已證明的在保持正常操作同時停用掃描器的方法。
• 本機資料庫變更：原始提案依賴未證明的資料庫架構、金鑰衍生和設定消耗路徑。與 unisdk_stable_udid_v1、upload_log 和 disable_roostx_log 的關係必須在得出結論之前確立。

伺服器端行為

客戶端分析並不確定伺服器端偵測如何運作或是否使用特定的行為訊號。這裡沒有關於其閾值或相對重要性的證據。關於使自動化行為看起來像人類的較早建議是推測性的，不屬於發現部分。

以下廣告滑動後還有帖子內容

常見問題Q&A

Q：NEProtect Lite 與其他反作弊系統（如 EAC、BattlEye）相比強度如何？
目前由於受保護程式碼區域尚未完全整理，無法為 NEProtect Lite 對比其他商業反作弊系統分配有意義的功能完成度百分比。這需要定義標準並收集可比較的證據。

Q：是否可以完全繞過 NEProtect 的保護？
目前觀察到的「繞過」方法（如暫存檔案競爭、物件回呼取消註冊等）均為本機實驗觀察，其可重現性、跨建置穩定性以及伺服器端回報機制仍需進一步驗證。目前沒有已證明的完整堆疊繞過方法。

Q：libenvsdk.dll 中的 .cdata0/.cdata1 區段包含什麼？
這些區段總計約 10.9 MB，標記為 RX（可執行唯讀），入口點位於第一個 .cdata1 區段內。目前推測這些是加密或壓縮的受保護程式碼，但具體的偵測邏輯和保護機制（是否為自製封裝器或商業保護）仍有待進一步逆向分析。

Q：Pharos 系統會收集哪些類型的資料？
Pharos 包含用戶端日誌鉤子（PharosSetClientLogHook）、遠端日誌批次處理、網路延遲測量（pharos_netlag_impl.cpp）和診斷探針執行器。具體收集的資料類型和觸發條件需要追蹤實際的呼叫路徑才能確定，目前僅從字串分析無法確切得知。

Q：Canary 系統的功能是什麼？
Canary 是 NetEase 的遠端功能設定系統，支援從 cfg.cdn.unisdk.netease.com 等端點獲取設定快照，並在本地快取（canary.conf）。這允許 NetEase 動態啟用或停用特定功能（包括安全相關行為），但具體哪些旗標控制安全相關行為尚未確立。

Q：分析中提到的「MMU」是什麼意思？
原始筆記中提及 PsLoadedModuleList、PiDDBCacheEntry 和「MMU」，但「MMU」縮寫需要澄清。這可能指的是記憶體管理單元（Memory Management Unit）相關的操作，或是特定的反作弊術語，但目前尚未有明確定義。