有时Windows与PE版本信息“不合拍”

作为我对Amcache（关于它的更多内容以后再说）的一些研究的一部分，我开始探索Windows PE版本信息以及Windows如何看待它。这源于我以为在Velocidex的PE模块中发现了一个错误，但实际上，更像是“Windows有时会做些奇怪的事情”。

所谓的“错误”是什么？

在检查我Windows 11机器上某个PE文件的版本信息时，我注意到在某些情况下，Windows显示给你的细节与文件实际嵌入的内容并不匹配。

我写了一个Velociraptor工件，用于从Amcache中抓取详细信息，同时用PE模块解析二进制文件（这是Velo擅长的——将各种痕迹组合在一起！）。截图中可以看到二进制文件的“属性”与手动解析结果的对比。

出于某种原因，根据PE版本信息，该文件是一个自解压的cab文件，但根据Windows的细节显示，却不是。这里的理论是，在某些情况下，API做了一些额外的工作——我猜这里的细节代表了被提取并安装的可执行文件。

所以我想要深入研究一下

你发现了什么？

好吧，我不知道它是如何工作的，或者为什么这样做；但在一些Copilot提示的帮助下，我制作了几个二进制文件并进行了一些测试。

第一个，hello.exe，只是打印“hello world”，没有嵌入任何元数据。只是一个用GCC编译的简单C脚本。

第二个，hello2.exe，有一个.rc文件，其中嵌入了我给的元数据。这很简单。

那么，这是hello2，它应该嵌入了信息，但出于我尚不理解的原因，用于提取信息以在“详细信息”窗格中呈现的API却……

如果我使用pestudio解析文件，信息肯定在那里（不过，顺便说一句，pestudio对之前那个自解压cab文件也没正常工作）。有趣的是，Amcache镜像了文件属性中的内容，所以可能使用了相同的API？

接下来，我让Copilot为我写了另外两个C程序——第一个使用Windows API打印版本信息，第二个手动提取数据。对于它是如何工作的，这里要持保留态度，因为我20年前上过C语言课，而且也不太确切知道Windows在做什么（可能结合了这些方法），但Copilot似乎在我稍微调整后按照我的要求完成了任务。

那又如何？

基本上，不要假定Windows API返回的属性是完整的，并且要警惕那些从PE头中提取数据的取证工件（例如Amcache）可能放入的内容。它可能并不总是完整的，或者正确的（但这又是另一个话题了）。