反作弊对抗分析（EAC / BattlEye / 内存校验）

何时使用 / 何时不用

• 用：分析反作弊组件（EAC / BattlEye / Vanguard 等）的驱动与服务、检测机制如何工作
• 用：游戏进程被反作弊拒绝/踢出后，理解"检测到了什么"（防御与研读视角）
• 用：反作弊驱动的静态逆向（DriverEntry、IRP、内存校验逻辑）与内核调试观察
• 不用：制作或分发作弊程序 / 在真实游戏环境实施绕过（明确禁止，见授权边界）
• 不用：只是游戏自身逻辑（内存修改、CE）→ [[re-game]]
• 不用：普通驱动分析（[[re-kernel]]）；用户态反调试（[[re-evasion]]）
• 授权边界（必读）：本技能仅限授权研究——自有设备、自有游戏账号、实验室环境、已获书面许可的安全研究。禁止：制作/分发作弊软件、在在线游戏中使用绕过手段获取不当优势、将检测机制分析用于破坏。所有动态实验在隔离沙箱（[[re-analyze/platform-tips]] 最高原则）内进行；分析结论以防御与研究视角产出（理解检测面 → 改进检测），不产出可操作的绕过工具。

工具准备

反作弊分析=驱动逆向 + 内核调试，全程隔离沙箱（[[re-analyze/platform-tips]] 最高原则）。所有工具先验证再使用。

驱动分析底座（[[re-kernel]]）

• 驱动静态：DriverEntry / IRP 分派 / 回调还原方法见 [[re-kernel]]「操作步骤」
• 反编译：[[re-ghidra]]（默认，导入 .sys 后 Data Type Manager 载入内核类型）
• 验证: 导入 EAC/BE 驱动 .sys 后 DriverEntry 能反编译

内核调试（[[re-windbg]]）

• 双机/VM 串口（COM Named Pipe）或 KDNET 配置见 [[re-windbg]]「工具准备」
• 内核调试是分析反作弊驱动的唯一动态手段（用户态 attach 被驱动拒绝，见坑 1）
• 验证: 内核会话 lm 能看到目标反作弊驱动模块，.reload /f <驱动名> 加载符号

用户态快速定位（[[re-x64dbg]] / [[re-windbg]]）

• [[re-x64dbg]]：受保护进程之外的辅助组件（加载器、服务端）快速查看
• 受保护进程（PPL）直接 attach 不可行——理解 PPL 保护是环境认知的一部分（见坑 1）
• 验证: x64dbg 能打开普通目标 exe

系统工具（服务/驱动枚举）

• Windows 内置：sc query / driverquery / fltmc（文件系统过滤驱动列表）
• Sysinternals（微软官网）: Process Explorer（process explorer 查看受保护进程标记）、Sysmon
• 验证: driverquery 输出驱动列表；sc query EasyAntiCheat（EAC 服务名按版本变化）

操作步骤

按顺序执行，每步产物（组件清单、IRP 表、校验逻辑笔记）记录证据路径 + sha256（见 [[re-triage]]），供报告引用。所有步骤在授权范围与沙箱内进行（授权边界见「何时使用」）。

1. 反作弊组件识别（驱动 / 服务）：

   driverquery /v | findstr /i "anti cheat easy battle"     # 驱动层组件
   sc query | findstr /i "anti cheat easy battle vanguard"  # 服务层组件
   fltmc                                                    # 文件系统过滤驱动（完整性校验常在此）
   

   • 典型组件：EAC（EasyAntiCheat.sys + 用户态加载器）、BE（BEDaisy.sys + 用户态服务）、Vanguard（vgk.sys 驱动 + 常驻服务）；各厂商还有更新服务/反篡改守护
   • 记录：组件清单（驱动名/服务名/安装路径）+ 驱动文件 sha256（版本锚点，见坑 3）+ 自保护状态（PPL 等）

