一、进程的地址空间

回顾：Fork、Execv、Exit

上一次课我们介绍了三个与进程相关的系统调用：Fork、Execv 和 Exit。从这周开始，我们进入学习操作系统 API 并用它们做一些有趣的程序。这是 UNIX 的设计；像 Windows 则有 Spawn 这样的 API，实际上 Linux 里也有一个类似 Spawn 的接口，比 Fork 更轻量，但这是后面要讲的故事。

UNIX 的设计很有趣。比如 Fork，我讲了一些有趣的应用——Zygote Process。你可以在做 DFS 的时候，当有多个分支要探索时，瞬间创建好几个状态的复制，每一个状态都知道自己要走哪个分支，于是它们可以并行地在多处理器系统上运行下去。

这边有一个典型的代码，讲解了怎样用 Fork、Execv 和 Exit 来创建子进程、让子进程运行另一个程序。父进程可以和子进程分离，继续做剩下的事情，也可以用 waitpid 等待子进程完成。大家只要有这个概念——我们可以做程序运行时状态的复制、重置和删除，剩下的如果想开发多进程并行程序，完全可以让 AI 来帮你完成。

Crazy OS 中的进程内存

我们今天继续上一次课讲的简单模型。上一节课我做了一个 Crazy OS，也许以后上操作系统课可以直接从这个 Crazy OS 开始把整学期的课讲完。在 Crazy OS 里我们观察到，进程是有内存的，里面有几个比较关键的变量。

比如 MemorySize——进程的内存大小是固定的。Memory 的 offset 是 0x8000，因为 Crazy OS 可以直接运行一个二进制文件，指令序列被加载到 0x8000，形成一个内存镜像。栈顶的指针指向高地址，往栈里 push 东西时从上往下增长。这就是一个进程的内存镜像，直接写在 struct proc 里。

所以每当你分配一个新的进程——无论是用 Fork 创建的，还是像 proc_init 直接无中生有——都会分配一个 struct proc，里面有一份内存的副本。内存有多大，这个数组就有多大，它是进程自己状态的一部分。

真实程序的地址空间

但对于实际的程序——终端里的程序或浏览器这些更复杂的程序——它不像 Crazy OS 那么简单。在计算机系统基础课上大家已经学过：代码（指令序列）在内存里，数据（各种全局变量）也在内存里。如果你写 int x = 1，这个 1 会出现在二进制文件里，你可以直接去编辑那个二进制文件看到初始化的变量值。如果是 int x = 0 或者定义一个 100 万大小的数组，那它不出现在二进制文件里，而是在 BSS section。

内存里有比大家想象的要多一些的内容，比 Crazy OS 复杂一些。这就是今天要讲的——进程的地址空间，也就是弄清楚进程的内存里到底有什么。

什么是进程的地址空间

AI 给了一个标准答案：进程的地址空间（Address Space）是操作系统为每个进程提供的一套独立的、连续的虚拟内存地址范围，因此也叫虚拟地址空间。

为什么要有地址空间呢？我们需要隔离和保护。上次课用 Fork 实现 DFS 的例子里，每 Fork 出来的进程，内存都是独立的一份拷贝。两个进程可以写同一个内存地址，但实际上写到了不同的物理内存上。这样便于扩展和管理，程序甚至可以以为自己占有一大片连续的内存。我可以一下子分配一个很大的内存，瞬间就分配完了，实际上操作系统并没有真正给我——就像画一个大饼，直到你真正需要的时候才把饼变出来。以及在隔离的前提下，允许有限的共享。

从直觉来理解地址空间

以上是教科书式的定义。但我们可以从更直观的角度来理解：我们都知道，进程由程序组成，程序里有指令，指令里有 load 和 store。这两条指令都需要一个地址和一个位宽。load/store 本质上就是从一个内存地址上读或写数据。内存是一个按字节寻址的字节序列，所谓的地址空间就是进程所有能够访问的那个字节序列。

