有时Windows和PE版本信息不兼容

作为我对Amcache研究的一部分（关于这个以后会详细讨论），我探索了Windows PE版本信息以及Windows如何识别它。这源于我以为在Velocidex PE模块中发现了一个bug，但实际上更可能是"Windows有时会做出奇怪的行为"。

所谓的"bug"是什么？

在检查我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。它可能不总是完整或正确的（但这是另一个话题了）。