修改器本质是普通exe？两个程序带你玩转跨进程内存读写

我以前也总觉得，修改器这种东西肯定特别玄乎，什么“注入”、“Hook”、“内核驱动”满天飞。直到我亲手把 Cheat Engine 改内存的过程拆开，才发现一个反直觉的事实：修改器的本质，就是一个再普通不过的 exe 程序。它跟你双击打开的记事本、计算器没有本质区别，只是多调用了几个 Windows 系统自带的 API，就能跨进程读写别的程序内存。这篇文章我不谈理论，直接用两个 exe 完整演示这套链路：一个 exe 当“靶子”，把自己内存里的某个数值暴露出来；另一个 exe 当“修改器”，跨进程把这个数值改掉。整个过程从写代码、打包到联调全部走一遍，适合刚接触逆向、想做内存修改器、或者单纯想知道 CE 背后原理的朋友。

1. 先拆穿“修改器神话”：它凭什么能改别的程序

很多人对修改器的第一印象就是：它是不是偷偷注入到游戏进程里了？是不是像病毒一样寄生在目标程序内部？其实完全不是。绝大多数修改器就是一个独立运行的普通程序，它以“外部进程”的身份，向操作系统申请对另一个进程内存的读写权限。

这个逻辑的起点，是 Windows 的进程隔离机制。每个进程被分配了一个独立的虚拟地址空间，默认情况下，进程 A 访问不到进程 B 的任何数据。这种隔离是系统稳定的基础，也防止程序之间互相干扰。但操作系统同时也留了几扇“官方后门”，其中最关键的就是三个 API：

• OpenProcess：按 PID 打开目标进程，拿到一个进程句柄。相当于向系统申请一把“钥匙”。
• ReadProcessMemory：通过句柄，读取目标进程某块内存地址的数据。
• WriteProcessMemory：通过句柄，把数据写入目标进程某块内存地址。

注意，这几个 API 本身没有任何“魔法”，它们就是 kernel32.dll 里导出的普通函数。任何 Windows 程序都可以调用它们，只要你有权限。而修改器做的事情，就是把这些 API 按顺序调用一遍：打开进程、读内存、写内存。

这里有个概念要澄清：打开进程拿到的是“句柄”，而不是把代码塞进目标进程。修改器全程活在”目标进程外部”，但这个“外部程序”通过系统 API，拿到了读取和写入目标进程内部内存的权限。打个比方，你住在一个封闭小区里，别人进不来，但物业管理员有一张万能门禁卡，他能直接打开你家门。修改器就是那个拿着门禁卡的人，而门禁卡就是 OpenProcess 返回的句柄。

但门禁卡也不是随便发的。Windows 会根据进程权限、安全描述符和调用者身份来决定到底给不给你开门的权利。这也是为什么修改器经常需要“以管理员身份运行”的关键原因。如果目标进程是管理员权限运行，而修改器是普通权限，OpenProcess 大概率会返回失败。

OpenProcess 的第一个参数 dwDesiredAccess 尤其重要，它决定你要申请哪些操作权限。最常见的几个权限位如下：

在我下面的 Demo 里，读取内存时申请 PROCESS_VM_READ | PROCESS_QUERY_INFORMATION，写入内存时申请 PROCESS_VM_WRITE | PROCESS_VM_OPERATION | PROCESS_QUERY_INFORMATION。权限给得越全，越容易被打开，但本着最小权限原则，能干活就行，别一上来就 PROCESS_ALL_ACCESS。

还有一个容易被忽视的点：ReadProcessMemory 和 WriteProcessMemory 的地址参数，是目标进程的虚拟地址，不是修改器进程自己的地址。编译器和操作系统不会自动帮你“翻译”地址，这个地址必须是你预先知道的目标进程内部地址。那地址从哪来？这就引出了我们的第一个 exe。

2. 第一个 exe：目标程序 demo_target.exe

为了让两个 exe 的实验足够简单可复现，我把“靶子程序”做成了一个极其直白的控制台程序：它内部有一个变量 gold，初始值是 100，每一秒打印一次当前值。为了让修改器能定位到这个变量，程序启动时会把 gold 在内存中的地址打印出来。

