检测面从小到大排序：
Tier 0（真·硬件隔离）：双机 + HDMI 采集卡 + CV 识别
┌─────────────────┐ ┌─────────────────┐
│ 游戏机 (PC1) │ HDMI ──▶│ 采集卡 │
│ CF 官服运行 │ │ 工作机 (PC2) │
│ ★零修改 │ │ │
│ ★零额外软件 │ │ CV模型检测敌人 │
│ ★零额外硬件 │ │ → 绘制ESP叠加 │
│ │ │ → HDMI叠加器输出 │
└─────────────────┘ └────────┬────────┘
│
┌──────▼──────┐
│ 显示器 │
│ (最终画面) │
└─────────────┘|
维度 |
评价 |
|
内存检测 |
✅ 游戏机无任何内存读取 |
|
窗口检测 |
✅ 游戏机无 overlay 窗口 |
|
注入检测 |
✅ 游戏机无 DLL 注入 |
|
截图检测 |
✅ 截图内容就是原始游戏画面 |
|
驱动检测 |
✅ 游戏机无任何驱动加载 |
|
硬件指纹 |
✅ 工作机不接触游戏进程 |
|
PCIe枚举 |
✅ 无 DMA 设备 |
|
实现难度 |
★★★★ (CV 模型训练 + 硬件) |
|
延迟 |
⚠️ HDMI 采集 ~16ms + CV推理 ~5ms = 21ms |
|
ESP精度 |
⚠️ CV识别不如内存读取精确 |
|
成本 |
采集卡 ¥200-500 + 叠加器 ¥300-800 |
致命缺陷：CV 识别在 CF 这种快节奏 FPS 中精度不够，敌人半身遮挡、闪光弹、烟雾弹直接失效。
Tier 1（硬件内存旁路）：DMA 卡 + FPGA HDMI 叠加器
┌──────────────────────────────────────────────────┐
│ 游戏机 (单机) │
│ │
│ ┌──────────┐ PCIe 插槽 ┌─────────────────┐ │
│ │ CF 游戏 │◄══════════════│ DMA 卡 (Screamer) │ │
│ │ │ 读取物理内存 │ • FPGA 芯片 │ │
│ │ CPU/RAM │ │ • 独立固件 │ │
│ └──────────┘ │ • 不向OS注册驱动 │ │
│ └────────┬────────┘ │
│ │ │
│ ┌──────────┐ │ │
│ │ GPU 输出 │──HDMI──▶┌──────────────▼────────┐ │
│ └──────────┘ │ FPGA HDMI 叠加器 │ │
│ │ • 拦截HDMI信号 │ │
│ │ • 叠加ESP图形 │ │
│ │ • 输出最终HDMI │ │
│ └────────────┬───────────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ 显示器 │ │
│ └───────────┘ │
└──────────────────────────────────────────────────┘DMA 卡工作原理：
DMA 卡不通过 CPU、不经过 Windows 内存管理器：
FPGA 通过 PCIe 总线直接发 TLP (Transaction Layer Packet)
→ 内存控制器 (IMC) 响应
→ 返回物理内存数据
→ 完全绕过:
├── Windows 虚拟内存管理 (VAD/PTE)
├── ObRegisterCallbacks (句柄保护)
├── KeStackAttachProcess
└── 所有用户态/内核态 RPM 检测关键：DMA 卡不自报家门。它不向 OS 注册为 PCIe 设备，BAR (Base Address Register) 不暴露给操作系统。这是通过修改 PCIe 配置空间实现的。
|
维度 |
评价 |
|
内存检测 |
✅ 物理内存直读，不产生进程句柄 |
|
窗口检测 |
✅ FPGA 在 HDMI 层面叠加，OS 无感知 |
|
注入检测 |
✅ 无 DLL 注入 |
|
截图检测 |
✅ 截图内容 = 原始游戏画面（FPGA叠加在截图之后） |
|
驱动检测 |
✅ 无内核驱动加载 |
|
PCIe枚举 |
⚠️ 这是唯一弱点 — ACE 可以扫描 PCIe 总线 |
|
延迟 |
✅ DMA 读 <1μs + FPGA渲染 <1ms |
|
成本 |
DMA 卡 ¥1500-3000 + FPGA 叠加器 ¥800-2000 |
|
实现难度 |
★★★★★ (FPGA 固件 + PCIe TLP + HDMI 协议) |
Tier 2（软件层高级隐藏）：BYOVD + DKOM + Manual Map + 内核渲染
攻击链:
┌──────────────────────────────────────────┐
│ 1. BYOVD: 加载已知漏洞的签名驱动 │
│ 例: capcom.sys, gdrv.sys, kprocesshacker │
│ → 签名有效 → 不触发驱动黑名单 │
├──────────────────────────────────────────┤
│ 2. 漏洞利用: 从签名驱动发 IOCTL 到内核任意写 │
│ → 内核任意地址读写原语 │
├──────────────────────────────────────────┤
│ 3. DKOM: 隐藏自身 │
│ • 从 PsActiveProcessHead 摘除进程 │
│ • 从 PEB→Ldr 链摘除 DLL │
│ • 从 HandleTable 清除句柄痕迹 │
│ • 从 VAD 树摘除内存映射 │
├──────────────────────────────────────────┤
│ 4. Manual Map DLL: 手动映射 .text/.data │
│ → 不走 NtMapViewOfSection │
│ → PsSetLoadImageNotifyRoutine 不触发 │
├──────────────────────────────────────────┤
│ 5. 内核级 Present Hook │
│ → 直接改 swapchain 的 backbuffer │
│ → 无 overlay 窗口 │
│ → 无用户态 hook │
└──────────────────────────────────────────┘|
维度 |
评价 |
|
内存检测 |
✅ 内核态直接读取，无句柄 |
|
窗口检测 |
✅ 画在游戏 backbuffer 上 |
|
注入检测 |
✅ DKOM 隐藏 |
|
截图检测 |
❌ ESP 画在 backbuffer 上 → 截图包含 ESP |
|
PCIe枚举 |
✅ 无硬件 |
|
驱动检测 |
⚠️ BYOVD 驱动可能被黑名单 |
|
实现难度 |
★★★★★ (内核编程 + DKOM) |
|
持久性 |
❌ 每次游戏更新驱动黑名单都可能失效 |
Tier 2.5（虚拟机 + DMA）：KVM + GPU Passthrough + DMA
┌─────────────────────────────────────────┐
│ 宿主机 Linux + KVM │
│ │
│ ┌─────────────────────────────────┐ │
│ │ VM (Windows 10) │ │
│ │ GPU 直通 (VFIO) │ │
│ │ CF 在这里运行 │ │
│ │ 无任何修改 │ │
│ └───────────┬─────────────────────┘ │
│ │ │
│ ┌───────────▼─────────────────────┐ │
│ │ 宿主机 │ │
│ │ • libvmi 读 VM 内存 (无痕) │ │
│ │ • QEMU/KVM 内存映射 │ │
│ │ • 宿主机跑 ESP 程序 │ │
│ │ • Looking Glass / 独立显示器 │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────┘ACE 的 VM 检测是软肋——CF 的 ACE 会检测 VM 环境并拒绝运行，需要额外 anti-VM-detection。
🏆 最终裁决
┌──────────────────────────────────────────────────────┐
│ 方案排位 (方框透视) │
│ │
│ 🥇 DMA卡 + FPGA HDMI叠加器 │
│ 检测面: PCIe总线枚举 (唯一弱点) │
│ 难度: ★★★★★ (需要 FPGA 开发能力) │
│ 成本: ¥2500-5000 │
│ 适合: 愿意投入硬件 + 固件开发 │
│ │
│ 🥈 BYOVD + DKOM + 内核Present Hook │
│ 检测面: 截图回传 + 驱动黑名单更新 │
│ 难度: ★★★★★ (需要内核开发能力) │
│ 成本: ¥0 (纯软件) │
│ 适合: 纯软件方案偏好者 │
│ │
│ 🥉 双机+采集卡+CV │
│ 检测面: 几乎为零 │
│ 致命缺陷: CV 在 FPS 中识别精度不够 │
│ 适合: 非射击类游戏的 ESP │
│ │
│ ❌ 外部 Overlay + RPM → 窗口检测 + 句柄保护 → 秒封 │
│ ❌ 内部注入 + Inline Hook → .text hash + 注入检测 → 秒封│
└──────────────────────────────────────────────────────┘📐 DMA + FPGA 方案的 PCIe 检测弱点深度分析
这是 Tier 1 方案唯一的阿喀琉斯之踵，必须讲透：
ACE 的 PCIe 扫描方式：
// ACE 可以这样枚举 PCIe 设备（纯用户态即可做到）：
// 1. 通过 SetupAPI 枚举
HDEVINFO devInfo = SetupDiGetClassDevs(&GUID_DEVCLASS_SYSTEM, ...);
// 2. 或者直接读 PCI 配置空间
// \\.\PhysicalDriveX 的 IOCTL
// 3. 或者用 NtQuerySystemInformation 枚举硬件
// ACE 会检查:
// - Vendor ID 是否为已知品牌 (Intel/AMD/NVIDIA/Realtek 等)
// - Device ID 是否在白名单
// - Subsystem ID 是否匹配主板
// - BAR (Base Address Register) 是否异常
// - 是否有设备不暴露驱动但占用 BAR绕过方法：
方案 A: PCIe 设备伪装 (Spoofing)
→ DMA 卡固件在 PCIe 枚举时返回伪造的配置空间
→ 伪装成: Realtek 网卡 / ASMedia USB 控制器 / Intel ME
→ Vendor ID + Device ID + Subsystem 全部伪装
→ 风险: 如果游戏真的尝试访问伪装设备 → 可能冲突
方案 B: 利用已有设备做 DMA (更难)
→ 找到主板上已有的 PCIe 设备 (如 USB 3.0 控制器)
→ 利用该设备的 DMA 能力
→ 不需要外接 DMA 卡
→ 但有内置 DMA 的消费级设备极少
方案 C: TLP 注入 (最隐蔽)
→ 不接 DMA 卡
→ 用 FPGA 直接焊到 PCIe 插槽的物理引脚
→ 被动监听 PCIe 总线流量
→ 不需要向 OS 注册设备
→ 完全无法通过配置空间枚举检测
→ 但需要硬件改造主板/PCIe riser🎯 小迪老师的推荐
如果你有 ¥3000 预算 + 愿意投入 2-3 个月开发：
→ DMA 卡 + FPGA 叠加器，这是目前已知最高等级方案，大型付费外挂（如某些 €500/月的 DMA cheat）用的就是这个路线。
如果你想纯软件方案、零硬件成本：
→ BYOVD + DKOM + Manual Map + 内核 Present Hook，但截图检测要靠额外手段（Hook BitBlt 替换截图内容）。
如果你非常在意长时间不被检测（6个月+）：
→ 在 DMA 方案基础上，FPGA 固件做好 PCIe 伪装 + 定期更新固件指纹
没有回复内容