在编程语言里，我们通过指针访问进程的地址空间。如果我有一个指针，我可以给它任何数值——任何一个 64 位整数都是一个合法的指针。我可以从这个指针读一个值，也可以往它写一个数据。在编程语言意义上这两个操作都是合理的，但在操作系统意义上未必允许——如果是空指针，程序就会发生 segmentation fault 然后 crash。

探索地址空间的小实验

如果我们有一个 C 程序，在 64 位机上，地址空间从 0 到 2^63 - 1。每个格子都可以有一个指针指向它，那么 load 它会有什么结果？store 它会有什么结果？如果你能回答清楚这个问题，你就真正理解了什么叫进程的地址空间。

volatile 的作用

在这之前做一个小 quiz：为什么代码里需要 volatile？volatile 可以用来修饰一个具有内存地址的东西，和 const 类似——const 说的是只能读不能写，volatile 说的是所有对这个内存的访问都不能优化。比如一个 load 不产生任何效果（没有把结果赋给任何变量），编译器可以直接删掉它。用了 volatile 修饰后就不会被优化了。你能出现 volatile 的地方都可以出现 const，这是一个小 trick。

用指针观察地址空间

让 AI 帮我们写一个 C 程序，用指针指向不同位置（代码、数据、栈），把这些地址打印出来，并从中读取一些数据。任何一个合法的符号——比如 main——都可以赋给一个函数指针，用 %p 把指针值打印出来。我可以把 main 函数所在位置的二进制代码给打印出来，甚至可以去反汇编，验证它和二进制文件里看到的是不是一样的。

运行这个程序，它会告诉你各个地址：比如 main 的地址是 0x5555...，全局变量的地址在比它稍高一点的位置（如 0x...ca00、0x...c80a08），栈上变量的地址在很高的位置。你还可以验证 main 函数的前 20 个字节——比如 fd 7b bb a9——和二进制文件里对应的字节一致（ARM64 和 x86 一样是小端的）。

你还可以让 AI 写程序，随机扫描进程的地址空间，看看还有没有一些你不知道的、但可以访问的区域。

地址空间里每一个字节是什么

计算机世界里没有魔法。我以前讲计算机系统基础时说过两个公理：第一，机器永远是对的——指令集的实现遵照 specification，哪怕处理器有 bug，它也遵守了某个 specification。第二，没有测过的代码都是错的。

推论就是：进程地址空间里每一个字节是什么，都应该是规定好的、可以理解的。

字节的含义

字节本身不带类型，完全取决于 CPU 的指令集体系结构如何解读：如果 program counter 在这里，它就会被译码执行；如果指令是 load/store，就会被当成数据来读写。

字节的位置

由链接器与可执行文件格式来决定。用 readelf -a 看一个二进制文件，会看到很多 PT_LOAD 的 program header，这些就是应该被加载到地址空间里的内容。静态链接的 binary，load 的地址完全确定；如果是 PIE（Position Independent Executable），可以加载到地址空间的任何位置，由操作系统决定。

所有的节（text、初始化数据、未初始化数据、只读数据等）放在地址空间的什么位置，是由链接器、可执行文件格式加上操作系统的地址随机化共同决定的。

ASLR

Linux 内核有一种叫 ASLR（Address Space Layout Randomization）的机制——每次程序加载到稍微不一样的地址，但都在某个范围附近。这可以让某些攻击更困难。所以你运行同一个程序多次，地址不一样；在 GDB 里运行，每次地址又一样了（因为 GDB 默认关闭了 ASLR）。

初始状态

在进程初始化好之后，它有一个初始的堆栈，里面有参数、环境变量、随机数种子等重要信息，还有一个叫 auxv（Auxiliary Vector）的结构。大家只要有这个概念，用到的时候能想起来就行。

用工具探索真实进程的地址空间

计算机科学里，你但凡能想到一件有意义的事情，就一定能做到——因为计算机从逻辑门开始就是人类设计的。所以一定有办法看到一个真实进程的地址空间到底什么样。

我准备了一个叫 "Process Address Space Explorer" 的命令行工具：从命令行接收一个 PID，解析它的地址空间，输出每个部分是什么；如果是可执行区域，再把第一个 KB 的内容反汇编出来。

