TL;DR. 每一代 Windows 都重写了 AppCompatCache 结构。XP 使用魔数 0xDEADBEEF 和固定的 552 字节记录；Server 2003、Vista/2008、Windows 7/2008 R2 和 Windows 8/8.1 各有自己的头部和条目布局。解析器必须根据头部魔数分支——不存在单一格式。
大多数 ShimCache 文档讲的是 Windows 10/11 布局。但事件响应人员仍会遇到 Windows 7 域控制器、Server 2008 R2 主机，以及偶尔的 XP 设备。这些主机上的磁盘结构有实质区别。这是逐版本参考。
为什么没有单一格式
ShimCache 是没有公开规范的 Windows 内部结构。随着 shim 基础设施演进，微软在各版本间不断重塑它。注册表值的名称和路径也变动过。健壮的解析器在读取任何一条条目之前，先从头部确定版本。
逐版本速查表
| Windows | 注册表值 | 头部魔数 | 条目形态 |
|---|---|---|---|
| XP（32 位） | …\AppCompatibility\AppCompatCache | 0xDEADBEEF | 固定 552 字节记录，最多 96 |
| Server 2003 | …\AppCompatCache\AppCompatCache | 0xBADC0FFE | 24 字节（x86）/ 32 字节（x64）条目 |
| Vista / 2008 | …\AppCompatCache\AppCompatCache | 0xBADC0FFE | 同 2003，标志不同 |
| Windows 7 / 2008 R2 | …\AppCompatCache\AppCompatCache | 0xBADC0FEE | 32 字节头部；条目带插入标志 |
| Windows 8 / 2012 | …\AppCompatCache\AppCompatCache | 0x00000080 | 变长条目签名 00ts |
| Windows 8.1 / 2012 R2 | …\AppCompatCache\AppCompatCache | 0x00000080 | 条目签名 10ts |
（Windows 10/11 的现代 10ts/00ts 布局在另一篇中详述。）
XP —— 异类
Windows XP 与之后的一切都不同：魔数 0xDEADBEEF、固定宽度 552 字节记录、96 条的硬性上限，以及填充到固定长度的 UTF-16 路径。它还存储了一个最后更新时间戳和一个文件大小字段，后续版本将其弃用。看到 0xDEADBEEF，你就在 XP 领域，任何现代解析逻辑都不适用。
Windows 7 —— 你最常遇到的
Windows 7 / Server 2008 R2 在 IR 中仍然常见。魔数 0xBADC0FEE、32 字节头部，每条记录包含路径、文件最后修改时间，以及——独具价值的——一个在 Windows 8 及以后被移除的执行标志。在 Windows 7 上，已置位的标志是对执行的合理（非绝对）佐证；不要把它外推到更新的系统，如ShimCache 是否证明执行所述。
8 / 8.1 过渡
Windows 8 引入了带逐条签名（00ts）的变长条目，8.1 将其升为 10ts。这是 Windows 10/11 格式的结构祖先，因此能处理 8.1 的解析器距离处理 10 已经不远。
不用工具链也能解析
Shimcache Parser 自动检测头部魔数，并分支到 XP、2003、Vista、7、8、8.1 和 10/11 的正确解码器——这样你无需部署旧工具就能在浏览器中读取旧版 SYSTEM 蜂巢。关于这些较旧系统的采集，见获取 SYSTEM 蜂巢。
延伸阅读
- Mandiant: leveraging the ShimCache —— 最初的逐版本逆向工程。
- Eric Zimmerman 的 AppCompatCacheParser —— 处理所有版本；很好的基准。