当文件来自system32文件夹时，文件的哈希值MD5和SHA256会有所不同。 为什么？

Question

我通过在线哈希生成器md5FileCalculator Onlinemd5计算了notepad.exe和mspaint.exe的MD5和SHA256哈希值。 我注意到的是，如果我计算出两个exe在system32的实际位置中何时存在，则得出的值与放置在system32文件夹之外的值不同。 背后的原因是什么？ 哪个是正确的哈希值？

我正在使用软件限制策略来阻止应用程序，我为notepad.exe（存在于SYSTE32文件夹中）文件创建了一个哈希规则，并将其阻止。 当我检查注册表中的哈希值时，它与通过其他方法（例如，在线md5计算器）或Windows API计算出的notepad.exe（从SYSTEM32文件夹）的哈希值不同。 但是当我将notepad.exe文件复制到桌面上的其他文件夹并计算哈希值时，它与创建规则的注册表中的哈希值相同。因此正确的值是我认为的值当文件不在system32文件夹中时。 但是我不明白为什么会这样吗？ 它与权限有关吗？

Answer 1

这是因为在64位Windows上运行的32位应用程序以及Windows如何处理这些程序的System32文件夹。

这也让我发疯了一段时间，因为我一生都无法弄清为什么System32中的某些文件（即.dlls和.exes）根据我检查它们的方式返回不同的哈希值。

使用HxD和Firefox上传文件以检查其哈希，与使用QTTabBar的哈希检查器（运行在explorer.exe中）相比，我得到了不同的结果。

但是，如果我将这些文件之一复制到另一个位置，那么我将在所有程序中获得相同的结果。

同时，HxD对于复制文件显示的文件长度与System32中文件的长度不同，并且虽然两者显示相似的字节分布，但也存在显着差异。

但是后来我想在另一个文件夹上尝试相同的操作，最后在Wikipedia的帮助下将其破解：

操作系统将％SystemRoot％\\ System32目录用于其64位库和可执行文件。 这样做是出于向后兼容性的原因，因为许多旧版应用程序都经过硬编码以使用该路径。 当执行32位应用程序时，WoW64透明地将32位DLL重定向到％SystemRoot％\\ SysWOW64 ，其中包含32位库和可执行文件。

32位应用程序通常不知道它们运行在64位操作系统上。 32位应用程序可以通过伪目录％SystemRoot％\\ Sysnative访问％SystemRoot％\\ System32 。

由于HxD和Firefox（以及大多数其他浏览器）都是32位应用程序，因此当您将文件加载到它们中时，Windows实际上实际上是将它们透明地重定向到SysWOW64文件夹中相同名称的文件（如果您运行的是64-位浏览器，则不会遇到此问题）。

同样，当您将文件从System32复制到另一个位置时，作为64位进程的explorer.exe将复制原始System32文件，而不是SysWOW64等效文件（名称易混淆）。

因此，正如Wiki所述，如果在32位应用程序中的打开文件对话框的路径中输入%SystemRoot%\\Sysnative ，它将从真实的 System32文件夹中加载文件，并为您提供正确的结果。

并且，如果您检查SysWOW64目录中的文件，则无论使用什么打开它们，所有文件都应返回相同的各自的哈希值。

进一步阅读：

• Syswow64资料
• Sysnative

Answer 2

您确定要在不同的路径上检查完全相同的文件吗？ 我认为您正在检查两个不同的notepad.exe。 检查文件的大小...字节数必须完全相同。 我刚刚在两个不同的路径C：\\ Windows \\ System32和C：\\ Windows上检查了我的notepad.exe ，它们是不同的。