Let's Decode the Mystery Bytes [video]

# TL;DR 本文通过反汇编和 WinDbg 调试工具，揭示了在 x86 环境下 `calloc` 分配内存时，分配地址前出现的 8 个“神秘字节”实际上是 Windows 堆管理器的条目头部，包含当前块大小、前一块大小、未使用字节和标志等信息。 --- ## 背景：从上一个视频说起 在之前的视频《让我们来回答雷的问题》中，我们分析了 Raylib 作者 Ramon Santamaria 的一段代码：同样的 C 代码，分别编译为 x86 和 x64 目标时，运行结果出现了差异。差异点之一是在 x86 版本中，`calloc` 分配的两个字符串指针之间出现了额外的 8 个字节。当时我们只给出了基本解释，并承诺会深入讲解汇编层面的细节。本视频就是第一个后续内容——专门分析那 8 个字节究竟是什么。 如果你还没有看过上一个视频，请先观看（链接在描述中），本视频假定你已经知道那 8 个字节的生成模式以及在代码中的位置。 --- ## 方法：从 `calloc` 开始跟踪 ### 汇编层初步探查 我们打开调试器，在第一个 `calloc` 调用处设置断点，然后单步进入反汇编代码。在 x86 中，指令长度是可变的（与 ARM 不同）。我们依次看到了 `push`（压入参数）、`call`（调用函数），然后通过一个跳转表最终进入真正的 `calloc` 实现。 单步走完几个跳转后，我们发现 `calloc` 并非 C 运行时库自己实现的分配器，而是一个薄包装，直接调用 Windows 系统例程 `RtlAllocateHeap`（位于 NTDLL 中）。这是一个重要线索：意味着我们可以使用 Windows 内置的堆调试工具来观察分配行为，而不必纠结于 C 运行时库的内部实现。 ### 利用 WinDbg 的 `!heap` 命令 退出反汇编，回到字符串 02 分配之前，此时字符串 01 已经分配完毕，地址为 `0xE77320`。那 8 个神秘字节的地址就是 `0xE77318`。在 WinDbg 中执行： ``` !heap -x 0xE77320 ``` 输出显示： - 该地址属于唯一的进程堆。 - 大小（`size`）为 `0x10`（即 16 字节）。 - 上一块大小（`prev size`）为 `0x18`（24 字节）。 - 未使用（`unused`）为 `8` 字节。 - 还有一些标志位。 这些信息直接对应刚才看到的 8 个字节。很明显，Windows 堆管理器把这 8 个字节当作堆分配条目的头部，它包含当前块的大小、前一块的大小以及一些元数据。 --- ## 深入分析：堆条目结构 ### 使用 `dt` 命令显示结构体 WinDbg 可以加载 NTDLL 的调试符号，因此我们可以使用 `dt` 命令查看堆条目的类型。假设我们知道堆条目类型名为 `_HEAP_ENTRY`，但实际命令需要传地址。不过作者在视频中演示了 `dt _HEAP_ENTRY` 直接显示结构定义。结构大致如下（根据转录提炼）： - `Size`：当前块的大小（以 16 字节为单位？此处需要验证，但转录中提到 `size` 为 0x10 即 16 字节） - `PreviousSize`：前一块的大小 - `UnusedBytes`：未使用的字节数 - `SmallTagIndex` 等标志字段 正是这 8 个字节组成的结构体，使得堆管理器能够知道每个分配块的大小、前后块的地址，从而支持内存的分配与释放。 ### 具体数值解读 以我们得到的 8 个字节（地址 `0xE77318`）为例，它们的内容（十六进制）可能排列为： - 2 字节：`size`（当前块大小） - 2 字节：`prev size`（前一块大小） - 1 字节：`segment index` - 1 字节：`flags` - 1 字节：`unused bytes` - 1 字节：`small tag index` 但具体布局因 Windows 版本和堆实现而异。重要的是，这 8 个字节不是 C 语言层面产生的，而是 Windows 堆管理器自动附加到每个分配块前面的头部信息。 --- ## 验证：与猜测一致 我们最初的直觉是对的：这 8 个字节是分配块的头部，用于堆管理。因为 `calloc` 调用的是 Windows 堆，所以每个分配前都有这样一个条目。在 x64 版本中，由于 64 位堆管理器的结构不同（堆条目大小可能为 16 字节或其他），加上地址空间对齐和头部大小变化，导致 x64 代码中看不到同样的现象。 另外，通过 `!heap -x` 我们还能看到分配条目的完整信息，包括“未使用”字节数（`unused` 为 8），这恰好与 `calloc` 分配 8 字节字符串后堆管理器保留的空间一致。 --- ## 总结 那 8 个神秘字节根本不是错误，也不是编译器或链接器产生的 garbage，而是 Windows 堆管理器在每个分配块前放置的审计头部（heap entry header）。它的作用是记录当前块的大小、前一块的大小以及其他元数据，便于内存管理（如合并空闲块、检查堆损坏等）。 通过阅读汇编调用链，我们定位到 `RtlAllocateHeap`，进而使用 WinDbg 的 `!heap` 和 `dt` 命令，直观地看到了这个结构。整个过程展示了如何从“奇怪现象”出发，借助系统工具和底层调试手段，得出一个合理的解释。 --- Source: https://www.youtube.com/watch?v=GZqB4D_Do38