这里有一个技术选型问题：像这种演示程序，用 C/C++ 写当然最正宗，一个 int 全局变量的地址固定且连续，内存布局清晰。但对于很多刚开始接触这个领域的朋友来说，安装 Visual Studio 或 MinGW 本身就是一关。所以我这里选择用 Python 来写目标程序，配合 ctypes 创建一个 C 语言级别的 32 位无符号整数对象，再由 PyInstaller 打包成 exe。这样既规避了装编译器的门槛，又能保证内存结构足够“原始”，不会牵扯到 Python 对象头那些复杂东西。

目标程序的完整代码如下：

python复制import ctypes
import os
import time

def main():
    print("=== demo_target.exe 已启动 ===")
    print(f"当前进程 PID: {os.getpid()}")

    # 创建一个 C 语言的 uint32 变量，初始值 100
    gold = ctypes.c_uint32(100)

    # 拿到这个变量在内存中的地址
    addr = ctypes.addressof(gold)

    print(f"gold 变量地址: 0x{addr:X}")
    print("把上面的地址记下来，待会儿修改器要用。")
    print("---------------------------------------------------")

    i = 0
    try:
        while True:
            print(f"[t+{i:03d}s] 当前金币数: {gold.value}")
            time.sleep(1)
            i += 1
    except KeyboardInterrupt:
        print("\n程序已退出。")

if __name__ == "__main__":
    main()

关键点在于 ctypes.c_uint32(100)。它创建的并不是 Python 普通的 int，而是一块真实的 C 内存，大小固定 4 字节，存储值 100。ctypes.addressof() 能拿到这块内存的起始地址。这个地址在目标程序运行期间是稳定的，而且因为 gold 对象一直在函数作用域内被循环引用，不会被垃圾回收器移动或释放。

用 PyInstaller 把它打包成 exe：

bash复制pip install pyinstaller
pyinstaller -F -c target.py

打包完成后，dist/target.exe 就是我们需要的第一个 exe。双击运行，你会看到类似这样的输出：

text复制=== demo_target.exe 已启动 ===
当前进程 PID: 12345
gold 变量地址: 0x1F2E3D4C
---------------------------------------------------
[t+000s] 当前金币数: 100
[t+001s] 当前金币数: 100
[t+002s] 当前金币数: 100

这里特别要说明的是，0x1F2E3D4C 这个地址是每次运行都会变的，因为 Windows 从 ASLR 机制到堆内存分配策略，都不会让你每次启动时拿到同一个地址。所以不要指望把地址写死在修改器里，正确做法是每次启动目标程序后，都把新打印的地址记下来喂给修改器。这个特点也正好解释了第 5 章里为什么真实修改器要依赖“搜索 + 偏移”而不是“固定地址”。

有人可能会问：为什么不能直接在目标程序里写一个“全局变量”然后固定地址？在关闭 ASLR 的编译程序里确实可以，但用 Python 打包出来的进程不归我们控制，地址漂移是常态。反而正好借这个“不稳定”，还原了真实游戏里修改器面对的动态环境。

3. 第二个 exe：修改器 memory_modifier.exe

第二个 exe 才是重头戏。它的任务有三个：

1. 根据用户输入的进程名或 PID，找到目标进程。
2. 通过 OpenProcess 拿到句柄。
3. 用 ReadProcessMemory 和 WriteProcessMemory 读取、修改目标内存。

这个 exe 我同样用 Python 写，但全程通过 ctypes 直接调用 Windows API，不依赖任何第三方库。代码看起来比目标程序长，是因为要手动声明 API 的函数签名和结构体，但每一步都对应一个明确的 Windows 概念。

python复制import ctypes
import ctypes.wintypes as wt

kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)

# ---------- 权限常量 ----------
PROCESS_QUERY_INFORMATION = 0x0400
PROCESS_VM_READ = 0x0010
PROCESS_VM_WRITE = 0x0020
PROCESS_VM_OPERATION = 0x0008

# ---------- API 声明 ----------
OpenProcess = kernel32.OpenProcess
OpenProcess.argtypes = [wt.DWORD, wt.BOOL, wt.DWORD]
OpenProcess.restype = wt.HANDLE

ReadProcessMemory = kernel32.ReadProcessMemory
ReadProcessMemory.argtypes = [
    wt.HANDLE,          # hProcess
    ctypes.c_void_p,    # lpBaseAddress
    ctypes.c_void_p,    # lpBuffer
    ctypes.c_size_t,    # nSize
    ctypes.POINTER(ctypes.c_size_t)  # lpNumberOfBytesRead
]
ReadProcessMemory.restype = wt.BOOL

