简介Cheat Engine源码是一套以德尔斐语言编写的游戏调试工具完整工程面向游戏逆向、安全研究人员也适合想深入理解内存扫描、动态地址跟踪与进程注入机制的开发者。资源包为压缩包封装共一千五百四十六个文件文件类型以帕斯卡源文件、窗体定义文件为主辅助包含C语言头文件、脚本、动态链接库以及多种开发环境配置整体体积仅约八兆结构凝练便于按模块学习和复用。目前已有三百九十五人学习下载适合具备一定编程基础并希望进阶的读者。透过源码可以系统学习精确值与模糊值扫描、动态地址重定位、跨进程内存读写与注入、结构体数组指针等复杂数据解析以及脚本引擎的集成方式同时也能借鉴其组件化界面设计、多线程任务调度和异常处理机制。对于游戏开发调试、逆向分析或安全研究而言这份源码提供了从理论到落地的完整参照能帮助读者快速建立内存操作与程序调试的整体认知。1. 先泼一盆冷水CheatEngine源码真正值钱的不是“改数值”CheatEngine源码这个标题八成读者是冲着游戏修改器来的。但如果你真把整套源码翻完会发现它最值钱的部分是一份完整的 Windows 用户态调试器教案进程怎么枚举、内存怎么扫描、断点怎么命中、异常怎么分发、哪些操作必须借内核驱动完成。这些恰恰是反外挂、安全测试和底层调试工程师每天都在处理的问题。一次扫描要处理分页边界和线程上下文一次断点命中要处理异常分发链路能把这套链路讲清楚的源码在开源世界里并不多。这套源码适合有 C/C 或 Object Pascal 基础、想补 Windows 内存模型盲区的开发者。下面的章节按“源码结构 → 扫描引擎 → 调试注入 → 编译坑 → 最小原型”的顺序推进全程只聊技术不聊任何具体的游戏修改玩法。2. 拆开 CheatEngine 源码的工程骨架Lazarus 下的四层结构与编译验证2.1 为什么用 Object Pascal一个能跑出性能又能快速改界面的选型先说选型。CheatEngine 主体用 Object Pascal 写成配套 Lazarus FreePascal 编译。很多人第一反应是“为什么不用 C”但回头看这个选择的合理性很强内存扫描器要频繁调用 Windows APIObject Pascal 对 API 声明的表达很直接界面需要快速迭代Lazarus 的窗体设计器能省大量布局时间调试器需要和汇编打交道时它又能内嵌 asm。源码里的核心单元有明确的边界界面层只管输入输出扫描器只管算法调试器只管异常分发驱动接口只管内核通信。读源码时先按这四层切分才不会陷进窗体代码的细节里。2.2 核心单元地图界面、扫描器、调试器、驱动四条线从工程文件入手先看项目里 .lpi 文件Lazarus 工程。它旁边的主单元通常承担界面和流程编排再往下是内存查询、扫描、调试和驱动桥接四组单元。表里整理我常对照着看的几个模块区域模块区域主要职责阅读时重点盯的逻辑进程与内存枚举枚举进程列表、遍历内存区块VirtualQueryEx 的循环方式和保护属性过滤扫描算法首次快照、二次比对、过滤候选候选地址的存储结构和页位图调试器VEH 注册、断点读写、线程上下文异常分发和恢复执行的路径驱动接口加载内核模块、与 Ring0 通信DeviceIoControl 的 IOCTL 分发脚本引擎Lua 解析与命令绑定脚本命令如何映射到扫描原语第一次拿到源码不要逐行读。我一般先全局搜 AddVectoredExceptionHandler、VirtualQueryEx、ReadProcessMemory 三个符号把这三条线的调用点标出来工程结构就清楚了大半。2.3 用命令把源码跑起来第一次全量编译的最低步骤环境准备时有两个容易翻车的点一是 Lazarus 与 FreePascal 版本必须匹配二是首次编译前需要先编译工程引用的依赖包。下面这个命令是我常用的全量构建方式# 首次全量构建--pcp 指定独立配置目录避免污染默认配置 lazbuild --pcp$HOME/ce_build_config -B CheatEngine.lpi # 若只改了一个单元去掉 -B 走增量编译会快很多 lazbuild --pcp$HOME/ce_build_config CheatEngine.lpi--pcp参数的作用是让这次构建使用独立的 IDE 配置不会影响你日常的 Lazarus 环境-B表示强制重新编译所有依赖单元源码包刚解压时几乎必须加。跑通之后先别急着附加进程在空白状态下点开“打开进程”对话框确认进程列表能正常列出说明用户态的进程枚举链路已经通了。第一次构建失败最常发生在资源文件路径上源码包解压目录带中文或空格时Lazarus 的 .lrs 资源链接偶尔会找不到文件。把源码放到纯英文无空格的路径下再编译这是成本最低的排障手段。2.4 程序启动的六步从权限检查到主窗口弹出读入口代码时把启动顺序拆成六步就够第一步检查当前进程是否管理员权限决定驱动相关功能是否可用第二步解析命令行参数看是正常启动还是带了特殊模式第三步初始化扫描器需要的全局配置包括值类型的注册表第四步尝试加载驱动失败则降级到纯用户态模式第五步创建主窗体并注册全局热键第六步进入消息循环。这六步里最容易让人迷路的是驱动加载失败后的降级分支很多菜单项会变灰并不是程序坏了而是驱动组件确实没起来。看源码时沿着这六步走能省下大量在窗体事件里找逻辑的时间。3. 内存扫描引擎CheatEngine 源码里最值得抄的一段算法演进3.1 扫描的本质一次快照一套比对候选集合指数级收敛内存扫描的核心不是“读内存”而是“维持候选集合”。第一次扫描时程序会枚举目标进程所有可读内存区域把每个区域按用户选择的值类型拆成条目存进快照。第二次扫描开始每次只对上一次的候选集合做比对命中保留、未命中剔除候选规模通常指数级下降。CheatEngine 的扫描快照结构本质上就是一个带页索引的数组地址、上次值、页号。这样在“未知初始值 增大”这类变化量扫描时不需要重读整块内存只需要拿着旧值和新值做一次差值判断。3.2 “未知初始值 变化量”扫描核心循环只有三步源码里变化量扫描的比对逻辑提炼出来是这么三步读当前值、与快照里存的上次值相减、按用户设定的“增大或减小”条件决定保留还是丢弃。真正的复杂度在内存区域枚举的边界处理比如不可读区域要跳过、共享页面的首尾对齐。下面这段是比对逻辑的简化表达# 简化版候选条目只需三个字段 # (address, old_value, page_index) # 枚举候选列表并判定“增大了”的条件 for candidate in candidates: current read_memory(candidate.address) # 重新读取 if current candidate.old_value: # 增大了则保留 kept.append(candidate) # 无论是否保留都把快照值更新为当前值 candidate.old_value current这段简化逻辑里address字段记录命中地址old_value保存上一次快照值page_index把候选归属到内存页便于后续按页合并。比较条件是current old_value对应界面上“增大了”的选项如果要扫“减小的值”只需把大于改成小于。注意无论候选是否保留old_value都要更新为当前值否则下一次比对永远拿不到变化量。比对循环本身不复杂真正的坑在后面候选集合可能包含几十万个条目每次比对后的去重、排序和内存占用决定了扫描器能不能在交互界面里跑起来。源码里用页位图来标记“哪一页有候选”再对页内条目做排序和压缩这样扫描结果展示时只加载命中的页而不是把整个候选数组扔给界面。3.3 三个必须调对的参数对齐方式、快照时机、暂停进程策略实操里扫描结果漂移十有八九是下面三个参数没调对。第一是值类型和字节对齐4 字节值要按 4 字节对齐扫否则命中数翻几倍而且大多是错位数据第二是快照时机目标进程在扫描间隙持续写入内存时新旧值之间夹了中间态变化量扫描会漏掉或误报第三是“扫描时是否暂停目标线程”暂停后一致性最好但有些目标进程暂停主线程会触发看门狗必须改用逐线程挂起。源码里对每个参数都有默认值但默认值不一定适合你正在调试的目标。提示扫描间隙持续写入的目标进程优先开逐线程挂起而不是全进程暂停这在生产环境的联动测试里能少踩很多坑。3.4 从扫描器单元能抄走的两个工程习惯一是结果增量展示扫描过程不是阻塞式的后台线程每合并完一批页就推送一次进度界面始终能响应。二是上层接口与算法解耦扫描算法完全不感知“用户选的是 4 字节还是浮点数”值类型的解析发生在更上层算法层只拿到统一的字节序列和比较谓词。这两个习惯在反外挂工具和服务端内存检测里可以直接复用。另外注意候选集合的内存上限控制当命中量超过预设阈值时源码不是无脑扩容而是把页面压成位图、只保留页号和页内偏移这样单条目的内存占用能压到 4 字节以内。这个思路在处理上亿候选时是保命级的设计。4. 调试器与注入链路VEH 断点、异常分发和内核驱动的分工边界4.1 为什么源码里放着调试 API 不用偏要自己注册 VEHWindows 调试 API 的挂接是排他的一个进程只能被一个调试器附加很多反外挂会抢先占住这个位置。CheatEngine 源码里的做法是在目标进程内挂一个 Vectored Exception Handler让异常先经过自己的回调再做判断、再决定要不要交回原链。这个思路对写反外挂和做安全研究同样重要VEH 在异常分发的第一顺位不受调试器排他限制只要能把代码注入目标进程就能挂。源码里的调试器单元核心就是两件事注册回调、在回调里读 CONTEXT 结构。4.2 软件断点与硬件断点一篇内存开销一篇寄存器开销断点管理是调试器单元里信息密度最高的部分。软件断点写 0xCC命中后 CPU 触发断点异常回调里要先把原字节写回去、再把指令指针回退一位、单步执行一次、最后重新下断。硬件断点则用 DR0~DR3 存地址DR7 存使能位不改内存但数量上限是四个。源码里两类断点分开管理软件断点带“原字节缓存”硬件断点带“寄存器槽位分配”。调试目标被反外挂检测时硬件断点往往比软件断点更隐蔽但 DR7 的读写本身也会被检测没有绝对安全。软件断点命中后的恢复流程可以用下面这段伪代码理解# 软件断点命中后的恢复流程伪代码 def on_breakpoint(context, addr): original_byte breakpoint_map[addr] # 取回断点处原字节 write_memory(addr, original_byte) # 先把 0xCC 写回原指令 context.Rip - 1 # 指令指针退回断点位置 set_thread_context(context) # 写回上下文 enable_single_step() # 开启单步执行原指令这里context.Rip - 1是必须的因为 INT3 指令只占 1 字节异常发生时 RIP 已经越过 0xCCbreakpoint_map以地址为键缓存原字节重复下断点时再写回 0xCC单步执行完原指令后TF 标志由下一次异常处理负责清除。这段逻辑读懂了调试器单元就算入门了。4.3 注入链路远程线程、APC 与手动映射的取舍需要远程执行代码时源码里常见的选择是 CreateRemoteThread 注入或者 APC 注入遇到更严格的保护时会用手动映射也就是把一份 DLL 的镜像手动展开到目标进程并修复重定位表。这三条路径的取舍很直接注入方式实现代价隐蔽性适用场景CreateRemoteThread低几行代码低调用点明显快速验证APC 注入中需要目标线程空闲中目标不创建新线程时手动映射高需要修复重定位表高需要绕过加载器检测时读源码时建议只盯一个点注入完成后代码做了什么。有些注入只是为了让目标进程加载调试辅助模块有些则是挂钩 API 做数据截获目的不同后续链路完全不同别在注入方式的选择上过度纠结。4.4 驱动接口哪些操作必须切换到 Ring0用户态能做的事到 VirtualProtectEx、WriteProcessMemory 就到顶了。要隐藏调试痕迹、读取被保护内存、绕过句柄权限限制必须加载内核驱动在 Ring0 完成。驱动接口单元通常是一个很薄的 DeviceIoControl 转发层上层传进程 ID 和地址驱动负责查进程结构、读写物理内存。阅读驱动部分时不要陷进内核结构细节先看 IOCTL 分发函数里有哪些指令码再对照用户态调用点看哪个操作对应哪个指令码整条通信链路就串起来了。5. 编译与联调的避坑记录环境版本、驱动签名和反外挂干扰5.1 坑一首次全量编译报“找不到资源文件”现象用 lazbuild -B 构建中途报 .lres 或 .ico 资源文件路径找不到构建中断。 原因源码解压路径里有中文或长空格资源链接时的相对路径解析失败。 解决把源码移动到纯英文且无空格的路径重新构建。这个坑出现频率极高先检查路径再怀疑环境。5.2 坑二驱动加载失败错误码 0x80070005 / 0x00000455现象点击加载驱动后提示权限不足或验证失败功能菜单里需要管理员权限的选项全灰。 原因驱动没有可信签名当前系统启用了内核强制签名策略。 解决临时开启内核调试模式或用管理员终端设置测试签名策略后重启。如果目标机器上有安全软件还要先把驱动添加到白名单。排障时先看系统事件日志里驱动的加载记录确认是签名问题还是设备对象创建失败。5.3 坑三附加目标进程目标立刻崩溃退出现象附加后目标进程秒崩断点还没来得及生效。 原因目标进程内有反调试检测或 VEH 回调里出现异常后没有正确调用涉及上下文恢复的接口导致异常处理链断裂。 解决先在 VEH 回调入口加日志确认异常是否到达。如果没到达说明注入的代码在运行前就被检测了检查注入方式是否有明显痕迹如果到达后崩溃重点检查回调里修改上下文后有没有正确写回。5.4 坑四64 位目标扫描结果大量错乱现象对 64 位目标进程扫描结果地址看起来正常读出来的值对不上。 原因地址变量在部分代码路径里仍是 32 位宽度高地址被截断或者目标进程存在多个同值条目选了错误的命中项。 解决确认地址类型用的是 QWORD把所有读写内存的 API 调用的 SIZE_T 参数显式声明为 64 位。源码在适应 64 位时最容易留疤的就是这类隐式截断排查时优先全局搜 DWORD 类型的地址变量。5.5 坑五扫描结果为空但目标进程确实有数据现象第一次扫描能出候选第二次扫描全部过滤干净。 原因扫描间隙目标进程重新分配了内存或者线程上下文保存的旧值对应的页已经被换出读到的快照是旧的。 解决把“暂停进程”选项打开或者在扫描前先锁定相关内存页。另外检查内存区域过滤条件排除了 MEM_PRIVATE 之后很多真实堆数据会被漏掉这是默认过滤里最隐蔽的一个条件。5.6 坑六进程列表一片空白现象主窗体能开但“打开进程”对话框里什么都列不出来。 原因枚举进程时用的权限位不够或者列表刷新线程被异常吞掉了。 解决先确认是否以管理员权限运行再在列表刷新入口加 try-except 日志看看是 OpenProcess 失败还是快照获取失败。源码里这类静默异常很常见因为 UI 线程不允许弹窗干扰交互错误被直接吞掉。6. 把原理落成工具一个可直接运行的内存扫描原型Python 版到这一步前面四章讲的链路已经可以浓缩成一个最小可运行的验证程序。下面这个 Python 脚本不含任何反外挂逻辑只做两件事枚举目标进程的可读内存区域、按区域边界打印地址和大小。它既能验证第 3 章扫描算法里的枚举逻辑也能当作你后续用 CheatEngine 源码时摸清各参数含义的标尺。import ctypes from ctypes import wintypes PROCESS_QUERY_INFORMATION 0x0400 PROCESS_VM_READ 0x0010 MEM_COMMIT 0x1000 PAGE_READABLE 0x7e # 常见可读保护属性的聚合 class MBI(ctypes.Structure): _fields_ [ (BaseAddress, ctypes.c_void_p), (AllocationBase, ctypes.c_void_p), (AllocationProtect, wintypes.DWORD), (RegionSize, ctypes.c_size_t), (State, wintypes.DWORD), (Protect, wintypes.DWORD), (Type, wintypes.DWORD), ] def enum_regions(pid): k32 ctypes.windll.kernel32 h k32.OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, False, pid) if not h: raise OSError(OpenProcess failed) addr, regions 0, [] while True: mbi MBI() if k32.VirtualQueryEx(h, ctypes.c_void_p(addr), ctypes.byref(mbi), ctypes.sizeof(mbi)) 0: break if mbi.State MEM_COMMIT and (mbi.Protect PAGE_READABLE): regions.append((mbi.BaseAddress, mbi.RegionSize)) addr mbi.BaseAddress mbi.RegionSize k32.CloseHandle(h) return regions脚本里的权限位参数值得单独说明PROCESS_QUERY_INFORMATION 是查询内存信息的必需权限PROCESS_VM_READ 是后续读取目标进程内存的必需权限两者缺一OpenProcess 成功但后续调用会静默失败。PAGE_READABLE 把常见可读保护属性聚合成一个掩码实际工程里还要区分可写和可执行这里只演示可读分支。遍历循环用 VirtualQueryEx 的返回值是否为 0 作为终止条件每次把地址指针推进一个 RegionSize这是枚举虚拟地址空间的标准做法CheatEngine 源码里的枚举循环也是同一套节奏。把这个原型跑通后再回头对照 CheatEngine 源码里的扫描单元做的事情基本同构差异只在页位图、快照压缩和界面交互。我读这套源码最大的教训是别想着从头读到尾先跑通最小链路再对照找符号效率完全不同。先建原型再读源码这条顺序建议你试试。希望帮到你。本文还有配套的精品资源点击获取