运行后，你会看到：对于一个静态链接的二进制文件，从 0x400000 开始有一段可读可执行的区域，映射到了 a.out。在地址空间高位，栈附近还有 vvar 和 vdso，然后才是栈。

vdso 和 vvar

即使是最小的应用程序，地址空间里也不只有栈和 a.out，还有 vdso 和 vvar。这是 Linux 内核提供的机制，可以让你在不陷入内核的情况下完成某些系统调用。比如 gettimeofday——如果调用非常频繁，每次都进入内核会浪费很多时钟周期。于是操作系统在每个进程的地址空间里放一段代码（vdso）和一段数据（vvar），通过 CPU 内部的精密定时器加上操作系统维护的秒级计时器，就可以不进入内核完成获取时间的操作。同理，getpid 也可以直接从这里读取。

实现原理

这个工具怎么实现的呢？它读取 /proc/<PID>/maps 文件来分析进程的内存区域，识别每个区域的类型，然后对可执行区域使用 Capstone 进行反汇编。你自己也可以去看 /proc/<PID>/maps——procfs 里面有进程完整地址空间的镜像：从哪里开始、到哪里结束、每一块的访问权限是什么，以及如果映射到了文件的话具体是哪个文件（libc、libm、libgcc 等等），还有 vvar 和 vdso。

二、mmap

需要一个系统调用来修改地址空间

现在我们知道了一个最小程序的地址空间里至少有这么多东西。那如果我不是写一个死循环，而是一个复杂程序——比如要调用 malloc 分配一大块内存——该怎么办？

初始时地址空间里只有 a.out 和栈，其余区域都是 dead zone——访问就会 segmentation fault。进程自己做不了的事情都必须请求操作系统。所以应该有一个系统调用来配置或修改进程的地址空间，帮我们在 dead zone 里分配一块可读可写的内存。

早期的 brk / sbrk

UNIX 最早的答案是 brk / sbrk（change data segment size）。以前的 a.out 就是 code、data 和 BSS，BSS 的末端就叫 break。sbrk 就是移动这个 break：要更多内存就往上移，释放内存就往下移。但今天这个系统调用有点不够用了。

mmap 系统调用

我们有一个更先进、把所有地址空间相关功能集合在一起的系统调用——mmap。

进程的地址空间就是一块一块可以访问的内存。mmap 的功能是：从地址空间里找一块区域，指定大小和权限，然后把它映射到一个文件或新分配的匿名内存。有分配就有回收——munmap 负责释放，甚至可以只释放一部分。

比如我用 MAP_ANONYMOUS 映射一段匿名页——所谓匿名就是分配一段初始值为零的内存。我可以分配 1 GB 的内存，然后把前 500 MB 用 munmap 释放掉。我还可以用 mprotect 修改已持有内存的访问权限——比如把只读内存变成可读可写，或者把数据内存变成可执行。

mmap 分配大内存的实验

我用 mmap 直接分配 8 GB 的内存——在只有 8 GB 物理内存的树莓派上，系统本身和其他程序也要消耗内存，理论上不应该分配得出来。但实际上这个调用可以成功，而且只用了 1.62 毫秒。我真的可以在 2 GB、4 GB、7 GB 的位置去读写。

为什么？因为 mmap 只是修改了 VR 眼镜的配置——操作系统做了一个标记说"这块内存属于你"，只有在你真正 load/store 的时候，才会真正把物理内存分配给你。而 load/store 一次只能看几个字节，视野非常小，所以操作系统可以做到延迟分配。

用 strace 可以看到分配 8 GB 内存时执行的系统调用：mmap 的参数是可读可写、MAP_PRIVATE | MAP_ANONYMOUS，大小就是 8 GB，返回了一个地址，和 printf 打印出来的完全一致。

mmap 映射文件

因为 UNIX 的 "everything is a file" 理念，mmap 还可以带一个文件描述符参数——打开一个文件后，把文件的一部分直接映射到进程的地址空间里。