WriteProcessMemory = kernel32.WriteProcessMemory
WriteProcessMemory.argtypes = [
    wt.HANDLE,          # hProcess
    ctypes.c_void_p,    # lpBaseAddress
    ctypes.c_void_p,    # lpBuffer
    ctypes.c_size_t,    # nSize
    ctypes.POINTER(ctypes.c_size_t)  # lpNumberOfBytesWritten
]
WriteProcessMemory.restype = wt.BOOL

CloseHandle = kernel32.CloseHandle
CloseHandle.argtypes = [wt.HANDLE]
CloseHandle.restype = wt.BOOL

# ---------- 进程遍历需要的结构体和函数 ----------
TH32CS_SNAPPROCESS = 0x00000002
INVALID_HANDLE_VALUE = ctypes.c_void_p(-1).value

class PROCESSENTRY32(ctypes.Structure):
    _fields_ = [
        ("dwSize", wt.DWORD),
        ("cntUsage", wt.DWORD),
        ("th32ProcessID", wt.DWORD),
        ("th32DefaultHeapID", ctypes.c_size_t),
        ("th32ModuleID", wt.DWORD),
        ("cntThreads", wt.DWORD),
        ("th32ParentProcessID", wt.DWORD),
        ("pcPriClassBase", ctypes.c_long),
        ("dwFlags", wt.DWORD),
        ("szExeFile", ctypes.c_char * 260),
    ]

CreateToolhelp32Snapshot = kernel32.CreateToolhelp32Snapshot
CreateToolhelp32Snapshot.argtypes = [wt.DWORD, wt.DWORD]
CreateToolhelp32Snapshot.restype = wt.HANDLE

Process32First = kernel32.Process32FirstA
Process32First.argtypes = [wt.HANDLE, ctypes.POINTER(PROCESSENTRY32)]
Process32First.restype = wt.BOOL

Process32Next = kernel32.Process32NextA
Process32Next.argtypes = [wt.HANDLE, ctypes.POINTER(PROCESSENTRY32)]
Process32Next.restype = wt.BOOL

def find_pid_by_name(name: str) -> int:
    target = name.lower()
    snap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0)
    if snap == INVALID_HANDLE_VALUE:
        raise RuntimeError(f"CreateToolhelp32Snapshot 失败，错误码 {ctypes.get_last_error()}")

    entry = PROCESSENTRY32()
    entry.dwSize = ctypes.sizeof(PROCESSENTRY32)

    ok = Process32First(snap, ctypes.byref(entry))
    while ok:
        exe_name = entry.szExeFile.decode("utf-8", errors="ignore").lower()
        if exe_name == target:
            CloseHandle(snap)
            return int(entry.th32ProcessID)
        ok = Process32Next(snap, ctypes.byref(entry))

    CloseHandle(snap)
    raise RuntimeError(f"找不到进程: {name}")

# ---------- 读取 / 写入内存 ----------
def read_uint32(pid: int, address: int) -> int:
    h = OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, False, pid)
    if not h:
        err = ctypes.get_last_error()
        raise RuntimeError(f"OpenProcess 失败，错误码 {err} (0x{err:X})")

    buf = ctypes.c_uint32(0)
    bytes_read = ctypes.c_size_t(0)
    ok = ReadProcessMemory(
        h,
        ctypes.c_void_p(address),
        ctypes.byref(buf),
        ctypes.sizeof(buf),
        ctypes.byref(bytes_read),
    )
    CloseHandle(h)

    if not ok:
        err = ctypes.get_last_error()
        raise RuntimeError(f"ReadProcessMemory 失败，错误码 {err} (0x{err:X})")
    return buf.value

def write_uint32(pid: int, address: int, value: int) -> None:
    h = OpenProcess(
        PROCESS_VM_WRITE | PROCESS_VM_OPERATION | PROCESS_QUERY_INFORMATION,
        False,
        pid,
    )
    if not h:
        err = ctypes.get_last_error()
        raise RuntimeError(f"OpenProcess 失败，错误码 {err} (0x{err:X})")

    val = ctypes.c_uint32(value)
    bytes_written = ctypes.c_size_t(0)
    ok = WriteProcessMemory(
        h,
        ctypes.c_void_p(address),
        ctypes.byref(val),
        ctypes.sizeof(val),
        ctypes.byref(bytes_written),
    )
    CloseHandle(h)

    if not ok:
        err = ctypes.get_last_error()
        raise RuntimeError(f"WriteProcessMemory 失败，错误码 {err} (0x{err:X})")

