1. 先搞清楚：为什么攻击者总盯着内存变量
做游戏逆向安全研究，绕不开一个事实：游戏进程中存放在内存里的“变量”，几乎就是整个游戏世界的真相。无论单机游戏里的角色血量、分数、金币，还是网络游戏里的坐标、动作状态、伤害数值，在CPU眼里都只是特定内存地址上的一段字节。所谓“内存变量修改技术”，简单说就是绕过游戏UI和逻辑接口，直接在进程内存层面把这些数值改成攻击者想要的值，从而改变游戏行为。
这项技术常被称为“游戏逆向攻防”的一个经典切入点。它听着很“黑客范儿”，但请先明确一点：本文讨论的修改技术，全部限定在自己开发的测试程序、本地单机游戏、CTF逆向题目等授权环境下，目的是研究内存布局、理解程序运行原理、演练攻防对抗。用别人线上游戏牟利、写外挂，是明确的违规违法行为，我帮不了也不鼓励。掌握了原理，其实更有价值的是知道“如何防”——服务端怎么校验、客户端怎么加壳、检测工具怎么识别这类修改，这些才是安全工程师真正要落地的能力。
从防御方视角看，内存变量修改天然个很难防的问题。因为程序一旦运行起来，CPU必须把关键数据加载进内存、频繁读写，攻击者利用调试器和内存扫描器也能对这些地址做同样的读写。这相当于你家房门锁得好好的，可小偷通过猫眼就能看见钥匙放在桌上。如何让“桌上的钥匙”不被看见、不被拿到，或者即使被拿到也打不开门，就是攻防对抗的乐趣所在。
适合看这篇文章的读者，我猜多半是三类人：一是刚接触逆向、想搞明白“CE（Cheat Engine）到底是咋扫描到数值”的入门者；二是做游戏安全、想做反外挂检测的研发；三是打CTF被内存类题目虐过、想系统补课的选手。下面我不打算堆理论，直接把它拆成“思路、操作、攻防、避坑”四个环节讲透。
2. 内存变量修改技术全景拆解
2.1 从“改金币”到“改逻辑”：变量修改的三种层次
刚开始接触内存修改的人，最容易陷入“数值搜索”这一个点里出不来。其实内存变量修改大体可以分为三个层次，难度和风险逐级递增。
第一层：直接改数值。比如单机游戏里金币是1000，用CE先扫描1000，花点钱变成900，再扫900，反复几轮后锁定唯一地址，改成99999。这是最基础、也最容易被基础反外挂检测拦截的方式。因为行为特征明显：数值异常、修改频率高、进程附加痕迹。
第二层：改指针和地址。很多游戏不会把关键对象暴露在固定地址上，而是通过多级指针一层层指向堆里的实例。你搜到的地址可能每次启动都变。这就要找到“指向这个地址的指针”，再找“指向这个指针的指针”，最后定位到一个静态地址加偏移的链条。修改这不只是改数值，而是引导程序跳到攻击者设定的内存区域。很多所谓“指针扫描”就是这个原理。
第三层：改逻辑与数据流。真正高级的修改不碰数值，而是改指令跳转、改函数行为、注入代码。比如把“扣血函数”里的减法改成加法，或者Hook掉伤害计算函数直接返回最大值。这已经不仅仅是内存变量修改，而是程序行为干预了。对防御方来说，对付第一层只需数值校验，对付第三层则要考虑完整性校验、反调试、虚拟化保护。
搞明白自己处在哪一层很重要。做实验和写文章，我建议从第一层踏实做起，先理解工具原理，再尝试第二层，第三层涉及体系编译与Hook技术，又是另一个深水区。
2.2 常用工具与操作思路
工具不在多，能用透一个就赢一半。内存修改方向最经典的是Cheat Engine（CE），它集内存扫描、反汇编、调试器、指针扫描于一身，学习逆向用它做启蒙非常合适。除了CE，还可以配合x64dbg做动态调试，用Process Explorer观察进程结构，用API Monitor监控API调用，用Python的pymem或ctypes自行编写读写进程内存的脚本。
我常被问“CE到底怎么工作的”。核心就几个API：OpenProcess打开进程句柄，ReadProcessMemory读取指定内存，WriteProcessMemory写入内存，VirtualQueryEx遍历内存区域。CE不过把这些API封装成可视化操作，再叠加了一套高效的搜索算法。理解到这一层，你就不会觉得CE黑魔法，反而能自己写脚本，也能明白检测工具在挂钩哪些API。
操作思路上，永远遵循“缩小范围、动态过滤、定位地址、验证偏移”这四步。记住一个反直觉的重点：不要一开始就搜精确值，很多数值在内存里不是裸存的，可能是翻倍存储、可能是浮点数、可能带偏移。所以先用未知初始值扫描，然后通过增/减/不变/变化来过滤，往往比直接搜数值更能快速缩小候选范围。
2.3 变量定位五步法
我把完整的定位流程拆成五步，新手照着做基本不会乱。
第一步，附加进程。打开CE，选择目标进程。如果目标进程有反调试，这一步就会失败或卡死，这本身就是一个检测信号。
第二步，首次扫描。输入当前数值，选择正确的扫描类型。这里有个关键点：要确认类型。整数就是4字节，但有些浮点数是用单精度/双精度存储的，有些字符串需要额外的编码处理。锁定类型可以减少很多干扰项。
第三步，动态过滤。回游戏里让数值发生变化，然后再次扫描“变化的数值”或“减少/增加”。重复操作，直到候选地址数量降到个位数。这个过程实际上在教你一个道理：内存里的变量是“活”的，你要跟着它的生命周期去筛。
第四步，确认与指针分析。双击候选地址，在CE中查看内存区域，检查前后上下文，尝试通过“找出是什么改写了这个地址”（Find out what writes to this address）来定位指令，再向指令跟踪到基址加偏移。
第五步，验证与固化。改动测试，确认生效。如果重启游戏后地址失效，则需要做指针扫描找到静态地址链，并把最终的基址+偏移记录为“特征值”。这一步是将临时修改升级为可复用脚本的转折点，难度也主要集中在这里。
3. 关键环节实操：以自研程序为例完整演示
3.1 准备一个合法的“靶子”程序
为了演示，我自己写了一个极简的C++控制台程序，模拟一个游戏角色的“血量”和“分数”。程序每秒钟血量减少1点，分数增加1点，同时打印当前值。用这个做靶子，你不仅没有任何合规风险，还能直接对照源码验证修改结果。
#include <iostream> #include <Windows.h> int main() { int hp = 100; // 模拟血量，4字节整数 float score = 0.0f; // 模拟分数，单精度浮点 while (true) { hp--; score += 1.0f; printf("HP=%d, SCORE=%.1f\n", hp, score); Sleep(1000); } return 0; }注意我这里故意用了一个变量hp、一个变量score，分别代表整数和浮点数。实际游戏中血量可能是float、锁在类成员里、还带随机扰动，但万变不离其宗。编译成Release x64版本，运行起来，我们开始实操。
3.2 定位一个浮点变量的具体步骤
第一步：打开CE，选择“打开进程”指向这个demo.exe。附加成功后，CE会列出进程的主模块和内存区域。
第二步：扫描类型选择“浮点数”，数值填当前分数（程序启动后几秒，score应该已经累加成几了）。点“首次扫描”后，结果一般有几十个，因为浮点数0.x在内存里可能有别的地方也在用。不急，等1秒后分数变化，再来一次“扫描类型-增加的值”，通常候选数骤降到个位数。
第三步：选中剩余候选地址中的某一个，双击加入地址列表，右键“浏览相关内存区域”，看一眼这个地址附近的字节。你会发现score周围的区域还有hp值，甚至能认出printf格式化字符串的指针，那种“原来内存长这样”的感觉很奇妙。
第四步：把该地址的值改为9999.0，回到程序控制台，下一行打印出来的分数就会变成9999.0。这就是一次完整的内存变量修改。
那个“HP”的整数定位更简单，你可以用4字节类型直接扫描100，等待血量减少后过滤减少的值。这一正一反的两个演示，足以学会CE的基础用法。真正到这一步，你应该停下来想想：刚才改写的地址，是不是每次启动程序都不同？是的，因为hp和score是栈上局部变量，每次进程启动分配的栈地址不同。这就是为什么还需要解决“重启后失效”的问题。
3.3 写入代码：用外部进程读写内存
CE只是工具，实际在写检测代码或研究脚本时，还是得用系统API。用Windows自带API做内存读写，代码量不大，但有几个参数特别坑。
#include <windows.h> #include <tlhelp32.h> #include <iostream> DWORD find_pid(LPCWSTR name) { HANDLE snap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); PROCESSENTRY32W entry = { sizeof(entry) }; if (Process32FirstW(snap, &entry)) { do { if (wcsstr(entry.szExeFile, name)) { CloseHandle(snap); return entry.th32ProcessID; } } while (Process32NextW(snap, &entry)); } CloseHandle(snap); return 0; } int main() { DWORD pid = find_pid(L"demo.exe"); if (!pid) { std::cout << "process not found\n"; return 1; } HANDLE hProc = OpenProcess(PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION, FALSE, pid); if (!hProc) { std::cout << "openprocess failed\n"; return 1; } DWORD64 addr = 0x00007FF7A1B2C3D4; // 这里替换成刚才CE找到的地址 int newHp = 999; SIZE_T written = 0; BOOL ok = WriteProcessMemory(hProc, (LPVOID)addr, &newHp, sizeof(newHp), &written); if (ok && written == sizeof(newHp)) { std::cout << "write OK\n"; } else { std::cout << "write failed: " << GetLastError() << "\n"; } CloseHandle(hProc); return 0; }这里几个关键点：
OpenProcess的权限标志如果只给PROCESS_VM_READ而不给PROCESS_VM_OPERATION，读没问题但写不了地址空间；再不给PROCESS_VM_WRITE，改值一定失败。很多新手卡在这。
FindWindow按窗口找进程也行，但用Toolhelp快照按名字找进程更通用，面对无窗口进程也有效。
写数据时要清楚目标变量大小。hp是int就写4字节，score是float也写4字节，字节序在小端机器上直接写即可，不用反转。
现实中的游戏进程有保护时，OpenProcess会失败返回5（拒绝访问），这是一条非常直观的“你被反作弊拦了”的信号。而服务端游戏更多是改了也不生效，因为真正的数值在服务端算，客户端只是展示。
3.4 指针与偏移：为什么不能直接搜地址
如果你止步于直接搜索局部变量，那么重启程序地址一变你就抓瞎了。真实程序里，玩家对象往往是通过new动态分配在堆上的，地址由运行时决定，但对象通常被某个全局指针（静态地址）指向。要稳定修改，就得找到“全局指针+对象内偏移”这条静态链。
举个例子：假设游戏有全局结构体Game* g_game;，指向一块堆内存，其中在偏移0x1C0的位置保存了playerInfo结构，该结构再在偏移0x40处存血量hp。那么完整地址计算公式是：
最终地址 = [g_game] + 0x1C0 + 0x40
方括号表示读指针值。如果还有多级指针，就继续嵌套。用CE的“指针扫描”功能可以自动探索，但理解原理更重要。防御方在做加密时常做的操作，就是把这些偏移随机化、把全局指针藏到内存池深处、或者把对象索引改成加密句柄，目的就是增加这条链的搜索成本。
顺带说一个实际心得：不要贪心一次找深指针链。宁可先定位到玩家对象的某个常见成员（坐标/血量），然后用这些成员的反汇编去“向上回溯”对象基址，一层一层追踪。手动回溯的过程虽然慢，但能极大加深对程序结构理解，比直接跑指针扫描学到的多得多。
4. 攻防博弈：修改的检测与对抗
4.1 服务端权威计算：让客户端数据不再可信
悟透内存修改这门技术后，第一反应往往是“那所有游戏都能改喽？”还真不一定。现在稍微有点规模的对抗类游戏，设计哲学已经从“客户端相信一切”转向“服务端权威”。
什么意思呢？就是玩家角色血量、金币、背包、位置这些影响公平性的关键数据，真正的数值只存在服务器内存里。客户端发出的只是“操作指令”，比如“我按了治疗药水”，服务器收到后自己计算扣药水、回血，再把结果同步给客户端显示。客户端的内存里可能也有一份血量值，但那只是“展示缓存”，你把它改成1万，服务器不认，下次同步立刻被覆盖回真实值。
从防御方角度，服务端权威是最有效的策略。代价是服务器压力大、网络要求高，某些体验（比如单机化快节奏动作游戏）不适合全量服务端计算。于是衍生出混合模式：普通数值本地算，关键数值（交易、排行、掉落）服务端强校验；或定期快照比对，服务端定期下发一段状态哈希，客户端自检比对不一致就判定异常。
做安全研究时，判断一个游戏值不值得改、改完有没有用，先看它的通信机制是TCP/UDP/WebSocket，有没有状态同步，有没有密文。多数单机游戏和早期网络游戏完全是客户端上脑，改起来像打开改文件一样简单，这正是它们容易成外挂重灾区的根源。
4.2 完整性校验与混淆：让检索变得困难
服务端权威解决“改了没用”的问题，但很多游戏必须本地计算，比如防掉线的PVE副本，数值要本地算。这时候防御方就得在不影响性能的前提下，让攻击者“搜不到、扫不动、改不了”。
第一招：数值混淆。血量100不存100，而是存一个加密值比如100 XOR 0xA5A5A5A5，或者“实际血量+固定偏移”后反向存储。这样用CE直接搜索100是搜不到的，攻击者必须先逆出混淆算法。代价是每次读写都要额外计算，且算法一旦被扒出来就失效。实践中我会用轻量级异或+动态混淆密钥，密钥从代码里随机生成，尽量避免硬编码。
第二招：内存垃圾填充与随机偏移。在关键对象周围填充随机垃圾数据，把真实偏移每隔一段时间重新布局一次。相当于你每次去图书馆，书的楼层和架号都变。这能在不增加太多计算量的前提下大幅提高指针扫描的复杂度。
第三招：关键代码虚拟化。把获取血量、校验逻辑编译进虚拟化保护壳，运行时解释执行，反汇编直接看会变成一堆自定义字节码。这个手段成本高、兼容性差，主要用在核心模块上。我在逆向CTF题里经常遇到这种魔改虚拟机，说实话每次都是头皮发麻，但确实是延缓攻击者的有效手段。
4.3 反调试与运行时自检：提高门槛
就算数据做了混淆，攻击者最终还是要通过附加进程、读写内存来操作。所以最后一道防线就是“不让碰”。
反调试基础操作包括：检测自身是否处于调试状态（IsDebuggerPresent、NtQueryInformationProcess的DebugPort字段）、检测窗口标题是否包含常见调试器（x64dbg、OllyDbg）、检测CE等工具的标志性窗口类、定期对自己关键地址做完整性校验（就像晚上巡逻的保安，发现有人撬门就拉闸）。更硬核的方式是父进程校验、线程隐蔽执行、内核态回调，这些属于更深的对抗方向。
不过我提醒搞防御的读者一句：反调试不是越强越好。太激进的反调试会误伤正常玩家，哪怕自己写的小工具也可能被安全软件拦截。常规游戏更多采用“服务端行为检测+客户端轻量自检”，重点抓行为异常，比如访问内存频率过高、修改数据特征匹配外挂数据库、异常模块注入。内存变量修改只是表面，更重要的还是整个攻击链路的识别。
5. 实战避坑清单与延伸建议
5.1 我在踩坑后总结的6条经验
这些年我在逆向和防护两侧反复横跳，踩过一些坑，整理几条高频的，希望对你有用。
扫描类型选错，白忙半小时。找整数变量时选了2字节，或者把浮点当4字节扫，结果要么扫不到要么候选海量。多试几种类型进行交叉确认，比死磕一种强。
未初始化的地址不要乱写。CE里写内存前先看那一块的Protect属性，只读区域（
PAGE_READONLY）直接写会失败。要写就先VirtualProtect改成PAGE_EXECUTE_READWRITE，用完及时还原，不然可能破坏内存页属性导致崩溃。多线程程序里读写不是原子操作。你写一半，目标程序另一线程也写了同一地址，最终值可能是“你中有我”。写关键数据时务必让目标线程暂停，或者用
InterlockedExchange级别的方法。用外部进程API无法保证原子性，所以我做实验时一般把目标程序先挂起（在进程的主线程上暂停）再写。地址断点会让性能崩。CE的“找出什么改写了这个地址”本质是设置硬件断点，虽然好使，但一直开着会让游戏帧数暴降，某些程序还会因断点异常直接崩溃。定位到指令后立刻删断点。
修改内存后目标程序崩溃，多半是破坏数据结构了。很多新手改完数值后游戏闪退，以为是改错了数值，其实是把旁边对象、链表指针给覆盖了。写之前一定确认“目标地址+写入长度”都在合法堆区域内，且不会影响到相邻成员。我建议你先读4字节看改动后前后上下文是否合理。
同一份代码在Release和Debug下编译，内存布局天差地别。如果你写检测代码依赖某个固定偏移，一定要对发行版做特征定位，别拿Debug版分析结果直接上线。
5.2 进一步学习方向
到这里，内存变量修改技术的核心链路你已经走了一遍：搜索定位、指针追溯、外部读写、防御对抗。如果还想深入，或者说想把这些知识转成真正有用的能力，我建议按下面几个方向延展。
方向一是内存池与对象管理。很多游戏引擎不直接用系统堆分配，而是用自定义内存池，对象在池子里固定大小、紧凑排列。理解内存池后你能更快理解“偏移规律”，而做防护时也可以把混淆算法挂在池子上统筹。
方向二是反外挂检测工程。去读一些开源反作弊方案（不是让你抄代码，是学检测思路），理解内核回调、句柄检测、特征码匹配。你会发现内存修改只是一个前菜，真正的对抗在模块注入、驱动对抗层面。
方向三是用动态二进制插桩（如Frida）做更高级的实验。Frida配合调试器可以实时Hook函数、修改参数、追踪调用栈，比单纯改内存变量更灵活。它在移动端逆向和CTF里大量使用，学起来曲线略陡，但值得投入。
方向四是写一个自己的内存读写库。不为生产，只为练手。从OpenProcess到ReadProcessMemory，再到用Thread32First遍历线程、用VirtualQueryEx枚举内存块，最后配合一个简单的AOB（特征码）搜索算法。这个项目做完，你对进程内存模型的理解会比看书扎实得多。
我个人很推荐方向四。因为我就是在自己写流程、踩了一遍崩溃和权限问题之后，才真正理解什么叫“地址空间”、什么叫“页保护”、什么叫“句柄”。纸上得来终觉浅，内存变量这件事尤其如此：读十篇别人改内存的教程，不如自己对着一个1KB的可执行文件改一遍再修复崩溃来得深刻。
最后再分享一个小技巧，也是我工作里反复用的：无论进攻还是防守，先画一张“数据流图”再动手。把“数值从哪来、经过哪几个函数、最终存到哪里、谁在写谁在读”这条链路画明白，你会发现找到可修改点或者可检测点特别快，远远快于在CE里瞎扫一气。很多新手觉得逆向是拼运气的体力活，其实真正拼的是对程序数据流的理解深度。方向对了，一个断点能解决的事，绝不用五个扫描。有任何具体场景想聊，欢迎带着你的报错信息和内存截图来交流，我们一起把每个坑都踩明白。
