.NET 混淆工具/策略

.NET obfuscation tools/strategy

提问by csmba

My product has several components: ASP.NET, Windows Forms App and Windows Service. 95% or so of the code is written in VB.NET.

我的产品有几个组件：ASP.NET、Windows 窗体应用程序和 Windows 服务。95% 左右的代码是用 VB.NET 编写的。

For Intellectual Property reasons, I need to obfuscate the code, and until now I have been using a version of dotfuscator which is now over 5 years old. I'm thinking it is time to move to a new generation tool. What I'm looking for is a list of requirements which I should consider when searching for a new obfuscator.

出于知识产权的原因，我需要对代码进行混淆，直到现在我一直在使用 dotfuscator 的一个版本，这个版本现在已经超过 5 年了。我认为是时候转向新一代工具了。我正在寻找的是我在搜索新的混淆器时应该考虑的要求列表。

What I know I should look for so far:

到目前为止，我知道我应该寻找什么：

• Serialization/De-serialization. In my current solution, I simply tell the tool notto obfuscate any class data members because the pain of not being able to load data which was previously serialized is simply too big.
• Integration with Build Process
• Working with ASP.NET. In the past, I have found this problematic due to changing .dll names (you often have one per page) - which not all tools handle well.

• 序列化/反序列化。在我当前的解决方案中，我只是告诉工具不要混淆任何类数据成员，因为无法加载以前序列化的数据的痛苦实在是太大了。
• 与构建过程集成
• 使用 ASP.NET。过去，由于更改 .dll 名称（您通常每页有一个），我发现了这个问题 - 并非所有工具都能很好地处理。

采纳答案by Keith

Back with .Net 1.1 obfuscation was essential: decompiling code was easy, and you could go from assembly, to IL, to C# code and have it compiled again with very little effort.

回到 .Net 1.1 混淆是必不可少的：反编译代码很容易，你可以从汇编到 IL，再到 C# 代码，只需很少的努力就可以再次编译它。

Now with .Net 3.5 I'm not at all sure. Try decompiling a 3.5 assembly; what you get is a long long way from compiling.

现在使用 .Net 3.5 我完全不确定。尝试反编译 3.5 程序集；你得到的距离编译还有很长的路要走。

Add the optimisations from 3.5 (far better than 1.1) and the way anonymous types, delegates and so on are handled by reflection (they are a nightmare to recompile). Add lambda expressions, compiler 'magic' like Linq-syntax and var, and C#2 functions like yield(which results in new classes with unreadable names). Your decompiled code ends up a long long way from compilable.

添加 3.5 中的优化（远好于 1.1）以及匿名类型、委托等由反射处理的方式（它们是重新编译的噩梦）。添加lambda表达式，编译器“魔”像Linq的语法和var，和C＃2功能，如yield（其结果在新的班级，不可读的名称）。您的反编译代码最终离可编译还有很长的路要走。

A professional team with lots of time could still reverse engineer it back again, but then the same is true of any obfuscated code. What code they got out of that would be unmaintainable and highly likely to be very buggy.

一个有很多时间的专业团队仍然可以再次对其进行逆向工程，但任何混淆的代码也是如此。他们从中得到的代码将是不可维护的，并且很可能有很多错误。

I would recommend key-signing your assemblies (meaning if hackers can recompile one they have to recompile all) but I don't think obfuscation's worth it.

我建议对您的程序集进行密钥签名（这意味着如果黑客可以重新编译一个，他们必须重新编译所有程序集），但我认为混淆不值得。

回答by Judah Gabriel Himango

We've tried a number of obfuscators. None of them work on a large client/server app that uses remoting. Problem is that client and server share some dlls, and we haven't found any obfuscator that can handle it.

我们已经尝试了许多混淆器。它们都不适用于使用远程处理的大型客户端/服务器应用程序。问题是客户端和服务器共享一些 dll，我们还没有找到任何可以处理它的混淆器。

We've tried DotFuscator Pro, SmartAssembly, XenoCode, Salamander, and several small time apps whose names escape me.

我们已经尝试过 DotFuscator Pro、SmartAssembly、XenoCode、Salamander 和几个名字让我不知道的小型应用程序。

Frankly, I'm convinced obfuscation is a big hack.

坦率地说，我确信混淆是一个大黑客。

Even the problems it addresses is not entirely a real problem. The only thing you really need to protect is connection strings, activation codes, security-sensitive things like that. This nonsense that another company is going to reverse-engineer your whole codebase and create a competing product from it is something from a paranoid manager's nightmare, not reality.

即使它解决的问题也不完全是一个真正的问题。您真正需要保护的唯一东西是连接字符串、激活码、诸如此类的安全敏感的东西。另一家公司将对您的整个代码库进行逆向工程并从中创建竞争产品的这种胡说八道是偏执经理的噩梦，而不是现实。

回答by Michael Dausmann

I am 'Knee Deep' in this now, trying to find a good solution. Here are my impressions so far.

