4

重复：如何保护dll？

我想保护我的 C# DLL 不被第三方应用程序使用。我只想我的应用程序使用这个 DLL。我怎样才能做到这一点？

谢谢你。

4

5 回答 5

14

将所有内容都放在 DLL 中，然后在 Properties\AssemblyInfo.cs 中，将InternalsVisibleTo属性设置为仅指向应用程序的强名称。

于 2009-07-10T14:12:00.467 回答
13

这根本不可能。

整个代码访问安全系统是基于这样一个概念，即安全决策来自运行代码的用户，而不是代码的作者。你，代码作者，不能告诉你的用户他们的安全决定是什么；你是用户的仆人，而不是用户的主人。

现在，您可以让第三方代码难以使用您的代码。您可以使用各种安全属性来证明您的意图是让第三方代码不使用您的代码。这些都是很好的步骤，但在用户对您怀有敌意的任何世界中，它们实际上并不能解决您的问题。在 CAS 模型中，用户永远是赢家。

例如：您可以让代码中的方法执行触发堆栈遍历的安全要求，以检查调用堆栈中的每个人是否都有与他们相关的某些证据。例如，“这个 DLL 是用 Guillaume 的强名称私钥签名的，它被锁在 Guillaume 办公室的抽屉里”的证据就是很好的检查证据。这几乎可以保证每个调用您的代码的人也是您的代码。

但这不是强名称签名的目的；强名称签名的目的是帮助用户知道他们认为他们正在运行的代码实际上来自您。正如我们将看到的，将安全工具用于非预期目的是很危险的。它给你一种完全错误的安全感。

假设您的用户想要创建一个使用您的 DLL 的不属于您的应用程序。用户可以编写完全可信的代码，完全可信的代码拥有伪造证据的权利。这就是“完全信任”的意思。所以用户创建了一个不是你签名的应用程序，但是因为用户可以完全信任那个应用程序，所以完全信任的应用程序可以伪造证据来证明代码来自你。

就此而言，没有什么可以阻止用户简单地获取您的代码、删除您的签名并用他们的签名替换它。你可以说你的 EULA 禁止这样做，如果你发现了你可以起诉他们，但你不能做任何事情来阻止他们。

哎呀，用户可以根据需要禁用整个安全系统，在这种情况下，任何东西都可以运行。

您应该考虑是否要将 DLL 发送给客户。如果它包含您不想泄露的秘密，请不要与成千上万的客户分享这些秘密，其中一些客户可能对您怀有敌意。如果您将 DLL 保存在您自己的服务器上并通过 Web 提供服务，那么您永远不会将您的 DLL 发送给客户，因此他们不能在他们自己的机器上将其用于您想要的其他目的。

于 2009-07-10T17:58:18.967 回答
3

没有单一的有效障碍，但是您可以设置许多障碍来阻止人们绑定到您的 DLL。

  1. 使用发布者和/或身份代码访问安全权限，以便您可以检查调用代码来自您（通过 x509cert 测试和强名称）。不要忘记在签署程序集时使用 -t ，否则当您的 x509cert 过期时，它将失败。

（强名称标识程序集，发布者标识谁发布了程序集。）

您还需要检查 .NET 中 CAS 安全性的禁用情况，这可以再次以编程方式在您要保护的资产中执行。

  1. 混淆您的 DLL 构建后（但在签名之前）。

  2. 考虑添加某种许可检查最终程序检查。

高温高压

菲尔

于 2009-07-10T14:19:23.267 回答
1

请记住，这种保护需要双重保护。如果您只保护 DLL，任何黑客都会开始分析您的应用程序以了解它是如何调用 DLL 的。此外，如果第三方对您的 DLL 具有完全访问权限，那么无论您的保护有多强大，他们都会成功地发现它的内部运作。尽管一些保护方案比其他方案需要更多的时间来破解。基本上，你的 DLL 的保护应该取决于这个 DLL 的值。如果黑客可以通过破解您的 DLL 来节省或赚取数百万美元，他们肯定会这样做。如果您的 DLL 只是为他们提供了最低限度的经济收益，那么他们更有可能甚至懒得破解它。

如果您想保证 DLL 代码的安全，请在某处设置 Web 服务并设置您的应用程序以调用此服务而不是本地 DLL。那么黑客访问你的图书馆就会有更多的麻烦。不幸的是，它还要求您的用户具有持续的 Internet 连接。

（基本上，这就是云计算变得越来越流行的原因。用户可以使用云应用程序，但无法访问二进制文件。）

于 2009-07-10T14:32:27.643 回答
0

混淆您的代码是补充解决方案

于 2009-07-10T14:19:25.200 回答