# ---------- 交互逻辑 ----------
def resolve_pid(text: str) -> int:
    text = text.strip()
    if text.isdigit():
        return int(text)
    return find_pid_by_name(text)

def main():
    print("=== memory_modifier.exe ===")
    target = input("目标进程名或PID: ").strip()
    addr_text = input("目标内存地址(十六进制，例如 0x1F2E3D4C): ").strip()
    new_value = int(input("要写入的整数(0~4294967295): ").strip())

    try:
        pid = resolve_pid(target)
        addr = int(addr_text, 16)

        print(f"目标进程 PID: {pid}")
        print(f"目标地址: 0x{addr:X}")

        old_value = read_uint32(pid, addr)
        print(f"写入前该地址的值: {old_value}")

        write_uint32(pid, addr, new_value)

        after_value = read_uint32(pid, addr)
        print(f"写入后该地址的值: {after_value}")

        if after_value == new_value:
            print("修改成功！")
        else:
            print("写入后读取结果不一致，请检查地址或数值范围。")

    except Exception as exc:
        print("操作失败:", exc)
        input("按回车退出...")
        return

if __name__ == "__main__":
    main()

这里踩过的一个典型坑是 API 函数签名声明。ReadProcessMemory 的 lpBaseAddress 和 lpBuffer 在 C 语言里是不同类型的指针，如果不明确声明 argtypes，ctypes 默认会把 Python 整数当成 32 位整数传进去，在 64 位系统上会直接丢掉高 32 位地址。所以必须用 ctypes.c_void_p 显式包装地址，用 ctypes.byref(buf) 传缓冲区指针。类似的坑还有 OpenProcess 返回的句柄类型，如果声明成整数，某些场景下也会出问题。

在按进程名查找 PID 时，我用了 Process32FirstA 这种 A 版本 API，配合 ctypes.c_char * 260。这样好处是字符串处理简单，进程名基本都用 ASCII 字符。如果你要处理中文路径或中文进程名，建议换成 Process32FirstW 并把 szExeFile 声明为 ctypes.c_wchar * 260。

打包命令和目标程序完全一样：

bash复制pyinstaller -F -c modifier.py

打包完就得到 dist/modifier.exe，也就是我们的第二个 exe。

4. 两个 exe 联调实测：修改内存那一刻发生了什么

代码都就绪后，我们把两个 exe 放在同一台 Windows 机器上，完整跑一遍联调。整个过程大概是这样：

如果一切顺利，你会看到目标程序的输出突然从 [t+005s] 当前金币数: 100 变成 [t+006s] 当前金币数: 9999。这个瞬间非常有意思——一个完全独立的进程，被另一个进程从外面改写了自己内存里的数据。

从系统内部看，这一连串操作到底是怎么发生的？关键在于虚拟内存地址的映射。目标程序里 gold 变量映射到物理内存的某个位置，但这个位置只有操作系统知道。修改器进程通过 OpenProcess 拿到句柄后，再调用 ReadProcessMemory，系统会拿着这个句柄去查目标进程的页表，找到 0x1F2E3D4C 对应的物理页，然后把 4 个字节的数据复制到修改器进程的缓冲区里。写入过程则是反过来：把修改器缓冲区里的 4 个字节，根据目标进程的地址映射，写进物理内存。所以修改器并没有“进入”目标进程，它只是通过系统调用间接操作了目标进程的虚拟地址空间。

联调过程中最容易出问题的几个点，我挨个说一下。

第一是权限问题。如果 demo_target.exe 是以普通权限运行的，修改器也普通权限，一般没问题。但如果目标程序是以管理员权限运行的（PyInstaller 默认不带管理员权限，所以这个 Demo 里很少遇到），修改器必须也以管理员身份运行，否则 OpenProcess 会返回错误码 5，也就是 ACCESS_DENIED。在 Windows 上，权限边界不是闹着玩的，跨权限打开进程会被系统直接拒绝。

