根据目前公布的不完整细节，恶意代码是在编译和签名之前插入的（例如，在开发人员的机器上，或在构建服务器上）。结果，受损版本的签名过程与未受损版本所使用的过程完全相同。该缺陷是在二进制文件签名之前引入的。

类似地，将根据编译结果计算校验和，此时恶意代码已经存在。

这是所有签名架构中的一个弱点——如果签名之前的过程被破坏，就没有真正的方法来检测它。这并不意味着它们没有帮助 - 如果攻击者在应用签名之后才能访问系统，那么很容易检测到篡改，因为签名不会匹配。

由受信任的证书签名并拥有代码的公共哈希/校验和是不同的事情。

证书将（应该）告诉您该软件来自受信任的来源，但仅此而已。

哈希或校验和将让您验证二进制与最初计算的哈希匹配。然而，在这种情况下，当源代码中存在恶意代码时计算哈希值，呈现这种特殊的保护措施，除非它增加了错误的安全感。

在提供公共哈希或校验和时（假设源代码没有被泄露），您应该采取措施从第三方域提供该哈希。想象一下这样一种情况，攻击者破坏了您的站点，将正版二进制文件替换为恶意二进制文件，然后更改您在站点上显示的公共哈希。至少如果它是由第 3 方提供的，则攻击者还必须破坏第 3 方以更改哈希值。

请记住，尽管这种特殊的攻击显然是被黑客入侵的开发人员机器的结果，所以这些哈希/校验和或代码签名控制无论如何都没有任何用处。