【问题标题】:How to secure .NET DLL's如何保护 .NET DLL
【发布时间】:2010-12-13 18:24:13
【问题描述】:

为您正在处理的项目保护 DLL 的最佳做法是什么?我有兴趣开发的某些 DLL 将具有数据访问层 (DAL) 和业务逻辑层 (BLL) 功能。可能有几个应用程序最终可以访问这些 DLL 以执行特定于业务的功能。

保护这些 DLL 以使其只能由创建者的应用程序使用的最佳方法是什么?

阻止未经授权使用 DLL 的安全性和防止可能的反编译的安全性都是可取的。

【问题讨论】:

  • 您的意思是保护它们不被反编译还是仅仅保护它们不被使用?
  • 现在我正在寻找使用,但真的在寻找两者。相应地更新了问题。

标签: .net vb.net programming-languages


【解决方案1】:

一种选择可能是将 DLL 中所有公开的类标记为“内部”而不是“公共”,然后使用 DLL 中的 "InternalsVisibleTo" 属性显式命名允许的 DLL(可能还有 exe)使用您的内部类型。这可能要求所有参与者都具有强名称,但无论如何这是一件好事。

最终,当您的代码在黑客的机器上执行时,没有绝对的方法可以阻止一个坚定的黑客访问您的代码。机器可以执行的所有代码都可以通过足够先进的工具和经验进行反汇编和重新组装成其他东西。

解决代码安全问题的最佳方法是提出以下问题:“我们想让某人在未经许可或授权的情况下使用此代码的难度有多大,我们愿意花费多少时间/金钱来实现这一目标? "如果您什么都不做,那么有人很容易在其他项目中使用您的 DLL。如果你做一些简单的事情,你可以让别人在别处使用你的 DLL 变得不方便。如果您投入数月的努力,您也许可以让他人难以滥用您的代码,但您永远无法做到这一点。

我能想象到的一种接近绝对安全的技术是:根本不要在客户端(或黑客)的机器上执行您的代码。改为运行 Web 服务,并将您的代码保存在服务器上,让黑客无法随意启动您的进程的调试器或反汇编您的代码。然后,您的代码安全性由服务器位置的物理安全性和对服务器端口的网络访问安全性定义。这些攻击向量比您对在黑客机器上执行的代码所能做的任何事情都更难规避。

对于一些软件公司而言,将部分应用程序从客户端迁移到云端并不是为了获得更好的可扩展性、更轻松的更新或降低成本,而是为了代码安全和防止盗版。

【讨论】:

  • 并非如此。 .NET 也允许您引用 exe 文件程序集,因此几乎没有区别。
  • 使用 Red Gate 的 Reflector 之类的工具。即使在可执行文件中,几乎任何东西似乎都相对容易地被反编译。那么在 exe 中包含它是否实际上提供了很多帮助?
  • 根据 Brian 的观点,我撤回了“将代码拉入 DLL”的建议。剩下的就是:没有绝对的锁定,所以你必须决定你愿意投资多少,以使破解结果更加不方便。
  • +1 表示“根本不要在客户端(或黑客)的机器上执行你的代码”
【解决方案2】:

使用 Open Key 机制建立身份验证。 DLL 中的函数只有在您提供有效的密钥和令牌时才能工作。

【讨论】:

  • 你能澄清或提供一些例子的链接吗?
【解决方案3】:

如果有人可以访问包含所有这些程序集的机器,那么您比有人重复使用它们更需要担心,他们可以直接访问数据库而不是使用您的程序集。

如果这是一个桌面应用程序或其他东西,并且您正在直接访问数据库,那么您需要重新考虑您的应用程序,通过 Web 服务或其他方式访问数据,而不是直接访问数据库。

【讨论】:

  • 场景存在于复制环境中。这些机器在任何给定时间可能有也可能没有互联网连接,因此无法选择网络服务。
  • Sooooo... 我不明白你的意思是什么。直接与数据库对话是不好的,你仍然没有理由直接与它对话。
【解决方案4】:

如果您将知识产权以 .NET DLL 的形式发送给客户端,那么保护您的知识产权实际上是不可能的。您可以在云中托管您的应用程序逻辑,尽管这可能不适合您的场景。

即使是“最好的”混淆器也不是万无一失的。你可能会推迟一个随便的黑客,但正如 dthorpe 所说,如果有人真的想反编译你的程序集,他们会的。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-01-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-08-22
    • 1970-01-01
    • 2017-12-04
    • 2022-12-18
    相关资源
    最近更新 更多