C# 没有强命名的代码签名会让你的应用程序被滥用吗？

尝试了解authenticode代码签名和强命名

如果我对引用了几个DLL（不是强名称）的exe进行代码签名，恶意用户可能会替换我的DLL，并以一种看起来像是我签名的方式分发应用程序，但却在运行他们的代码，这是对的吗

假设这是真的，那么你似乎真的不想签署一个.NET应用程序而不对整个程序进行强有力的命名，否则你就给了人们以你编写的应用程序的名义执行代码的能力

---

我不确定的原因是，我在网上找到的文章（包括关于使用SN+Authenticode的MSDN文档）似乎都没有提到这一点，而且这似乎是一个相当重要的理解点（如果我理解正确的话）？

一旦有人可以替换dll或在您的机器上运行代码，您就没有那么多的保护措施了。在我的例子中，所有Dll都是单独进行代码签名的。我的代码拒绝下载未作为自我更新一部分签名的Dll。但是，在我的系统上以我的完整性级别或更高级别运行的任何应用程序（在>=Vista Windows的情况下）仍然可以使用CreateRemoteThread等将dll插入到我的exe中(http://www.codeguru.com/Cpp/W-P/dll/article.php/c105) 但是，再次假设有人可以将外来代码输入系统是困难的部分。剩下的很简单

如果我对引用了几个DLL（不是强名称）的exe进行代码签名，恶意用户可能会替换我的DLL，并以一种看起来像是我签名的方式分发应用程序，但却在运行他们的代码，这是对的吗

是的，如果其余的DLL只进行了签名而没有强名称，则可以替换它们，而无需.NET引发异常。您可以在exe内部验证DLL是否由与exe相同的密钥签名。这些方法都不能阻止有人替换您的DLL或EXE

假设这是真的，那么你似乎真的不想签署一个.NET应用程序而不对整个程序进行强有力的命名，否则你就给了人们以你编写的应用程序的名义执行代码的能力

一般来说，我认为这是“最佳实践”，但你也没有阻止任何事情。一旦用户有权更改本地系统上的文件，您就无法阻止他们进行恶意活动

有几种模糊处理技术可以将完整的.NET项目构建到单个exe中，这可能是“最安全”的方法，但仍然可以被篡改

真正的问题是你在试图阻止他们做什么？我的意思是，为什么会有人对替换你的dll感兴趣？他们希望实现什么，他们的目标是什么？如果你试图阻止某人阅读过程中的敏感信息，你将陷入漫长而艰难的失望之路。假设恶意方完全可以访问您的源代码和流程使用的每一条信息，因为他们可以访问。假设他们可以随意替换全部或部分代码，因为他们可以

已更新

---

因此，绑定重定向将只适用于具有相同密钥的强名称程序集，因此是否可以保护您不受DLL更改的影响

正确，但值得注意的例外是，代码注入仍然可以通过多种方式完成

。。。回到最初的问题，没有强命名的代码签名会破坏代码签名的重要性吗

不是真的。代码签名（非强命名）有两个不同的用途：

认证。验证谁是软件的作者

正直。验证软件自签署以来未被篡改

通常，这仅在安装过程中经过身份验证和验证。这就是为什么我们要对setup.exe进行签名，以确保客户已收到我们提供的未经修改的安装程序。系统会提示他们“您是否信任XXXX公司”，从而向经过身份验证/签名的安装程序授予授权。然而，一旦安装，操作系统就很少使用内置的代码签名（除了驱动程序和其他一些模糊的情况）

另一方面，强命名对它的存在有着完全不同的目的。它完全关注应用程序的“完整性”。没有证书，没有签名机构（CA）来验证它，没有用户显示的信息供他们确认，操作系统也无法验证它将要运行的可执行文件

.NET framework在许多方面都使用了强名称，我将它们松散地归类为应用程序完整性：

dll/exe的内容具有签名哈希，因此无法对其进行篡改

加载依赖项时，必须对每个引用进行强命名和验证

可以在GAC中注册程序集，并且可以使用发布者策略

可以对本机映像进行加密以生成程序集IL的编译映像

我肯定还有其他东西我在这里遗漏了，但这些是我知道的主要用途

签名和强命名的最佳实践

• 使用已签名的安装程序
• 使用代码签名的可执行文件
• 使用强名称的可执行文件
• 强名称所有依赖项及其引用
• 通常不需要代码签名依赖项*
• 考虑GAC在安装时注册程序集

---

*注意：代码签名在某些情况下对DLL很有用，例如，标记为“安全”并嵌入到浏览器中的COM对象应进行签名并强命名，就像它是可执行文件一样。代码签名在外部验证依赖项时也很有用，无需加载程序集或反映其属性。

您还必须记住，代码签名在升级时通常会带来很多麻烦