c++如何读取并修改PE文件的版本资源信息【深度】

C++如何读取并修改PE文件的版本资源信息【深度】

PE版本资源结构在哪找

如果你在Windows PE文件中寻找版本信息，那它一定藏在资源节（.rsrc）里。具体来说，它的资源类型是 RT_VERSION，名称通常是 1（也就是主版本块），语言ID则常见为 0x409（美国英语）或 0x0（LANG_NEUTRAL）。

这里有个关键点：版本资源可不是一个简单的字符串表。它是一个嵌套的二进制结构。最外层是 VS_VERSIONINFO，里面包裹着 StringFileInfo 和 VarFileInfo，再往下深入，才是我们真正关心的键值对，比如 FileVersion 和 ProductName。

直接调用 BeginUpdateResource 和 UpdateResource 来修改版本资源？这条路几乎注定失败。原因在于，这些API要求你提供的是一个完整、严格对齐、大小精确的资源数据块。而版本资源的字节对齐要求极为苛刻——所有字段必须按 WORD 边界对齐，字符串必须以双字节零终止，长度字段还得重新计算。手动构造这个结构，稍有不慎就会出错。

用 UpdateResource 替换整个版本块的实操要点

想要稳妥地修改版本信息，必须遵循一套标准流程：提取原始资源 → 解析结构 → 修改指定字符串 → 重新序列化 → 最后写入。以下是几个关键步骤，缺一不可：

• 获取原始数据：使用 FindResource 和 LoadResource 获取 RT_VERSION 数据的指针。注意，这里拿到的是未经解压的原始内存块，包含了完整的头部和所有子块。
• 精准定位：手动解析 VS_VERSIONINFO 头部，一路向下找到 StringTable（它位于 StringFileInfo 之下），然后定位到目标 String 子块，比如键名为 FileVersion 的那一项。
• 谨慎修改：修改字符串内容时，必须确保新字符串的UTF-16长度（包含结尾的两个 \0）不超过原 String 块分配的空间。如果新字符串更长，那就必须重建整个 StringTable，并同步更新所有相关的长度字段（如 wLength、wValueLength 等）。
• 严格对齐：重新打包时，每个子结构的起始地址必须是 WORD 对齐（即地址 % 2 == 0），末尾需要用零填充。最终，整个资源块的大小还必须是 DWORD 对齐（% 4 == 0）。
• 正确写入：调用 UpdateResource 时，第三个参数（lpData）必须指向完全重序列化后的新内存块，而第四个参数（cbData）必须是这个新块的真实字节数，绝不能直接使用原始数据的大小。

// 示例：检查是否能原地替换（仅当新字符串更短或等长时安全）
if (newWStr.length() * sizeof(wchar_t) + 2 <= oldStringLengthField) {
    // 可覆盖：memcpy + 补零
} else {
    // 必须重建整个 VS_VERSIONINFO 结构
}

为什么 GetFileVersionInfo 读出来全是空或乱码

遇到读取结果为空或乱码，先别急着怀疑编码问题。十有八九，是调用方式踩了坑。下面这几个陷阱，看看你中了哪个：

立即学习“C++免费学习笔记（深入）”；

• 缓冲区大小错误：忘记了要先调用 GetFileVersionInfoSize 来获取所需的缓冲区大小，而是直接传入一个固定的小缓冲区，导致数据被截断。
• 静默失败：传给 GetFileVersionInfo 的缓冲区大小，小于 GetFileVersionInfoSize 的返回值。这时函数可能仍然返回 TRUE，但内部数据已经不完整了。
• 指针类型混淆：解析时，误将 VerQueryValue 返回的指针当作字符串直接 printf。这个指针可能指向 VS_FIXEDFILEINFO* 结构，也可能指向 LPWSTR 字符串（取决于查询路径），后者还需要进行恰当的字符串转换。
• 查询路径写错：例如，使用了 \StringFileInfo\040904b0\ProductName 这样的路径，但实际的资源语言块名可能是 040904E4（包含代码页）或 04090000（LANG_NEUTRAL）。最可靠的方法是从资源中动态枚举获取正确的路径。

第三方库（如 pe-tools 或 pefile）能省事吗

坦白说，在C++的生态里，想找一个成熟、轻量且无依赖的PE版本资源编辑库，并不容易。Python的 pefile 库支持读取，但对安全写入的支持有限；而GitHub上那些C++的 pe-tools 项目，大多功能不全，要么只读，要么接口不稳定。

因此，目前最可靠的方案，往往还是自己动手实现一个解析器。关键在于守住以下三点：

• 严格重算长度：所有长度字段（wLength、wValueLength，以及 szKey 后面字符串的长度）都必须严格按照规范重新计算。
• 坚守对齐规则：每个结构体的起始偏移必须是偶数，结构之间的填充字节一个都不能省。
• 事后验证：修改完成后，务必使用 dumpbin /headers 或 CFF Explorer 等工具验证资源节的校验和是否依然有效。虽然Windows不强制校验，但结构错位会导致资源根本无法加载。

最后提一个最容易被忽略的细节：版本资源块内部的字符串键名（比如 CompanyName）本身也是UTF-16字符串，并且以双零结尾。如果你在手动拼接时漏掉了一个 \0，那么整个后续的结构偏移都会乱套，功亏一篑。