我现在是“膝盖深”，试图找到一个好的解决方案。到目前为止，这是我的印象。

Xenocode- I have an old licence for Xenocode2005 which I used to use for obfuscating my .net 2.0 assemblies. It worked fine on XP and was a decent solution. My current project is .net 3.5 and I am on Vista, support told me to give it a go but the 2005 version does not even work on Vista (crashes) so I and now I have to buy 'PostBuild2008' at a gobsmacking price point of $1900. This might be a good tool but I'm not going to find out. Too expensive.

Xenocode- 我有一个旧的 Xenocode2005 许可证，我曾经用它来混淆我的 .net 2.0 程序集。它在 XP 上运行良好，是一个不错的解决方案。我目前的项目是 .net 3.5，我在 Vista 上，支持告诉我试一试，但 2005 版本甚至不能在 Vista 上运行（崩溃），所以我现在必须以惊人的价格购买“PostBuild2008” 1900 美元。这可能是一个很好的工具，但我不会去发现。太贵了。

Reactor.Net- This is a much more attractive price point and it worked fine on my Standalone Executeable. The Licencing module was also nice and would have saved me a bunch of effort. Unfortunately, It is missing a key feature and that is the ability to Exclude stuff from the obfuscation. This makes it impossible to achieve the result I needed (Merge multiple assemblies together, obfuscate some, not-Obfuscate others).

Reactor.Net- 这是一个更具吸引力的价格点，它在我的独立可执行文件上运行良好。Licensing 模块也很好，可以为我节省大量精力。不幸的是，它缺少一个关键功能，即从混淆中排除内容的能力。这使得无法实现我需要的结果（将多个程序集合并在一起，混淆一些，而不是混淆其他）。

SmartAssembly- I downloaded the Eval for this and it worked flawlessly. I was able to achieve everything I wanted and the Interface was first class. Price point is still a bit hefty.

SmartAssembly- 我为此下载了 Eval，它运行完美。我能够实现我想要的一切，并且界面是一流的。价格点还是有点高。

Dotfuscator Pro- Couldn't find price on website. Currently in discussions to get a quotation. Sounds ominous.

Dotfuscator Pro- 在网站上找不到价格。目前正在讨论以获取报价。听起来不祥。

Confuser- an open source project which works quite well (to confuse ppl, just as the name implies).

Confuser- 一个运行良好的开源项目（正如名称所暗示的那样混淆 ppl）。

Note: ConfuserEx is reportedly "broken" according to Issue #498on their GitHub repo.

注意：据报道，根据GitHub 存储库上的问题 #498，ConfuserEx 已“损坏” 。

回答by Sam

If your looking for a free one you could try DotObfuscator Community Edition that comes with Visual Studio or Eazfuscator.NET.

如果您正在寻找免费的，您可以尝试使用 Visual Studio 或Eazfuscator.NET附带的 DotObfuscator Community Edition 。

---

---

Since June 29, 2012, Eazfuscator.NET is now commercial. The last free available version is 3.3.

自 2012 年 6 月 29 日起，Eazfuscator.NET 现已商业化。最后一个可用的免费版本是 3.3。

回答by Shawn

I have been using smartassembly. Basically, you pick a dll and it returns it obfuscated. It seems to work fine and I've had no problems so far. Very, very easy to use.

我一直在使用智能装配。基本上，你选择一个 dll 并返回它混淆。它似乎工作正常，到目前为止我没有遇到任何问题。非常非常容易使用。

回答by Andrew Peters

I have tried almost every obfuscator on the market and SmartAssembly is the best in my opinion.

我已经尝试了市场上几乎所有的混淆器，我认为 SmartAssembly 是最好的。

回答by Ronnie

I've been also using SmartAssembly. I found that Ezrinz .Net Reactor much better for me on .net applications. It obfuscates, support Mono, merges assemblies and it also also has a very nice licensing module to create trial version or link the licence to a particular machine (very easy to implement). Price is also very competitive and when I needed support they where fast. Eziriz

我也一直在使用 SmartAssembly。我发现 Ezrinz .Net Reactor 在 .net 应用程序上对我来说更好。它混淆、支持 Mono、合并程序集，它还有一个非常好的许可模块来创建试用版或将许可证链接到特定机器（非常容易实现）。价格也非常有竞争力，当我需要支持时，他们会很快。 埃兹里兹

Just to be clear I'm just a custumer who likes the product and not in any way related with the company.

需要说明的是，我只是一个喜欢产品的客户，与公司没有任何关系。

回答by Bevan

The short answer is that you can't.

简短的回答是你不能。

There are various tools around that will make it harder for someone to read your code - some of which have been pointed out by other answers.

周围有各种工具会使某人更难阅读您的代码 - 其中一些已被其他答案指出。

However, all these do is make it harder to read - they increase the amount of effort required, that is all. Often this is enough to deter casual readers, but someone who is determined to dig into your code will always be able to do so.

