简介驱动CE是一份面向游戏安全研究与逆向调试场景的增强版Cheat Engine资源主要解决常规调试工具无法穿透驱动保护的问题。资源具备绕过EAC等常见反作弊机制的能力可用于访问被保护进程、设置硬件断点、跟踪关键代码以及执行内存读写分析适合具备内存调试基础的安全爱好者、游戏汉化人员以及嵌入式与单片机方向的学习者。压缩包共包含330个文件大小仅14.67MB内容覆盖C/C头文件与源代码、动态链接库、Lua自动化脚本、可执行程序、窗体设计文件以及配置文件等。其中头文件和源码便于把握驱动编译逻辑动态链接库与系统驱动文件支撑底层调用Lua脚本和窗体文件可辅助界面操作与批量任务整体目录结构清晰便于按需检索和二次开发。目前已有2968人学习下载读者不仅能获得一套可直接运行的工具链还能通过阅读源码理解驱动保护绕过与调试器交互的实现思路进一步迁移到嵌入式硬件调试或加固对抗分析中。 你有没有遇到过这种情况用 Cheat EngineCE附加一个带自校验的程序进程加上了地址也搜出来了但数值一改就报错或者指针链中间某层地址直接变成“”。更离谱的是有的程序连 CE 的“读取”操作都会被拦仿佛整个进程被罩了一层玻璃罩。这时候懂行的人会告诉你用驱动。所谓“驱动 CE”并不是给 CE 装个什么特殊皮肤而是给 CE 这类内存分析工具补上一个“内核态读写通道”——把原本在用户态走 OpenProcess/ReadProcessMemory 的流程换成由内核驱动直接解析进程页表、读写目标地址。这个方案对内核驱动的学习者来说也是很好的实战项目。这篇文章我会把驱动 CE 背后涉及的核心机制讲清楚并给出一份可直接编译的最小驱动源码。内容面向两类人一类是想理解 CE 凭什么能读写游戏内存的逆向爱好者另一类是刚开始接触 Windows 内核驱动开发、想找个具体项目练手的同学。先说好我讲的是技术原理和单机/CTF 场景下的合法研究不是帮你去破坏多人游戏的公平性。1. 为什么“驱动CE”不只是一个噱头主流内存访问模式的优劣势1.1 用户态API的权限边界与反调试拦截很多新手遇到 CE 写不进数值的问题时第一反应是“搜错了地址”或者“偏移不对”但真正的原因是CE 默认走的是用户态读写调用链大致是 WriteProcessMemory - NtWriteVirtualMemory - 进入内核完成实际写入。这个过程本身没什么问题问题是它的调用源头在用户态并且使用的句柄权限、进程保护状态都是可以被目标进程里面运行的代码检查到的。如果一个程序启动了调试特权SeDebugPrivilege拦截、NtWriteVirtualMemory 的 hook或者直接把自己进程的访问权限设为只能读取那么 CE 在用户态怎么折腾都突破不了。我在调试一个加了反调试器检测的 CrackMe 时就遇到过CE 能附加但所有对指定地址的读操作返回的数据全是 0写操作虽然显示成功重新读还是旧值。这种情况基本可以判定目标在用户态 API 层做了手脚。1.2 VEH模式为什么救不了加固程序CE 从 7.5 开始默认不再加载内核驱动而是用 VEHVectored Exception Handler模式它在目标进程里注册一个向量化异常处理器通过故意触发异常、在异常处理器中拦截并修改指令执行流来实现数值修改。这个模式最大的好处就是不需要驱动签名很干净也正因如此它成了很多轻度修改场景的默认选项。但 VEH 本质上是“在你自己的进程里做文章”它绕不过一个前置条件你首先得能正常越权访问目标进程的关键内存。如果目标进程被反调试框架保护像 VADVirtual Address Descriptor被标记为 NoAccess或者页面被设置成内核级保护那 VEH 根本没有插手的机会。它解决的是“如何不重新扫描就修数据”的问题而不是“如何在权限不足时强读内存”的问题。1.3 驱动模式到底动用了什么内核能力驱动模式之所以强是因为它直接绕开了用户态那一整套 API 链路。驱动模块运行在 Ring0它拿到的不是“某个进程的受控句柄”而是这个进程的内核对象 EPROCESS。只要拿到了 EPROCESS就相当于拿到了整个进程地址空间的钥匙之后无论是读内存、写内存还是遍历模块、修改内存属性都是在内核里直接操作页表用户态的 hook 根本无从拦截。我自己第一次写驱动 CE 的时候感受特别深原来在用户态遇到一堆“访问拒绝”的地方在内核态只需要 PsLookupProcessByProcessId 拿到 EPROCESS然后 KeStackAttachProcess 切一下进程上下文RtlCopyMemory 就能直接读写。这种能力上的碾压才是“驱动 CE”存在的真正意义。2. 内核驱动读写用户态内存的核心机制从PID到CR3切换2.1 设备对象、符号链接与IRP分发CE怎么找到驱动驱动要能被 CE 或者我们自己的用户态程序调用首先得把自己变成一个“可以被打开的设备”。在 Windows 内核里这个动作分两步用 IoCreateDevice 创建一个设备对象比如 \Device\CeDrv再用 IoCreateSymbolicLink 建立一个符号链接比如 ??\CeDrv。用户态之所以能用 CreateFile 打开 \.\CeDrv靠的就是这个符号链接。设备建好之后还要处理 IRPI/O Request Packet。用户态每次调用 CreateFile、DeviceIoControl、ReadFile、WriteFile最终都会变成内核里的 IRP并且分发到驱动对象的 MajorFunction 表里对应的回调函数。对驱动 CE 来说最重要的函数是 IRP_MJ_DEVICE_CONTROL也就是用户态 DeviceIoControl 到达的地方。我们会在这一层解析用户传递的 PID、目标地址、读写长度等参数。2.2 从进程ID到EPROCESS只读握手的通行证用户态程序能拿到的通常是 PID也就是任务管理器里看到的那个数字。但内核驱动不认 PID它认的是 EPROCESS一个内核结构体。获取 EPROCESS 的标准途径是 PsLookupProcessByProcessId传进去一个 HANDLE 类型的 PID它就返回一个 PEPROCESS 指针。这个指针在后续操作中极其关键。我们可以把 EPROCESS 理解成“进程身份证”它内部包含了进程的页表基址也就是寄存器 CR3 要加载的值、进程的 PEB 地址、模块列表、Token 等一大堆核心信息。你不需要彻底弄懂 EPROCESS 的每一个字段但要知道拿到它你才有资格谈“读写这个进程的内存”。2.3 切换CR3的代价KeStackAttachProcess为什么是首选一个 CPU 同一时刻只能在一个进程地址空间里执行。想让驱动读取目标进程的用户态地址最直接的办法是切换 CR3 寄存器把当前地址空间换成目标进程的地址空间。但这在大项目中特别危险因为你手动切换 CR3 后一旦某个中断进来中断处理函数可能默认访问当前进程的地址空间直接蓝屏。所以更推荐的做法是用 KeStackAttachProcess。它内部会处理 CR3 切换和异常状态保存我们只需要在操作完成后调用 KeUnstackDetachProcess 切回来。这个思路有点像你进同事的工位拿文件需要先把门禁权限临时切到同事名下干完活再切回自己的工位。驱动里只要不做极端操作KeStackAttachProcess 是稳定且高效的选择。3. 从零写一个可用的CE读写驱动完整源码与部署流程3.1 环境准备WDK、测试签名与虚拟机写 Windows 内核驱动建议直接在 Windows 10/11 Visual Studio 2022 WDKWindows Driver Kit的环境里操作。安装完成后新建一个“Kernel Mode Driver, Empty”项目把源码加进去编译即可。不过有个前提64 位系统默认不允许加载未签名驱动开发调试阶段最简单的办法是开启测试签名模式。在管理员命令行里执行bcdedit /set testsigning on重启后桌面右下角会出现“测试模式”的水印。这个模式只在开发机上用不要在主力机上开更不要拿它去加载不明来源的驱动。我自己习惯在 VMware 虚拟机里搭一套 Win10 测试环境来跑驱动一旦蓝屏也不会影响宿主系统。3.2 自定义IOCTL与读写请求结构体现在定义用户态和内核态之间的通信协议。这里采用 METHOD_BUFFERED 模式系统会把用户的输入缓冲区和输出缓冲区分别整理成 SystemBuffer 和 UserBuffer驱动操作起来比较安全。读写请求结构体如下// 公共头文件用户态和驱动都包含 #define IOCTL_CE_READ CTL_CODE(0x9000, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS) #define IOCTL_CE_WRITE CTL_CODE(0x9000, 0x801, METHOD_BUFFERED, FILE_ANY_ACCESS) typedef struct _CE_RW_REQUEST { ULONG pid; // 目标进程 PID ULONG64 address; // 目标进程内的起始地址 ULONG64 size; // 读写长度 } CE_RW_REQUEST;读操作时输入缓冲区放这个结构体输出缓冲区接收读到的字节。写操作时输入缓冲区是结构体后面直接跟要写入的数据这样一次 DeviceIoControl 就能完成携带数据和请求参数的传递。CTL_CODE 里的 0x9000 是自定义设备类型号可以换成不会和系统冲突的值。3.3 驱动主体代码入口、设备创建与读写处理函数下面是一份精简但完整可编译的驱动源码主干#include ntddk.h #include ce_ioctl.h #define DEVICE_NAME L\\Device\\CeDrv #define SYMBOL_LINK L\\??\\CeDrv NTSTATUS CeReadVirtualMemory(PEPROCESS proc, PVOID addr, PVOID buffer, SIZE_T size) { KAPC_STATE apc; NTSTATUS status STATUS_SUCCESS; KeStackAttachProcess(proc, apc); __try { ProbeForRead(addr, size, 1); RtlCopyMemory(buffer, addr, size); } __except (EXCEPTION_EXECUTE_HANDLER) { status GetExceptionCode(); } KeUnstackDetachProcess(apc); return status; } NTSTATUS CeWriteVirtualMemory(PEPROCESS proc, PVOID addr, PVOID buffer, SIZE_T size) { KAPC_STATE apc; NTSTATUS status STATUS_SUCCESS; KeStackAttachProcess(proc, apc); __try { ProbeForWrite(addr, size, 1); RtlCopyMemory(addr, buffer, size); } __except (EXCEPTION_EXECUTE_HANDLER) { status GetExceptionCode(); } KeUnstackDetachProcess(apc); return status; }驱动的入口和 IRP 分发函数也不复杂NTSTATUS CeDeviceControl(PDEVICE_OBJECT dev_obj, PIRP irp) { PIO_STACK_LOCATION irp_sp IoGetCurrentIrpStackLocation(irp); ULONG ioctl irp_sp-Parameters.DeviceIoControl.IoControlCode; PVOID sys_buf irp-AssociatedIrp.SystemBuffer; ULONG in_len irp_sp-Parameters.DeviceIoControl.InputBufferLength; ULONG out_len irp_sp-Parameters.DeviceIoControl.OutputBufferLength; NTSTATUS status STATUS_SUCCESS; ULONG info 0; switch (ioctl) { case IOCTL_CE_READ: { CE_RW_REQUEST* req (CE_RW_REQUEST*)sys_buf; PEPROCESS proc NULL; if (NT_SUCCESS(PsLookupProcessByProcessId((HANDLE)req-pid, proc))) { status CeReadVirtualMemory(proc, (PVOID)req-address, sys_buf, (SIZE_T)req-size); if (NT_SUCCESS(status)) info (ULONG)req-size; ObDereferenceObject(proc); } else { status STATUS_INVALID_CID; } break; } case IOCTL_CE_WRITE: { CE_RW_REQUEST* req (CE_RW_REQUEST*)sys_buf; PEPROCESS proc NULL; PVOID data (PUCHAR)sys_buf sizeof(CE_RW_REQUEST); if (NT_SUCCESS(PsLookupProcessByProcessId((HANDLE)req-pid, proc))) { status CeWriteVirtualMemory(proc, (PVOID)req-address, data, (SIZE_T)req-size); if (NT_SUCCESS(status)) info (ULONG)req-size; ObDereferenceObject(proc); } else { status STATUS_INVALID_CID; } break; } default: status STATUS_INVALID_DEVICE_REQUEST; break; } irp-IoStatus.Status status; irp-IoStatus.Information info; IoCompleteRequest(irp, IO_NO_INCREMENT); return status; }入口函数和设备卸载函数同样直接NTSTATUS CeCreateClose(PDEVICE_OBJECT dev_obj, PIRP irp) { irp-IoStatus.Status STATUS_SUCCESS; irp-IoStatus.Information 0; IoCompleteRequest(irp, IO_NO_INCREMENT); return STATUS_SUCCESS; } VOID CeUnload(PDRIVER_OBJECT drv_obj) { IoDeleteSymbolicLink(SYMBOL_LINK); IoDeleteDevice(drv_obj-DeviceObject); } NTSTATUS DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING reg_path) { UNICODE_STRING dev_name; UNICODE_STRING sym_name; PDEVICE_OBJECT dev_obj NULL; NTSTATUS status; RtlInitUnicodeString(dev_name, DEVICE_NAME); RtlInitUnicodeString(sym_name, SYMBOL_LINK); status IoCreateDevice(drv_obj, 0, dev_name, FILE_DEVICE_UNKNOWN, 0, FALSE, dev_obj); if (!NT_SUCCESS(status)) return status; drv_obj-MajorFunction[IRP_MJ_CREATE] CeCreateClose; drv_obj-MajorFunction[IRP_MJ_CLOSE] CeCreateClose; drv_obj-MajorFunction[IRP_MJ_DEVICE_CONTROL] CeDeviceControl; drv_obj-DriverUnload CeUnload; status IoCreateSymbolicLink(sym_name, dev_name); if (!NT_SUCCESS(status)) { IoDeleteDevice(dev_obj); return status; } return STATUS_SUCCESS; }这里有一个很关键的细节读请求里我把读到的数据直接放回了 SystemBuffer。因为在 METHOD_BUFFERED 模式下SystemBuffer 既是输入缓冲也是输出缓冲系统最后会把它复制到用户态的输出缓冲区。这省去了单独维护缓冲区变量的麻烦代价是输入输出共用一块内存读请求下原请求结构体会被覆盖但用户态反正只关心输出数据问题不大。3.4 用户态调用DeviceIoControl与CE联动编译出 .sys 文件后先创建驱动服务再启动sc create CeDrv type kernel binPath C:\drivers\CeDrv.sys sc start CeDrv用户态程序打开设备并调用读写接口的代码非常简单#include windows.h #include stdio.h #include ce_ioctl.h int main() { HANDLE h CreateFileW(L\\\\.\\CeDrv, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (h INVALID_HANDLE_VALUE) return 1; CE_RW_REQUEST req { 0 }; req.pid 1234; // 改成目标进程 PID req.address 0x7FF70000000ULL; // 改成目标地址 req.size 4; ULONG bytes 0; BOOL ok DeviceIoControl(h, IOCTL_CE_READ, req, sizeof(req), req, sizeof(req), bytes, NULL); if (ok bytes 4) { printf(value: %08X\n, *(ULONG*)req); } return 0; }写操作稍微复杂一点需要构造一个比 CE_RW_REQUEST 更大的缓冲区结构体后面接数据。这个用户态程序通常不会直接替换 CE 的界面而是作为独立的读写验证工具和 CE 的扫描结果做交叉验证。4. 驱动开发中反复踩的坑签名、IRQL、缓冲区与蓝屏4.1 64位驱动签名测试签名模式的边界就算你只在自己机器上加载驱动64 位 Windows 也要求驱动有签名。测试签名模式是一个开发期方案但注意它有三个坑测试签名只对“用测试证书签名的驱动”生效不是随便弄一个没签名的 .sys 就能加载你仍然需要生成自签名证书来签名。开启测试签名模式后设备上会一直显示水印某些安全软件也会格外警惕所以它适合一次性开发环境。在 UEFI Secure Boot 开启的机器上bcdedit /set testsigning on 可能不生效得临时关闭 Secure Boot 才行。我自己调试时通常用 MakeCert 或者 Visual Studio 的 Driver Signing 功能生成测试证书然后 SIGNTool sign 一下再加载。每次改完代码build sign sc stop/start 的循环确实繁琐但这是绕不开的一步。4.2 上下文切换、IRQL 与 __try/__except 异常防护KeStackAttachProcess 虽然方便但它在较高的 IRQLDISPATCH_LEVEL 以下下才能正常工作。如果在驱动里随便开线程、自旋锁、工作项很容易触发 IRQL_NOT_LESS_OR_EQUAL 蓝屏。另外attach 之后读写目标地址可能因为目标内存不是正常用户内存而触发异常。比如地址是无效的或者该内存页被标记为“无访问”。这个异常发生在内核态不能用用户态的 try/catch 接住必须用内核态的 __try/__except 包裹否则驱动会直接 BugCheck。我在早期版本里漏了 ProbeForRead/ProbeForWrite结果每次读到坏地址都蓝屏。加上异常保护和内存探测函数之后即使地址非法驱动也能优雅地返回错误码。4.3 缓冲区大小、指针宽度和WOW64进程还有一个特别容易出问题的地方被读进程可能是 32 位的WOW64此时用户态地址是 32 位长度作为 ULONG64 传给驱动没有问题但在用户态结构体里如果用了 UINT就要额外小心符号扩展的问题。我建议统一用 ULONG64 存储地址避免 32 位进程地址被错误截断。同时METHOD_BUFFERED 模式下系统会检查 InputBufferLength 和 OutputBufferLength如果你用户态传入的 size 跟结构体长度不匹配驱动里读取 req-address 或 req-size 就可能读到越界内容。稳妥的做法是在驱动里校验 in_len 至少是 sizeof(CE_RW_REQUEST)并且写操作的数据长度加结构体长度不超过 in_len。5. 用驱动配合CE做实际内存分析一个完整小例子与进阶思路5.1 场景实战ReadProcessMemory失效的Demo我拿一个特意加了内存保护的自定义 CrackMe 来演示。这个程序在用户态被 CE 附加后数值区能正常搜到初始值但只要你修改它下一秒数值就恢复原样说明它在后台有校验线程或者 CRC 检查。这时候驱动派上用场。先用 CE 搜到目标地址再用自己写的用户态控制台程序把 PID 和目标地址传给驱动直接读取该地址的原始数据CeReadTool.exe --pid 1234 --addr 0x00A9B1C0 --size 16驱动读出来的数值和 CE 的扫描结果一致而且不会触发目标程序的自校验——因为整个过程没有走任何用户态 API目标进程根本感知不到这次读取。这给我们接下来的“静态分析校验函数”工作提供了干净的参考数据。5.2 驱动读出的数据与CE扫描结果交叉验证拿到驱动读写工具后建议不要急着改装 CE而是先用一组已知数据做交叉验证。比如在一个测试程序里设置一个整数全局变量CE 搜到它的地址驱动读完比对数值一致说明驱动读写链路可靠。然后再把 CE 的自动汇编脚本和驱动的写入接口分开测试确保写操作不会破坏调用进程的堆栈结构。我在这个环节踩过的坑是用户态把 PID 传进驱动时进程已经退出了但 PsLookupProcessByProcessId 竟然返回成功。原因是系统里进程对象没有立刻销毁只是处于“垂死”状态此时读写出的数据有可能是僵尸数据。所以调用前最好先用用户态 API 确认进程存在读取失败时也要检查错误码。5.3 后续扩展把驱动接口封装成服务或者DLL驱动本身只是底层能力真正好用的形态是封装。你可以把 DeviceIoControl 的调用包成一个读取函数再把函数编成 DLL交给 CE 的 Lua 脚本或者自己的图形界面调用。DLL 内部可以缓存设备句柄省得每次读写都 CreateFile/CloseHandle吞吐量会好很多。另外如果你刚开始接触 CE连官方教程第 9 步“共享代码”里的 auto assembler 都还没玩明白建议先把那一步的 AA 脚本和代码注入逻辑搞懂再回来看驱动。因为驱动只解决了“能不能读写”的问题而“写什么、写哪里、怎么绕过逻辑”这些更高层的分析思路恰恰是 CE 官方教程里那些步骤教你的事。驱动和 CE 就像锤子和图纸驱动给你一把够硬的锤子但盖房子的设计图还是要靠 CE 本身去理解。最后说一个我自己的开发习惯每次改完驱动代码不要直接在目标机器上反复重启测试。先在 Windbg 双机调试环境里跑一遍 read/write 的边界用例确认不会蓝屏再上真实目标。这样排查 CR3 切换、IRQL 这些问题时可以边看内核调试输出边定位比盯着 BugCheck 蓝屏代码猜原因高效得多。本文还有配套的精品资源点击获取