2. 驱动校验分析（内存扫描 / 完整性）：

   • 静态还原（[[re-kernel]] 方法）：DriverEntry → IRP 分发表（IRP_MJ_DEVICE_CONTROL 等）→ 用户态 IOCTL 交互界面；重点找：
     • 完整性校验：定时/触发式校验游戏进程代码段与数据段哈希（MmCopyVirtualMemory/KeStackAttachProcess 类读取目标进程内存后计算）
     • 内存扫描：按特征扫描游戏进程内存（寻找修改后的代码/注入模块）
     • 回调注册：PsSetCreateProcessNotifyRoutine（监控进程创建）、PsSetLoadImageNotifyRoutine（监控模块加载）——校验逻辑的触发入口
   • 用户态组件：加载器与服务（[[re-binary-core]] 反编译）——心跳、报告通道、更新检查
   • 产物：检测机制清单（触发点 → 校验内容 → 处置动作）

3. 检测规避思路（授权范围内研究）：

   • 研究"检测机制如何工作"（防御视角），组织方式：检测面清单（完整性校验 / 内存特征 / 行为时序 / 驱动层监控）
   • 每个检测面的分析产出：检测条件、触发频率、报告通道（谁收到告警、什么格式）
   • 不实施：在真实游戏环境中的规避、绕过工具开发、外挂分发——超出授权边界（坑 2）
   • 分析用途建议：检测改进（给厂商/防御侧）、规则编写（[[re-ioc]] 思路：驱动特征、行为模式）

4. 内核对抗（[[re-kernel]] 联动）：

   • 内核调试会话（[[re-windbg]]）：断点打在回调函数 / 校验函数上观察触发时机与参数
   • 反作弊驱动对调试器的反制：检测调试端口 / 清调试寄存器（!dr）/ 蓝屏诱饵——分析时记录反制手段（防御视角的"检测面"组成部分），应对一律在沙箱 + 快照（[[re-analyze/platform-tips]] 最高原则）
   • 蓝屏风险：所有断点/触发实验在调试 VM 内做，操作前打快照（[[re-kernel]] 坑 4）
   • 产物：调试会话记录 + 反制手段清单

5. 分析报告（合规边界）：

   • 报告结构：授权范围声明 → 组件清单（版本/哈希）→ 检测机制（触发点/内容/动作）→ 反制手段 → 防御建议
   • 合规要点：报告标注授权环境与用途；不包含可操作的绕过步骤；不发布驱动密钥/签名材料；敏感结论走负责任披露（厂商安全团队/漏洞奖励）
   • 产物：报告存档（sha256）

跨域联合

• [[re-kernel]]：驱动逆向方法论底座（DriverEntry / IRP / 回调）+ 内核调试配合——本技能固定依赖
• [[re-windbg]]：内核调试会话、!analyze -v、断点与现场恢复（唯一可用的动态手段）
• [[re-x64dbg]]：用户态辅助组件（加载器/服务）快速定位
• [[re-game]]：游戏侧内存修改 / CE 思路——检测机制的"被检测对象"，对照理解
• [[re-evasion]]：用户态反调试 / 反分析对抗框架（与驱动层反制对照）
• [[re-ioc]]：检测特征 → YARA 规则 / 行为模式产出（防御视角）
• [[re-sandbox]] / [[re-analyze/platform-tips]]：隔离沙箱 + 快照最高原则（蓝屏与样本风险）

常见坑与陷阱