第二是 32 位和 64 位不匹配。如果目标程序是 32 位进程，修改器是 64 位进程，读取依然可能成功，因为 ReadProcessMemory 支持跨位数读取。但反过来，64 位进程的地址高 32 位非零，32 位修改器无法表达，就不能正常工作。为了省事，两个 exe 都打成 64 位最常见。

第三是杀毒软件误报。PyInstaller 打包的 exe 体积大、入口代码有 Python 运行时特征，经常会触发杀软误报。加上修改器会调用 WriteProcessMemory 修改其他进程内存，这种行为和恶意软件有重合，误报概率更高。遇到这种情况，自行决定是加白名单还是换打包参数，但不要因为怕误报就去研究什么绕过检测的“免杀”技巧，那是法律的灰色地带，也偏离了学习技术的初衷。

安全边界这块我必须多说一句。这篇文章演示的所有内存读写操作，目标都是你自己编写、自己启动、并且明确授权做实验的程序。拿修改器去改别人开发的软件、游戏，轻则违反软件用户协议，重则触犯法律法规中的破坏计算机系统或非法获取计算机数据条款。技术本身是中性的，但使用边界必须自己把住。

5. 从固定地址到真实修改器：为什么 CE 要做“搜索 + 偏移”

一旦你跑通了上面这个 Demo，自然会产生一个疑问：Demo 里地址是目标程序自己打印出来的，真实游戏里我啥也不知道，地址是动态的，那 CE 这种修改器是怎么找到“金币”的？

答案就是“数值扫描”，也就是 CE 里最核心的“首次扫描 / 再次扫描”功能。它的思路非常朴素：先不知道目标变量的地址，但我知道目标变量的当前值是 100。CE 先扫描整个目标进程的可读写内存，把所有值为 100 的 4 字节数据的位置都记下来，这一步可能有几十万个结果。然后你在游戏里让金币变成 50，再点“再次扫描”，CE 在上次的结果里筛出当前值为 50 的地址。反复这么筛几轮，几万、几十个、几个，最后剩下几个候选地址，其中一个就是真正的金币数据。

但扫描完成后，地址还是固定的吗？不一定。很多游戏在启动时动态分配内存，每次运行分配到的地址都可能不同。如果修改器把找到的地址写死，下次游戏重启就失效了。真实世界的修改器解决办法是“指针扫描”。原理是：动态分配的内存地址虽然会变，但总有一个“静态的根”，比如某个全局指针变量，它的地址固定，而它存的值才是动态内存的真实地址。游戏逻辑通过“多级指针”一层层跳转，最终才访问到金币。修改器只要找到这串“指针链”，每次启动游戏后沿着这条链重新计算一次最终地址，就能稳定修改了。

再往后走，外部读写的修改器还有两个明显的性能瓶颈：一是每次 ReadProcessMemory 都是一次系统调用，频繁读写大量数据时开销很大；二是它毕竟只能“看”和“改”，没有办法在目标进程内部执行任意逻辑。所以更进阶的修改器会走“注入”路线，把 DLL 注入到目标进程内，在进程内直接读取变量、乃至 Hook 函数。但注意，这已经是另一套完全不同的技术栈了，而且很多游戏的反作弊系统对注入行为极度敏感，一不小心就会触发封禁。

回到这次的 Demo 本身，我认为最有价值的收获不是“我写出了修改器”，而是理解了 CE 底层到底在做什么。CE 本质上也是一个普通的 exe，它跟你自己写的这个 modifier.exe 没有任何本质区别，只是把“扫描、筛选、指针追迹、脚本执行”这些操作封装成了可视化的图形界面。只要你理解 OpenProcess 和 ReadProcessMemory 这两个 API 在做什么，CE 在你眼里就不再是一个黑盒了。

如果你还想继续深入，我建议按这个顺序往下走：先完善自己的扫描器，循环遍历进程内存区域，把 VirtualQueryEx 也用起来；然后尝试写一个简单的“多级指针追踪”工具；最后再去研究 DLL 注入和 Hook，理解内挂与外挂的差异。每一步都比上一步更复杂，但每一步都会让你对操作系统的内存管理有更直观的认识。

最后分享一个我实际折腾下来的体会：这个 Demo 最值得跑通的地方，不是那个“改数成功”的结果，而是理解“为什么目标程序打印的地址每次运行都不一样”。当你真正面对一个动态分配的地址，用搜索或指针把它定位出来的那一刻，你对修改器技术的理解才算完成了闭环。