这非常有用。比如我可以把一个 128 GB 的磁盘设备（/dev/sda）整个映射到内存里——64 位地址空间够大，做得到。映射后就是一个指针，我用一个 memset 就可以抹掉整个磁盘。（我真的抹掉过一次，结果下一节课老师直接教学事故了，后面再也不敢做这种危险操作了。那个还原卡的设计是有缺陷的。）

mmap 的更多应用

• Memory-Mapped I/O：可以把 /dev/gpiomem 映射到进程地址空间，用指针写 0 和 1 来控制 GPIO 引脚的高低电平。
• 共享内存：配合 shm_open 返回一个文件描述符，再用 mmap 在多个进程之间共享同一段内存。
• 动态生成代码：用 mmap 分配内存，再用 mprotect 把它标记为可执行。内存本身不带类型——如果 PC 跳转到一个可读可执行的地方，它就会被执行。这用来实现 JIT（Just-In-Time）编译器，比如浏览器的 JavaScript 引擎会一边运行、一边把脚本语言编译成机器码。

mmap 参数总结

mmap 接收几个参数：

• addr：建议把它映射到这个地址（不保证，有 MAP_FIXED flag 可以强制）。
• length：映射的长度。
• prot：权限——可读、可写、可执行。
• flags：映射方式——MAP_ANONYMOUS（匿名，分配全零内存）或指定文件描述符和 offset 来映射文件。

就 mmap、munmap、mprotect 这三个系统调用，构成了进程所有的地址空间管理。不管是第三方库、malloc 分配的内存，还是 ELF 文件里指定的段，理论上都可以用这一组系统调用来实现。

三、入侵进程的地址空间

我们已经做过了

你们没有意识到，今天第一个例子——探索进程的地址空间——我们就做了一件了不起的事情：从命令行接收一个 PID，解析了它的地址空间，还把数据读出来了。这本身是一件非常"可怕"的事——从一个进程去读另一个进程的内存。以前谁干这件事？调试器。

调试器本身是一个程序，它要读另一个程序的内存。在过去为了实现它，你需要读很多手册、对操作系统有很好的了解。而今天你甚至在不经意间就把它搞定了。

GDB 是怎么实现断点的

GDB 打断点的流程是这样的：假设要在某条指令上打断点，GDB 会先用 mprotect 把那段内存变成可读可写可执行，然后把那条指令改成一条 int 3（x86 上的一字节中断指令）。程序继续执行，碰到 int 3 会产生异常，通过 ptrace 系统调用把控制权转给 GDB。GDB 再把指令 patch 回去，放程序继续执行。GDB 就是用 mmap 系列和 ptrace 两个系统调用来实现的。

以前这需要花一节课来讲。今天你可以回家让 AI 帮你做一个最小的 GDB——在一个地方打断点并实现一个功能，分分钟就能完成。

Game Genie：物理层面的金手指

在更早的时候，个人电脑还没有 MMU，就有一个天才的产品叫 Game Genie。

游戏卡带本质上是一个存储器（大的字节数组），插入卡舱就相当于把 ROM 映射到游戏机的地址空间。Firmware 启动后跳转到 ROM 上的代码执行，游戏就跑起来了。

Game Genie 的创意在于：卡带和接口之间有空间，导线是裸露的，所以它可以在卡带前面加一个外挂设备——一个简单的可编程逻辑。它会劫持 Firmware 的跳转，先进入 Game Genie 界面，允许你输入作弊码（比如 8 个字符）。这个作弊码被写入一个 lookup table，工作原理是：如果地址等于 X 且数据等于 Y，就把数据改成 Z。

比如游戏初始化时 life = 3（马里奥有三条命），这个 3 是指令里的立即数。只要在 lookup table 里找到那条指令的地址，把 3 换成 99，你就有 99 条命了。这才是真正意义上的"外挂"——在物理导线上做 patch。

扫描内存的游戏修改器

后来有了 Windows 和更多游戏，你想要一个对任何游戏都生效的金手指。原理不难：

