问题标签 [winverifytrust]

我目前正在使用 WinVerifyTrust api 检查 Windows 安装程序文件 (.msi) 的数字签名在 C# 中是否有效。我还在验证签名中的指纹是否来自已知列表。

我需要对 C#（在 Windows 上）中的 Mac OSX 文件（.dmg）执行相同的操作。有没有办法做到这一点？

我在windows 10 pro上使用 windows WinVerifyTrust函数来验证 dll 签名。当我第一次激活此功能时，该功能需要4秒才能执行并返回第一个dll的验证状态。对于其他进行中的 dll，该函数会快速返回。

谁能帮我理解这种延迟的可能原因？

需要 4 秒的调用是这个调用：

我正在使用的包装函数如下所示：

正如文档所说：

WinVerifyTrust 函数使应用程序能够调用信任提供程序来验证指定对象是否满足指定验证操作的条件。 （来自https://docs.microsoft.com/en-us/windows/win32/api/wintrust/nf-wintrust-winverifytrust）

什么实际上是信任提供者？我在哪里可以找到它？调用 WinVerifyTrust 时会加载哪些 dll 的外部 dll？

我正在尝试使用该WinVerifyTrust功能来验证 msi 的签名。

虽然这适用于文件系统上的文件，但我无法让它与内存 blob 一起使用。
我的示例显示问题的基础是微软的示例程序

在上面的例子中使用了WINTRUST_FILE_INFO作品，但WINTRUST_BLOB_INFO没有。我使用内存 blob 得到的错误始终是TRUST_E_PROVIDER_UNKNOWN.

我认为问题可能是WIN_TRUST_SUBJTYPE_RAW_FILE主题类型，但我不知道应该将哪个用于 msi 文件。我想知道是否可以使用 msi 文件的内存 blob 进行符号检查。

我收到一个指向包含文件的内存的指针，我需要检查该文件是否具有嵌入式证书（数字签名）并且它是否有效。过去，我使用 winverifytrust 使用 WINTRUST_ACTION_GENERIC_VERIFY_V2 标志检查这一点，但这仅适用于磁盘上的文件（我在将内存写入磁盘之前从驱动程序获取指向内存的指针）。我想过使用带有 WINTRUST_BLOB_INFO 结构的 winverifytrust，根据这个：

在调用 WinVerifyTrust 来验证内存 BLOB 时使用。

但不幸的是，文档指出：

注意以下收件箱文件格式当前不支持此结构。除了这些格式之外，可能还有其他格式不受支持。可移植的可执行文件（例如 .exe、.dll、.ocx） Cab 文件 (.cab) 目录文件 (.cat)

我能够使用 C# 中的X509Certificate(byte[])构造函数获取文件的证书，甚至使用X509chain.Build(X509Certificate2)函数检查链，但是 winverifytrust 所做的更多验证不包含在其中检查（例如：检查文件自签名后是否被篡改）。

我需要从内部验证我的多平台应用程序的代码签名。Win32 为此提供了一个非常方便的 API - WinVerifyTrust。但是，我不知道如何在 iOS 中执行此操作。此检查需要从应用程序内部完成，不能使用外部工具。

感谢这里有一篇非常古老的帖子

https://web.archive.org/web/20140217003950/http://forum.sysinternals.com/topic16893_post83634.html

我遇到了一个函数，它将在文件上调用 WinVerifyTrust 以检查嵌入的签名，如果失败，则找到适当的系统目录文件并通过另一个对 WinVerifyTrust 的调用来检查它。

但是，使用 C:\Windows\System32\cmd.exe 进行测试失败。请注意，测试应用程序是 64 位的，因此文件重定向不是问题。

将该函数的输出与 Microsoft 的Sigcheck实用程序进行比较，该函数具有正确的文件哈希，并找到正确的目录文件。但是，当使用目录信息调用 WinVerifyTrust 时，它仍然失败并显示

TRUST_E_BAD_DIGEST 0x80096010 //对象的数字签名没有验证。

有趣的是，当 UI 启用时

dwUIChoice = WTD_UI_ALL

失败代码不同：

TRUST_E_SUBJECT_NOT_TRUSTED 0x800B0004 // 指定操作不信任主题。

但是 Sigcheck.exe 和 Signtool.exe 都说它是可信的。

此外，如果设置了 dwUIChoice = WTD_UI_ALL，我会在下面弹出一个错误消息，其中包含指向看起来非常有效的证书的链接。

那么为什么 WinVerifyTrust 表明 cmd.exe 上的签名是错误的呢？

代码如下，我欢迎任何关于可以修复的输入：

请注意，要使用上述功能，您需要：

更新：来自此处提供的示例

https://github.com/microsoft/Windows-classic-samples/blob/master/Samples/Security/CodeSigning/cpp/codesigning.cpp

我刚刚发现使用

而不是 CryptCATAdminAcquireContext，并且 CryptCATAdminCalcHashFromFileHandle 2而不是 CryptCATAdminCalcHashFromFileHandle在我的 Windows Server 2019 上工作。

所以现在问题变成了“为什么？”，对于可能运行代码的其他操作系统版本（Win 7？Win 8？Server 2012 R2？），BCRYPT_SHA256_ALGORITHM 是否是合适的参数？

更新 2

CryptCATAdminAcquireContext2 的文档说：“此函数使您能够选择或为您选择在需要目录管理员上下文的函数中使用的哈希算法。虽然您可以设置哈希算法的名称，但我们建议您让函数确定算法。这样做可以保护您的应用程序免受将来可能变得不受信任的硬编码算法的影响。

但是，设置 NULL （如文档中所建议的那样）而不是 BCRYPT_SHA256_ALGORITHM 会导致之前看到的失败。这非常脆弱，似乎是特定于操作系统的 :(

无论如何要使这项工作在操作系统版本之间可靠地工作？

更新 3 现在很明显为什么这不能正常工作。这是 sigcheck 显示的来自 cmd.exe 的哈希列表

当使用 NULL 调用 CryptCATAdminAcquireContext2 时，您会从 CryptCATAdminCalcHashFromFileHandle2 获得 PESHA1 哈希。当使用 BCRYPT_SHA256_ALGORITHM 调用时，您会得到 PE256 哈希。

这一切都说得通。不幸的是，目录文件只包含 PE256 哈希。因此，如果您不知道目录文件包含什么散列算法，我能想到的唯一解决方案是使用 CryptCATAdminAcquireContext2 的各种算法遍历所有这些代码，并一遍又一遍地拥有该文件，直到找到一个散列存在于目录文件中。

不清楚的是，CryptCATAdminEnumCatalogFromHash 如何使用 PESHA1 哈希找到相同的目录文件，即使在目录文件中找不到哈希？ 必须有一些额外的信息允许它工作。