• 驱动级检测不可 attach（需内核调试）：现象——x64dbg/WinDbg 用户态 attach 游戏进程被拒绝（"无法附加"）或附加后进程立即退出/蓝屏；原因——反作弊驱动用 PPL（Protected Process Light）保护游戏与自身进程，普通用户态调试器权限不足；驱动层还会检测调试器活动（调试端口、调试寄存器、NtQueryInformationProcess 调试状态）；对策——用户态 attach 不是分析路径，直接搭内核调试（双机/VM，[[re-windbg]]），目标在 VM 内、调试器在宿主；断点下在内核函数（回调/校验）而非游戏进程内；一切在沙箱 + 快照内（蓝屏即回滚）
• 法律边界（仅研究授权环境）：现象——分析被用于制作外挂 / 在线作弊 / 出售绕过工具，触发法律与游戏厂商反制（封禁、诉讼）；原因——反作弊分析天然接近作弊技术，绕过手段在真实游戏环境使用即侵权/违约；对策——严格限定授权范围（自有设备、自有账号、书面许可的实验室）；报告只做防御向（检测机制如何工作、如何改进检测）；不发布可操作工具、不公开驱动敏感材料；以"理解检测面"为边界，不以"绕过成功"为产出
• 反作弊更新频繁（结论过期）：现象——上周分析出的函数地址/偏移/检测点全部失效，报告结论"过时"；原因——EAC/BE 数天一个版本，驱动加壳/混淆与结构变动频繁；对策——分析必须锚定版本：记录驱动 sha256、文件版本号、分析时间（步骤 1）；报告注明版本与日期；分析方法（IRP 还原、回调枚举、IOCTL 解码）跨版本复用，具体地址/偏移不跨版本复用
• 绕过技术对抗升级（分析方向错位）：现象——分析出的"弱点"很快被修复或触发新检测，陷入逐点对抗；原因——反作弊是持续对抗工程，单点绕过必然升级；对策——把分析定位为"理解检测面"（系统视角）而非"制造漏洞"（单点视角）；产出按检测面组织（完整性/内存/行为/驱动层）并给出防御建议；对抗升级的案例本身就是防御研究素材（记录新旧检测机制对比）
• CSAuth3 心跳协议自包含可脱机复现（GameGuard）：现象——反作弊心跳包（头部 KDF + 载荷变换 + 双重 CRC）黑盒猜测易错，静态逆向无从下手；原因——CSAuth3 是 GameMon 客户端与对端的心跳问答循环（对端发挑战包、客户端回心跳包），全部密码学材料是硬编码常量（Blowfish K=0x91284712、公开 π 表），仅 counter 与 prev_size 随会话变化——首包 seed=0（counter=0、K=0x91284712、载荷 8 字节全 0 且空载荷不 scramble）；对策——按"头部 KDF 解密 → CRC1 → Blowfish 逆变换 → CRC2"逐层还原；scramble/descramble 是同一函数（Blowfish 加解密对称性：发送方明文 TLV 跑一遍 bf_dec 成线上密文，接收方再跑 bf_dec 还原）；构造包时必须先 scramble 再算 CRC2（CRC2 校验的是 descramble 之后的载荷）；密钥编排离线确定 → 纯脱机心跳可行
• 错误码表是心跳重放的黑盒加速器：现象——构造的心跳包被对端拒绝，不知道卡在哪层校验；原因——CSAuth3 对每类校验失败返回不同错误码（0xBAE 首包标志正常、0xCE9 CRC1 不匹配、0xCE8 CRC2 严格不匹配、0xBB8 CRC2 映射模式基值、0xCE5 seq>5、0xCEA magic≠0x1E、0xCEF/0xCEC size 越界、0xD4A body 未 8 对齐、0xD52 消息数不符、0xD913 消息类型1 哈希失败等）；对策——按错误码反推失败层（≥0xBB8 的错误置错误标志 → 后续 Check 假通过、Get 停发）；hook 客户端处理挑战包的 callback handler 可直接获知该发什么，转发即可
• CR3 加密（EAC 类内核反作弊）：现象——读 _KPROCESS.DirectoryTableBase 拿到的是错误 CR3，遍历进程内存全乱/访问异常；原因——反作弊接管内核异常并把 DirectoryTableBase 写错值，附加/读进程等需访问该字段的操作触发异常时，在接管后的异常回调里才修复真值；对策——获取真实 CR3 的常用法：页帧 ListEntry.Flink 指向加密后的进程 K/EPROCESS 结构指针，遍历 MmPfnDataBase 逐页帧比对 Flink 解密值是否为目标进程结构，命中即得真实 CR3；注意版本差异：Win11 24H2 及部分高版本 Win10/11 的加密算法（MiSetPageTablePfnBuddy 可见）与其他版本不同，需按版本适配；分析前先确认目标系统版本（见 [[re-kernel]] 结构随版本变化坑）