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

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

PE版本资源结构在哪找

在Windows可执行文件（PE文件）中定位版本信息，其核心位置在于资源节（.rsrc）。具体而言，你需要查找资源类型为 RT_VERSION 的条目，其资源名称通常为 1（即主版本块），而语言标识符（Language ID）则常见为 0x409（美国英语）或 0x0（语言中立，LANG_NEUTRAL）。

一个关键认知是：版本资源并非简单的文本表，而是一个复杂的嵌套二进制数据结构。其顶层是 VS_VERSIONINFO 根结构，内部包含 StringFileInfo（存储字符串信息）和 VarFileInfo（存储变量信息）两个主要部分。进一步深入 StringFileInfo，才能找到包含实际键值对的 StringTable，例如我们常用的 FileVersion（文件版本）和 ProductName（产品名称）。

直接使用 BeginUpdateResource 和 UpdateResource 这类API来修改版本资源极易失败。根本原因在于，这些API要求传入一个格式完全正确、字节严格对齐且大小精确的资源数据块。版本资源对字节对齐的要求极为严格——所有字段必须按 WORD（2字节）边界对齐，字符串必须以双字节的零（\0\0）终止，并且所有长度字段都需要精确计算。手动构建此结构时，任何细微的偏差都可能导致资源损坏。

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

要安全、可靠地修改PE文件的版本信息，必须遵循一套严谨的流程：提取原始资源 → 解析其内部结构 → 修改目标字符串 → 重新序列化数据 → 最终写回文件。以下是实现此流程不可或缺的关键步骤：

• 获取原始数据：首先，使用 FindResource 定位到 RT_VERSION 资源，再通过 LoadResource 和 LockResource 获取指向其原始内存数据的指针。请注意，此处获得的是未经处理的原始二进制块，包含了完整的资源头部及其所有嵌套子结构。
• 精准定位：手动解析 VS_VERSIONINFO 头部，逐层向下遍历，找到 StringFileInfo 下的 StringTable，进而定位到具体的 String 子结构。例如，找到键名（szKey）为 FileVersion 的条目。
• 谨慎修改：修改字符串值时，必须确保新字符串的UTF-16编码长度（包含结尾的两个空字符）不超过原 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 读出来全是空或乱码

当使用 GetFileVersionInfo 读取版本信息却得到空值或乱码时，问题通常不在于文件编码，而在于API的调用细节。以下是几个常见的错误原因：

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

• 缓冲区大小错误：未首先调用 GetFileVersionInfoSize 来获取所需的缓冲区大小，而是直接传入一个固定大小的数组，导致数据被截断。
• 静默失败：传递给 GetFileVersionInfo 的缓冲区大小，小于 GetFileVersionInfoSize 返回的值。此时函数可能仍返回成功（TRUE），但缓冲区内的数据已不完整。
• 指针类型混淆：解析时，错误地将 VerQueryValue 返回的指针当作普通字符串直接输出。该指针可能指向 VS_FIXEDFILEINFO 结构体，也可能指向 LPWSTR 宽字符串（取决于查询路径），后者需要进行正确的宽字符到多字节的转换。
• 查询路径错误：例如，使用了类似 \StringFileInfo\040904b0\ProductName 的路径，但实际资源中的语言代码页组合可能是 040904E4 或 04090000。最稳妥的方法是先通过 VerQueryValue 枚举出资源中存在的 \VarFileInfo\Translation 来动态获取正确的路径。

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

客观地说，在C++开发环境中，寻找一个成熟、轻量且无外部依赖的PE版本资源编辑库颇具挑战。Python的 pefile 库在读取方面表现出色，但对安全写入的支持有限；而GitHub上许多C++的 pe-tools 类项目，功能往往不完整，要么仅支持读取，要么API接口不够稳定。

因此，当前最可靠的解决方案通常是自行实现一个解析与修改器。实现过程中的核心要点如下：

• 严格重算长度：所有涉及长度的字段（包括 wLength、wValueLength，以及 szKey 键名字符串的长度）都必须严格遵循PE规范重新计算。
• 坚守对齐规则：每个结构体的起始偏移必须是偶数（WORD对齐），结构体之间的填充字节必须保留，不可省略。
• 事后验证：修改完成后，务必使用如 dumpbin /headers 或 CFF Explorer 等工具检查资源节的完整性。虽然Windows加载器不一定强制校验，但结构错位将直接导致资源无法被正常识别和加载。

最后，一个极易被忽视的细节是：版本资源块内部的字符串键名（例如 CompanyName）本身也是以UTF-16编码存储，并且以双空字符（\0\0）结尾。如果在手动构建数据结构时遗漏了结尾的零字符，将导致后续所有结构的偏移计算错误，前功尽弃。