1. 进入游戏时经验值是 4950，扫描内存里所有值为 4950 的地址，找到比如 100 个候选。
2. 出门打一个怪，经验值变成 5100，再扫描那些候选地址，保留值变为 5100 的，排除没变的（比如指针）。
3. 不断重复，最终锁定经验值的真实地址。

一旦找到，就可以直接修改。这就是基于内存扫描的游戏修改器的原理。

演示：用游戏修改器修改 DOS 游戏

我在 DOSBox 里运行了一个老游戏（红色警戒一代），用我做的游戏修改器——本质上就是前面探索进程地址空间的程序加上 /proc/<PID>/mem 文件。这个文件代表了进程的完整地址空间，可以读也可以写。

找到 DOSBox 进程后搜索 16 位的值 10000（金钱），找到 392 个匹配。造一个 90 块的围墙，金钱变成 9910，再次扫描缩小范围，最终定位到目标地址并修改它。

当然也有失败的情况——有时只找到了显示用的金额，而没找到实际逻辑中的金额。这就是基于内存的游戏修改器有趣的地方。

扫描内存方法的局限

如果游戏的代码写成每次更新逻辑都创建一个新的 state 对象——每更新一次，地址就变了——那简单的扫描内存方式就不管用了。我们需要更深入地理解程序的语义。

其实我们已经做过类似的事情——之前展示汉诺塔的时候，用调试器截持控制流、读取数据流、打印状态，这本身就是一个"游戏外挂程序"。只要能截持控制流或数据流，加上自己的逻辑，理论上可以实现任何一种游戏外挂。

其他类型的外挂

• 透视外挂：游戏里所有人物都是三角形组成的，图形渲染管线根据 Z 轴做深度遮挡。只要把人物的三角形提取出来，在最近距离重新画一遍，就能透视看到所有人。
• 变速齿轮：程序通过系统调用（gettimeofday、sleep、alarm）感知时间。在这些函数入口插断点或替换实现，把 sleep 时间除以 10、把返回的时间加速 10 倍，游戏就变快了。在计算时间远小于 sleep 时间的情况下，这个方法非常有效。

DMA 外挂

更终极的外挂是 DMA 外挂——不通过操作系统，而是在物理总线上加一个设备，不停地把游戏内存拷贝到另一台计算机或 FPGA 板子上（比如每秒 30 次）。这几乎无法检测和防范。

未来还可以用 CXL 这样的高速内存互联技术做 Double Write Memory Mirror——卖给你的"内存条"除了内存接口还有另一个接口，所有写入数据都通过 CXL 技术做多副本。这不仅可以在数据中心做容错，也可以成为 Copilot 的基础——你的电脑所有内存状态都被镜像出来，AI 可以实时知道你的电脑在做什么。

畅想：AI 时代的可能性

有了入侵进程地址空间的能力和 AI 的帮助，我们可以做很多疯狂的事情：

• 老游戏重制：用 AI 逆向老游戏的逻辑，在 DOSBox 运行老游戏的基础上加一层类似 DLSS 的神经网络渲染，生成现代画面，但游戏逻辑不变。
• AI 游戏辅助：采集游戏画面做图像分割，只要有一个像素 AI 就能识别人物，在另一个屏幕上提示你怎么操作。
• 学习 Copilot：不止是游戏，你学任何东西都可以用这个模式——AI 实时分析你的操作并给出建议。

回到核心

所有这些有趣的内容，在操作系统的意义上就是 mmap、munmap、mprotect 这三个系统调用，再加上 /proc/<PID>/maps（查看地址空间布局）和 /proc/<PID>/mem（读写进程内存）。

游戏修改器的实现：通过打开目标进程的 /proc/<PID>/mem 文件获取文件描述符，用 lseek 移动游标到目标地址，再用 read / write 读写内存。总结就是：通过 procfs 接口直接读写其他进程的内存。

你只要有正确的概念——知道进程地址空间是什么、知道所有合理的事情都能办到——能够提出正确的问题，AI 就可以帮你把剩下的事情搞定。