If you have a .NET Exe file there is a FAR better solution.
I use Themida and can tell that it works very well.
The only drawback of Themida is that it cannot protect .NET Dlls. (It also protects C++ code in Exe and DLLs)
Themida is by far cheaper than the here mentioned obfuscators and is the best in antipiracyprotection on the market. It creates a virtual machine were critical parts of your code are run and runs several threads that detect manipulation or breakpoints set by a cracker. It converts the .NET Exe into something that Reflector does not even recognize as a .NET assembly anymore.
I have tried a product called Rummage and it does a good job in giving you some control ... Although it lacks many things that Eziriz offers but price for Rummage is too good...
There's a good open source version called Obfuscar. Seems to work fine. Types, properties, fields, methods can be excluded. The original is here: https://code.google.com/p/obfuscar/, but since it seems to not be updated anymore
You may also want to look at new code protection technologies such as Metaforic and V.i.Labs and new software copy protection technologies such as ByteShield. Disclosure: I work for ByteShield.
I also use smartassembly. However, I don't know how it works for a web application. However, I'd like to point out that if your app uses shareware type protection, make sure it don't check a license with a boolean return. it's too easy to byte crack. http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx
I had to use a obfuscation/resource protection in my latest rpoject and found Crypto Obfuscator as a nice and simple to use tool. The serialization issue is only a matter of settings in this tool.
We're using SmartAssembly on our windows client. Works just fine.
Does add some extra problems too. Printing out your class names in log files/exceptions have to be de-obfuscated. And of course can't create a class from its name. So it's a good idea to take a look at your client and see which problems you can get by obfuscating.
I've been obfuscating code in the same application since .Net 1, and it's been a major headache from a maintenance perspective. As you've mentioned, the serialization problem can be avoided, but it's really easy to make a mistake and obfuscate something you didn't want obfuscated. It's easy to break the build, or to change the obfuscation pattern and not be able to open old files. Plus it can be difficult to find out what went wrong and where.
Our choice was Xenocode, and were I to make the choice again today I would prefer to not obfuscate the code, or use Dotfuscator.
至于序列化，我已将该代码移至另一个 DLL 中并将其包含在项目中。 我推断其中没有任何秘密不在 XML 中，因此不需要混淆。 如果这些类中有任何严重的代码，则在主程序集中使用分部类应该可以覆盖它。
I've recently tried piping the output of one free obfuscator into the another free obfuscator - namely Dotfuscator CE and the new Babel obfuscator on CodePlex. More details on my blog.
As for serialization, I've moved that code into a different DLL and included that in the project. I reasoned that there weren't any secrets in there that aren't in the XML anyway, so it didn't need obfuscation. If there is any serious code in those classes, using partial classes in the main assembly should cover it.
您应该使用最便宜且最知名的平台，然后就到此为止了。 高级语言的混淆是一个难题，因为 VM 操作码流不会遇到本地操作码流所面临的两个最大问题：函数/方法识别和寄存器别名。
关于字节码逆向，您应该了解的是，安全测试人员检查直接 X86 代码并查找其中的漏洞已经是标准做法。 在原始 X86 中，您甚至不一定能找到有效的函数，更不用说在整个函数调用中跟踪局部变量了。 在几乎任何情况下，本机代码逆向者都无法访问函数和变量名称，除非他们正在审查 Microsoft 代码，而 MSFT 会为此向公众提供该信息。
You should use whatever is cheapest and best known for your platform and call it a day. Obfuscation of high-level languages is a hard problem, because VM opcode streams don't suffer from the two biggest problems native opcode streams do: function/method identification and register aliasing.
What you should know about bytecode reversing is that it is already standard practice for security testers to review straight X86 code and find vulnerabilities in it. In raw X86, you cannot necessarily even find valid functions, let alone track a local variable throughout a function call. In almost no circumstances do native code reversers have access to function and variable names --- unless they're reviewing Microsoft code, for which MSFT helpfully provides that information to the public.
"Dotfuscation" works principally by scrambling function and variable names. It's probably better to do this than publish code with debug-level information, where the Reflector is literally giving up your source code. But anything you do beyond this is likely to get into diminishing returns.
The "Professional" version of the product costs money but is better.
Do you really need your code obfuscated? Usually there is very little wrong with your application being decompiled, unless it is used for security purposes. If you are worried about people "stealing" your code, don't be; the vast majority of people looking at your code will be for learning purposes. Anyway, there is no totally effective obfuscation strategy for .NET - someone with enough skill will always be able to decompile/change you application.
Avoid Reactor. It is completely useless (and yes I paid for a license). Xenocode was the best one I encountered and bought a license for too. The support was very good but I didn't need it much as it just worked. I tested every obfuscator I could find and my conclusion is that xenocode was far and away the most robust and did the best job (also possibility to post process your .NET exe to a native exe which I didn't see anywhere else.).
There are two main differences between reactor and xenocode. The first one is that Xenocode actually works. The second is that the execution speed of your assemblies is no different. With reactor it was about 6 million times slower. I also got the impression that reactor was a one man operation.
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).
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.
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.
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.
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". :)
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.
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.
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.
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.
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
Just to be clear I'm just a custumer who likes the product and not in any way related with the company.
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.
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.
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.
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.
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.
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.
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).
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.
Dotfuscator Pro - Couldn't find price on website. Currently in discussions to get a quotation. Sounds ominous.
Confuser - an open source project which works quite well (to confuse ppl, just as the name implies).
Note: ConfuserEx is reportedly "broken" according to Issue #498 on their GitHub repo.
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.
We've tried DotFuscator Pro, SmartAssembly, XenoCode, Salamander, and several small time apps whose names escape me.
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.
发布评论
评论（30）
混淆并不是真正的保护。
如果您有 .NET Exe 文件，那么有一个更好的解决方案。
我使用Themida并且可以看出它效果非常好。
Themida 的唯一缺点是它无法保护 .NET Dll。
（它还保护 Exe 和 DLL 中的 C++ 代码）
Themida 比这里提到的混淆器便宜得多，并且在反 盗版 保护方面是最好的在市场上。 它会创建一个虚拟机，在其中运行代码的关键部分，并运行多个线程来检测破解者设置的操作或断点。 它将 .NET Exe 转换为 Reflector 甚至不再识别为 .NET 程序集的东西。
请阅读他们网站上的详细说明：
http://www.oreans.com/themida_features.php
Obfuscating is not a real protection.
If you have a .NET Exe file there is a FAR better solution.
I use Themida and can tell that it works very well.
The only drawback of Themida is that it cannot protect .NET Dlls.
(It also protects C++ code in Exe and DLLs)
Themida is by far cheaper than the here mentioned obfuscators and is the best in anti piracy protection on the market. It creates a virtual machine were critical parts of your code are run and runs several threads that detect manipulation or breakpoints set by a cracker. It converts the .NET Exe into something that Reflector does not even recognize as a .NET assembly anymore.
Please read the detailed description on their website:
http://www.oreans.com/themida_features.php
我尝试过一款名为 Rummage 的产品，它在给你一些控制方面做得很好......虽然它缺乏 Eziriz 提供的很多东西，但 Rummage 的价格太优惠了......
I have tried a product called Rummage and it does a good job in giving you some control ... Although it lacks many things that Eziriz offers but price for Rummage is too good...
我尝试了 Eziriz 演示版......我喜欢它。 但从来没有带过软件。
I tried Eziriz demo version....I liked it. But never brought the software.
SmartAssembly 很棒，我的大部分项目都用过
SmartAssembly is great,I was used in most of my projects
有一个很好的开源版本，称为 Obfuscar。 似乎工作正常。 可以排除类型、属性、字段、方法。 原文位于：https://code.google.com/p/obfuscar/ ，不过好像不再更新了
There's a good open source version called Obfuscar. Seems to work fine. Types, properties, fields, methods can be excluded. The original is here: https://code.google.com/p/obfuscar/, but since it seems to not be updated anymore
您可能还想了解新的代码保护技术，例如 Metaforic 和 ViLabs 和新的软件版权保护技术，例如 ByteShield。 披露：我在 ByteShield 工作。
You may also want to look at new code protection technologies such as Metaforic and V.i.Labs and new software copy protection technologies such as ByteShield. Disclosure: I work for ByteShield.
我也使用智能装配。 但是，我不知道它如何适用于网络应用程序。 但是，我想指出，如果您的应用程序使用共享软件类型保护，请确保它不会检查带有布尔返回值的许可证。 字节破解太容易了。
http://blogs.compdj.com/post/Binary- hack-a-NET-executable.aspx
I also use smartassembly. However, I don't know how it works for a web application. However, I'd like to point out that if your app uses shareware type protection, make sure it don't check a license with a boolean return. it's too easy to byte crack.
http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx
我必须在最新的 rpoject 中使用混淆/资源保护，并发现 Crypto Obfuscator作为一个漂亮且易于使用的工具。 序列化问题只是该工具中的设置问题。
I had to use a obfuscation/resource protection in my latest rpoject and found Crypto Obfuscator as a nice and simple to use tool. The serialization issue is only a matter of settings in this tool.
这完全取决于您使用的编程语言。
阅读文章：混淆代码
It all depends on the programming language, which you use.
Read the article: Obfuscated code
免费的方法是在 Visual Studio 中使用 dotfuscator，否则你必须出去购买像 Postbuild 这样的混淆器（http://www.xenocode.com/Landing/Obfuscation.aspx)
the free way would be to use dotfuscator from within visual studio, otherwise youd have to go out and buy an obfuscator like Postbuild (http://www.xenocode.com/Landing/Obfuscation.aspx)
我们在 Windows 客户端上使用 SmartAssembly。 效果很好。
也确实增加了一些额外的问题。 在日志文件/异常中打印出类名必须进行反混淆。 当然，不能从类的名称创建类。 因此，最好检查一下您的客户端，看看通过混淆可以解决哪些问题。
We're using SmartAssembly on our windows client. Works just fine.
Does add some extra problems too. Printing out your class names in log files/exceptions have to be de-obfuscated. And of course can't create a class from its name. So it's a good idea to take a look at your client and see which problems you can get by obfuscating.
这是 Microsoft 自己提供的文档。 希望有所帮助...，这是 2003 年的内容，但可能仍然具有相关性。
Here's a document from Microsoft themselves. Hope that helps..., it's from 2003, but it might still be relevant.
自 .Net 1 以来，我一直在同一应用程序中混淆代码，从维护角度来看，这是一个令人头疼的问题。 正如您所提到的，序列化问题是可以避免的，但是很容易犯错误并混淆您不想混淆的内容。 破坏构建或更改混淆模式很容易并且无法打开旧文件。 另外，找出问题所在以及问题所在也很困难。
我们的选择是 Xenocode，如果我今天再次做出选择，我宁愿不混淆代码，或者使用 Dotfuscator。
I've been obfuscating code in the same application since .Net 1, and it's been a major headache from a maintenance perspective. As you've mentioned, the serialization problem can be avoided, but it's really easy to make a mistake and obfuscate something you didn't want obfuscated. It's easy to break the build, or to change the obfuscation pattern and not be able to open old files. Plus it can be difficult to find out what went wrong and where.
Our choice was Xenocode, and were I to make the choice again today I would prefer to not obfuscate the code, or use Dotfuscator.
我发现 Agile.Net 为您的 .Net 程序集提供了很好的保护，因为它不仅提供混淆，还提供加密。 下载免费试用版。
http://secureteam.net/NET-Code-Protection.aspx
http://secureteam.net/downloads.aspx
I found the Agile.Net provide pretty good protection for your .Net Assembly because it offer not only obfuscation but also encryption. Download a free trail.
http://secureteam.net/NET-Code-Protection.aspx
http://secureteam.net/downloads.aspx
我最近尝试将一个免费混淆器的输出通过管道传输到另一个免费混淆器 - 即 Dotfuscator CE 和 CodePlex 上的新 Babel 混淆器。 更多详细信息在我的博客上。
至于序列化，我已将该代码移至另一个 DLL 中并将其包含在项目中。 我推断其中没有任何秘密不在 XML 中，因此不需要混淆。 如果这些类中有任何严重的代码，则在主程序集中使用分部类应该可以覆盖它。
I've recently tried piping the output of one free obfuscator into the another free obfuscator - namely Dotfuscator CE and the new Babel obfuscator on CodePlex. More details on my blog.
As for serialization, I've moved that code into a different DLL and included that in the project. I reasoned that there weren't any secrets in there that aren't in the XML anyway, so it didn't need obfuscation. If there is any serious code in those classes, using partial classes in the main assembly should cover it.
您应该使用最便宜且最知名的平台，然后就到此为止了。 高级语言的混淆是一个难题，因为 VM 操作码流不会遇到本地操作码流所面临的两个最大问题：函数/方法识别和寄存器别名。
关于字节码逆向，您应该了解的是，安全测试人员检查直接 X86 代码并查找其中的漏洞已经是标准做法。 在原始 X86 中，您甚至不一定能找到有效的函数，更不用说在整个函数调用中跟踪局部变量了。 在几乎任何情况下，本机代码逆向者都无法访问函数和变量名称，除非他们正在审查 Microsoft 代码，而 MSFT 会为此向公众提供该信息。
“Dotfuscation”主要通过扰乱函数和变量名称来工作。 这样做可能比发布带有调试级别信息的代码更好，因为反射器实际上会放弃您的源代码。 但超出此范围所做的任何事情都可能会导致收益递减。
You should use whatever is cheapest and best known for your platform and call it a day. Obfuscation of high-level languages is a hard problem, because VM opcode streams don't suffer from the two biggest problems native opcode streams do: function/method identification and register aliasing.
What you should know about bytecode reversing is that it is already standard practice for security testers to review straight X86 code and find vulnerabilities in it. In raw X86, you cannot necessarily even find valid functions, let alone track a local variable throughout a function call. In almost no circumstances do native code reversers have access to function and variable names --- unless they're reviewing Microsoft code, for which MSFT helpfully provides that information to the public.
"Dotfuscation" works principally by scrambling function and variable names. It's probably better to do this than publish code with debug-level information, where the Reflector is literally giving up your source code. But anything you do beyond this is likely to get into diminishing returns.
我在使用 Smartassemble 时没有遇到任何问题。
I have had no problems with Smartassembly.
您可以使用“Dotfuscator Community Edition” - 它默认出现在 Visual Studio 2008 Professional 中。 您可以在以下位置阅读相关内容：
http://msdn .microsoft.com/en-us/library/ms227240%28VS.80%29.aspx
http://www.preemptive.com/dotfuscator.html
的“专业”版本产品要花钱但更好。
你真的需要混淆你的代码吗？ 通常，您的应用程序被反编译不会有什么问题，除非是出于安全目的。 如果您担心人们“窃取”您的代码，请不要担心； 绝大多数人查看您的代码都是出于学习目的。 无论如何，.NET 没有完全有效的混淆策略 - 具有足够技能的人总是能够反编译/更改您的应用程序。
You could use "Dotfuscator Community Edition" - it comes by default in Visual Studio 2008 Professional. You can read about it at:
http://msdn.microsoft.com/en-us/library/ms227240%28VS.80%29.aspx
http://www.preemptive.com/dotfuscator.html
The "Professional" version of the product costs money but is better.
Do you really need your code obfuscated? Usually there is very little wrong with your application being decompiled, unless it is used for security purposes. If you are worried about people "stealing" your code, don't be; the vast majority of people looking at your code will be for learning purposes. Anyway, there is no totally effective obfuscation strategy for .NET - someone with enough skill will always be able to decompile/change you application.
避免反应堆。 它完全没用（是的，我支付了许可证费用）。 Xenocode 是我遇到过的最好的一个，也购买了许可证。 支持非常好，但我并不需要太多，因为它刚刚起作用。 我测试了我能找到的每一个混淆器，我的结论是 xenocode 无疑是最强大的并且做得最好（也可以将您的 .NET exe 后处理为我在其他地方没有看到的本机 exe）。
reactor 和 xenocode 之间有两个主要区别。
第一个是 Xenocode 确实有效。
第二个是程序集的执行速度没有什么不同。 使用反应堆时，速度慢了约 600 万倍。 我还觉得反应堆是一个人操作的。
Avoid Reactor. It is completely useless (and yes I paid for a license). Xenocode was the best one I encountered and bought a license for too. The support was very good but I didn't need it much as it just worked. I tested every obfuscator I could find and my conclusion is that xenocode was far and away the most robust and did the best job (also possibility to post process your .NET exe to a native exe which I didn't see anywhere else.).
There are two main differences between reactor and xenocode.
The first one is that Xenocode actually works.
The second is that the execution speed of your assemblies is no different. With reactor it was about 6 million times slower. I also got the impression that reactor was a one man operation.
在过去的两天里，我一直在尝试 Dotfuscator Community Edition Advanced（注册与 Visual Studio 捆绑在一起的基本 CE 后可以免费下载）。
我认为更多人不使用混淆作为默认选项的原因是，与风险相比，这是一个严重的麻烦。 在较小的测试项目中，我可以花费很多精力来运行混淆的代码。 通过 ClickOnce 部署一个简单的项目很麻烦，但在使用 mage 手动签署清单后可以实现。 唯一的问题是，出现错误时，堆栈跟踪会被混淆，并且 CE 没有封装反混淆器或澄清器。
我试图混淆一个基于 Excel 的 VSTO 的真实项目，其中包含 Virtual Earth 集成、大量 Web 服务调用、IOC 容器以及大量反射。 这是不可能的。
如果混淆确实是一个关键要求，那么您应该从一开始就考虑到这一点来设计您的应用程序，并随着您的进展测试混淆的版本。 否则，如果这是一个相当复杂的项目，你最终会遭受巨大的痛苦。
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).
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.
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.
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.
我们有一个多层应用程序，带有 asp.net 和 winform 界面，也支持远程处理。 我使用任何混淆器都没有问题，除了加密类型之外，它会生成一个加载程序，这可能会以各种意想不到的方式出现问题，而且在我看来不值得。 实际上，我的建议更像是“避免像瘟疫一样加密加载器类型混淆器”。 :)
根据我的经验，任何混淆器都可以很好地处理 .net 的任何方面，包括 asp.net 和远程处理，您只需熟悉这些设置并了解您可以在代码的哪些区域将其推进到什么程度。 并花时间尝试对您获得的内容进行逆向工程，看看它如何在各种设置下工作。
多年来，我们在商业应用程序中使用了几种，最终选择了 9rays.net 的 Spices 混淆器，因为价格合适，它能完成工作，而且他们有很好的支持，尽管我们已经很多年不再需要支持了，但说实话我认为使用哪种混淆器并不重要，如果您想让它与远程处理和 asp.net 一起正常工作，问题和学习曲线都是相同的。
正如其他人所提到的，您真正所做的一切相当于一把挂锁，将其他诚实的人拒之门外，或者使简单地重新编译应用程序变得更加困难。
对于大多数人来说，许可通常是关键领域，无论如何，您绝对应该使用某种数字签名证书系统来进行许可。 如果您没有适当的智能系统，那么您最大的损失将来自随意共享许可证，破坏许可系统的人一开始就不会购买。
很容易走得太远，对您的客户和您的业务产生负面影响，做简单合理的事情，然后就不用担心。
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". :)
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.
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.
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.
加密混淆器解决您的所有问题和场景。 它：
Crypto Obfuscator address all your concerns and scenarios. It :
简短的回答是你不能。
有各种各样的工具会让别人更难阅读你的代码 - 其他答案已经指出了其中一些工具。
然而，所有这些只会增加阅读的难度——它们增加了所需的工作量，仅此而已。 通常这足以阻止临时读者，但决心深入研究代码的人总是能够做到这一点。
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.
我也一直在使用 SmartAssembly。
我发现 Ezrinz .Net Reactor 在 .net 应用程序上更适合我。
它混淆、支持 Mono、合并程序集，它还有一个非常好的许可模块来创建试用版本或将许可证链接到特定机器（非常容易实现）。
价格也非常有竞争力，当我需要支持时，他们很快。
Eziriz
需要澄清的是，我只是喜欢该产品的客户，与公司没有任何关系。
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
Just to be clear I'm just a custumer who likes the product and not in any way related with the company.
我尝试过市场上几乎所有的混淆器，我认为 SmartAssembly 是最好的。
I have tried almost every obfuscator on the market and SmartAssembly is the best in my opinion.
我一直在使用智能装配。 基本上，你选择一个 dll，它会返回混淆的结果。 它似乎运行良好，到目前为止我还没有遇到任何问题。 非常非常容易使用。
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.
如果您正在寻找免费的，您可以尝试 Visual Studio 附带的 DotObfuscator Community Edition 或 Eazfuscator.NET。
自 2012 年 6 月 29 日起，Eazfuscator.NET 现已商业化。 最后一个免费可用版本是 3.3。
If your looking for a free one you could try DotObfuscator Community Edition that comes with Visual Studio or Eazfuscator.NET.
Since June 29, 2012, Eazfuscator.NET is now commercial. The last free available version is 3.3.
回到.Net 1.1，混淆是必不可少的：反编译代码很容易，您可以从汇编到 IL，再到 C# 代码，然后毫不费力地再次编译它。
现在对于 .Net 3.5，我完全不确定。 尝试反编译 3.5 程序集； 你得到的东西离编译还有很长的路要走。
添加 3.5 的优化（比 1.1 好得多）以及通过反射处理匿名类型、委托等的方式（重新编译它们是一场噩梦）。 添加 lambda 表达式、编译器“魔法”（如 Linq-syntax 和
var）以及 C#2 函数（如yield）（这会产生名称不可读的新类）。 您的反编译代码最终距离可编译还有很长的路要走。拥有大量时间的专业团队仍然可以对其进行逆向工程，但对于任何混淆的代码也是如此。 他们从中得到的代码将是无法维护的，并且很可能有很多错误。
我建议对你的程序集进行密钥签名（这意味着如果黑客可以重新编译一个程序集，他们就必须重新编译所有程序集），但我认为混淆不值得。
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.
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.
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 likeyield(which results in new classes with unreadable names). Your decompiled code ends up a long long way from compilable.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.
我现在正陷入困境，试图找到一个好的解决方案。 这是迄今为止我的印象。
Xenocode - 我有一个旧的 Xenocode2005 许可证，我用它来混淆我的 .net 2.0 程序集。 它在 XP 上运行良好，是一个不错的解决方案。 我当前的项目是 .net 3.5，我使用的是 Vista，支持人员告诉我可以尝试一下，但 2005 版本甚至无法在 Vista 上运行（崩溃），所以我现在必须以令人惊叹的价格购买“PostBuild2008” 1900 美元。 这可能是一个很好的工具，但我不会找出答案。 太贵了。
Reactor.Net - 这是一个更具吸引力的价格点，并且在我的独立可执行文件上运行良好。 许可模块也很好，可以节省我很多精力。 不幸的是，它缺少一个关键功能，那就是从混淆中排除内容的能力。 这使得无法实现我需要的结果（将多个程序集合并在一起，混淆一些程序集，不混淆其他程序集）。
SmartAssembly - 我为此下载了 Eval，它运行得非常完美。 我能够实现我想要的一切，并且界面是一流的。 价格点还是有点高。
Dotfuscator Pro - 无法在网站上找到价格。 目前正在讨论以获得报价。 听起来不祥。
Confuser - 一个运行良好的开源项目（顾名思义，用于迷惑人们）。
注意：据报道，根据 GitHub 存储库上的 Issue #498，ConfuserEx 已“损坏”。
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.
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).
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.
Dotfuscator Pro - Couldn't find price on website. Currently in discussions to get a quotation. Sounds ominous.
Confuser - an open source project which works quite well (to confuse ppl, just as the name implies).
Note: ConfuserEx is reportedly "broken" according to Issue #498 on their GitHub repo.
我们已经尝试了许多混淆器。 它们都不适用于使用远程处理的大型客户端/服务器应用程序。 问题是客户端和服务器共享一些dll，而我们还没有找到任何可以处理它的混淆器。
我们尝试过 DotFuscator Pro、SmartAssembly、XenoCode、Salamander 和几个我记不清名字的小型应用程序。
坦率地说，我确信混淆是一个大黑客。
即使它解决的问题也不完全是一个真正的问题。 您真正需要保护的唯一内容是连接字符串、激活码以及诸如此类的安全敏感内容。 另一家公司将对你的整个代码库进行逆向工程并从中创建竞争产品的说法是偏执经理的噩梦，而不是现实。
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.
We've tried DotFuscator Pro, SmartAssembly, XenoCode, Salamander, and several small time apps whose names escape me.
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.