然而，所有这些都让阅读变得更加困难——它们增加了所需的工作量，仅此而已。通常这足以阻止不经意的读者，但决心深入研究您的代码的人总是能够这样做。

回答by JohnC

We have a multi tier app with an asp.net and winform interface that also supports remoting. I've had no problems with using any obfuscator with the exception of the encrypting type which generates a loader which can be problematic in all sorts of unexpected ways and just not worth it in my opinion. Actually my advice would be more along the lines of "Avoid encrypting loader type obfuscators like the plague". :)

我们有一个带有 asp.net 和 winform 界面的多层应用程序，它也支持远程处理。我使用任何混淆器都没有问题，但加密类型除外，它会生成一个加载程序，该加载程序可能会以各种意想不到的方式出现问题，而且在我看来不值得。实际上，我的建议更像是“避免像瘟疫一样加密加载程序类型的混淆器”。:)

In my experience any obfuscator will work fine with any aspect of .net including asp.net and remoting, you just have to become intimate with the settings and learn how far you can push it in which areas of your code. And take the time to attempt reverse engineering on what you get and see how it works with the various settings.

根据我的经验，任何混淆器都适用于 .net 的任何方面，包括 asp.net 和远程处理，您只需要熟悉设置并了解可以在代码的哪些区域推动它。并花时间尝试对您所获得的内容进行逆向工程，看看它如何与各种设置一起工作。

We used several over the years in our commercial apps and settled on Spices obfuscator from 9rays.net because the price is right, it does the job and they have good support though we really haven't needed the support in years anymore but to be honest I don't think it really matters which obfuscator you use, the issues and learning curve are all the same if you want to have it work properly with remoting and asp.net.

多年来，我们在我们的商业应用程序中使用了一些，并选择了来自 9rays.net 的 Spices 混淆器，因为价格合适，它可以完成工作，并且他们有很好的支持，尽管我们多年来真的不再需要支持了，但说实话我认为你使用哪种混淆器并不重要，如果你想让它与远程处理和 asp.net 一起正常工作，问题和学习曲线都是一样的。

As others have mentioned all you're really doing is the equivalent of a padlock, keeping otherwise honest people out and or making it harder to simply recompile an app.

正如其他人所提到的，您实际上所做的一切都相当于挂锁，将其他诚实的人拒之门外，或者使简单地重新编译应用程序变得更加困难。

Licensing is usually the key area for most people and you should definitely be using some kind of digitally signed certificate system for licensing anyway. Your biggest loss will come from casual sharing of licenses if you don't have a smart system in place, the people that break the licensing system were never going to buy in the first place.

许可通常是大多数人的关键领域，无论如何您绝对应该使用某种数字签名的证书系统进行许可。如果您没有适当的智能系统，您最大的损失将来自随意共享许可证，破坏许可证系统的人永远不会首先购买。

It's really easy to take this too far and have a negative impact on your customers and your business, do what is simple and reasonable and then don't worry about it.

走得太远很容易对您的客户和您的业务产生负面影响，做一些简单合理的事情，然后不要担心。

回答by burnside

For the past two days I've been experimenting with Dotfuscator Community Edition advanced (a free download after registering the basic CE that comes bundled with Visual Studio).

在过去的两天里，我一直在试验 Dotfuscator Community Edition advanced（注册 Visual Studio 附带的基本 CE 后可以免费下载）。

I think the reason more people don't use obfuscation as a default option is that it's a serious hassle compared to the risk. On smaller test projects I could get the obfuscated code running with a lot of effort. Deploying a simple project via ClickOnce was troublesome, but achievable after manually signing the manifests with mage. The only problem was that on error the stack trace came back obfuscated and the CE doesn't have a deobfuscator or clarifier packaged.

我认为更多人不使用混淆作为默认选项的原因是，与风险相比，这是一个严重的麻烦。在较小的测试项目中，我可以花费很多精力来运行混淆代码。通过 ClickOnce 部署一个简单的项目很麻烦，但在使用 mage 手动签署清单后可以实现。唯一的问题是，在错误时，堆栈跟踪被混淆了，并且 CE 没有打包反混淆器或澄清器。

I tried to obfuscate a real project which is VSTO based in Excel, with Virtual Earth integration, lots of webservice calls and an IOC container and lot's of reflection. It was impossible.

我试图混淆一个基于 Excel 的 VSTO 真实项目，其中包含 Virtual Earth 集成、大量网络服务调用和 IOC 容器以及大量反射。这是不可能的。

If obfuscation is really a critical requirement, you should design your application with that in mind from the start, testing the obfuscated builds as you progress. Otherwise, if it's a fairly complex project, you're going to end up with a serious amount of pain.

如果混淆确实是一个关键要求，那么您应该从一开始就考虑到这一点来设计您的应用程序，并随着您的进展测试混淆的构建。否则，如果它是一个相当复杂的项目，你最终会遇到很大的痛苦。