ORM 和 .NET 代码保护器

Posted 2023-04-12

【中文标题】ORM 和 .NET 代码保护器

【英文标题】：ORM and .NET Code Protectors

【发布时间】：2009-09-22 10:56:56

【问题描述】：

我们即将使用代码保护器（Obsfucation 和 Native Compilation），我认为 ORM 将稍微依赖于反射，我担心 Obsfucation 和 Native Compilation 保护技术会产生任何问题吗？

有没有人为任何好的桌面应用程序尝试过成功的 ORM 和代码保护？我们正在开发 WPF 桌面应用程序。

我们的主要开发语言是 C#，我们使用的是自定义 ORM，但我也想评估任何商业 ORM 或 ADO.NET EF 等。

问题不是关于什么是代码保护以及我应该使用哪一个，我想问的是保护对 ORM 的影响。

【参考方案1】：

如果您的代码使用反射，很可能混淆的程序集将无法工作。您需要从混淆中排除那些以其原始名称引用的实体。查看Crypto Obfuscator，它将在混淆期间分析您的代码，并显示调用可能破坏方法（例如 Reflection ）的所有方法和行号。这是一个巨大的计时器节省程序，因为它可以精确定位确切位置并帮助确定您需要从重命名中排除的属性/类。

【讨论】：

谢谢，这是我一直在寻找的答案，这是否也意味着 WPF 等在基于反射进行绑定的情况下可能无法正常工作？

【参考方案2】：

试试 .Net Reactor。可在http://www.eziriz.com/

它比周围的其他一些便宜很多，而且可以做得更多。您还可以禁用某些选项（例如混淆，以保留反射的使用），并且只启用某些选项，例如 ILDASM Suppression，它仍然可以保护代码。

干杯

【讨论】：

请阅读问题，我不想知道该尝试哪个 Protector，您对这个 Protector 对 ORM 的影响有经验吗？比如实体框架、BL Toolkit 等？

【参考方案3】：

Redgate 不久前收购了Smart Assembly，如果我有需要，我会考虑这样做。

不久前，我试用了 CodeViel 来研究混淆/加密代码，并取得了一定程度的成功。我认为，如果你认真对待这样做，它并不像将一个组件放在一端然后弹出一个受保护的组件那么简单。您将不得不考虑仅在内部使用的部分代码（即命名空间、类、方法、字段、属性、结构、事件和资源），以及需要向其他资源和库公开的部分。在我正在查看的情况下，我能够加密（或使用本机编译）以隐藏一些方法实现，但保留类定义（名称、方法、属性不变）。在某些情况下，我保留了整个命名空间，因为它们只包含其他库所需的简单 POCO 对象。

对于您在哪里使用什么策略，您可能会混淆一些内部结构以使反编译/逆向工程变得困难，这似乎真的是一个仔细的个案基础，这就足够了。在其他情况下，您可以使用加密/本机编译来简单地隐藏方法实现。而且您还会遇到一些情况，即您完全排除了组件的某些部分。这些程序中的大多数都会为您提供一些推荐的默认值和选项，您可以从中开始，但您需要调整和更改这些，直到您可以产生保护您的核心 IP 但不限制最终用户的结果。