Obsfucation is limited in it's effectiveness, it might keep the casual guy away. The most effective obsfucation is making only the smallest amount of code available to the user. If you can, make your app run depend heavily on a fat server.
We don't use obfuscation for "non public" applications but we use it for public available applications. The obfuscated app contains plenty of highly sophisticated code which took us an exorbitant amount of time to write and that's the reason that let me think that obfuscation is a must - at least in that case.
I wouldn't worry about it too much. I'd rather focus on putting out an awesome product, getting a good user base, and treating your customers right than worry about the minimal percentage of users concerned with stealing your code or looking at the source.
Remember, obfuscation is not encryption. IMHO, if somebody perceives value in reverse-engineering your code, they will do it. That's true for managed code or native code, obfuscated or not. Sure, obfuscation deters the casual observer, but is your business actually threatened by such people? Every .NET obfuscation method I've seen makes your life as a developer harder.
We currently obfuscate all our output, even though we are a small outfit who sells specialist software to a small number of clients.
We made this decision for one simple reason - we discovered a disgruntled ex-employee was actively approaching our clients requesting binaries - there was some some concern he was intending to reverse engineer newer features in order to offer competing functionality.
Of course he is still able to do this if he uses the software, but there is no reason to make it easy for him.
例如，每次使用匿名类型时，您都会得到使用相当晦涩的名称编译回来的 IL。 每次你使用yield你都会得到一个全新的类，它同时实现了IEnumerable和IEnumerator（聪明的优化，不可读的代码）。 每次使用匿名委托时，您都会得到一个新方法，其名称在我所知道的每种 .Net 语言中都无效，但在 IL 中没问题。
No new obfuscation, but lots of compiler tricks since 1.1
For instance every time you use an anonymous type you get IL that compiles back with a pretty obscure name. Every time you use yield you get a whole new class that implements both IEnumerable and IEnumerator (clever optimisation, unreadable code). Every time you use an anonymous delegate you get a new method with a name that's invalid in every .Net language that I know of, but that's fine in the IL.
Having had some discussions with my manager at work, he said he doesn't obfuscate, but does NGEN on install, apparantly that should be enough to stop Reflector working on your assemblies, but I have no idea if this is true and to what extent, so please don't take it as gospel :)
This doesn't offer any kind of protection against disassembly. First I imagine its quite possible to extract raw files from any installation package like an MSI or a CAB file.
But more importantly, Ngen runs on the client machine after the assembly has been installed. Ngen just forces the assembly to compile now instead of later using the JIT. The original assembly remains and is unmodified and it must remain because Ngen might not be able to compile the entire assembly.
Ngen is for performance, not security, and does nothing to prevent disassembly or make it even slightly more difficult.
I think to some extent we should ALL be worrying about our IP :)
Good question though as its something I am keen to know more about (I currently do not obfuscate).
Having had some discussions with my manager at work, he said he doesn't obfuscate, but does NGEN on install, apparantly that should be enough to stop Reflector working on your assemblies, but I have no idea if this is true and to what extent, so please don't take it as gospel :)
发布评论
评论（10）
同意，大多数知道如何编码的人，哪怕只是一点点，都不需要窃取你的代码！
Agree, most people who know how to code even a little bit do not need to steal your code!
混淆的有效性是有限的，它可能会让那些不经意的人望而却步。 最有效的混淆是只向用户提供最少量的代码。 如果可以的话，让你的应用程序运行很大程度上依赖于胖服务器。
Obsfucation is limited in it's effectiveness, it might keep the casual guy away. The most effective obsfucation is making only the smallest amount of code available to the user. If you can, make your app run depend heavily on a fat server.
我们不会对“非公共”应用程序使用混淆，但我们将其用于公共可用的应用程序。 混淆的应用程序包含大量高度复杂的代码，这些代码花费了我们大量的时间来编写，这就是让我认为混淆是必须的原因 - 至少在这种情况下。
We don't use obfuscation for "non public" applications but we use it for public available applications. The obfuscated app contains plenty of highly sophisticated code which took us an exorbitant amount of time to write and that's the reason that let me think that obfuscation is a must - at least in that case.
我不会太担心。 我宁愿专注于推出出色的产品，获得良好的用户群，并正确对待您的客户，而不是担心极少数用户担心窃取您的代码或查看源代码。
I wouldn't worry about it too much. I'd rather focus on putting out an awesome product, getting a good user base, and treating your customers right than worry about the minimal percentage of users concerned with stealing your code or looking at the source.
请记住，混淆不是加密。 恕我直言，如果有人认为对你的代码进行逆向工程的价值，他们就会这么做。 对于托管代码或本机代码来说都是如此，无论是否经过混淆。 当然，混淆会阻止漫不经心的观察者，但您的企业真的受到这些人的威胁吗？ 我见过的每一种 .NET 混淆方法都会让开发人员的生活变得更加困难。
有些服务提供真正的加密，例如 Microsoft 的 SLPS。 请参阅http://www.microsoft.com/slps/default.aspx
Remember, obfuscation is not encryption. IMHO, if somebody perceives value in reverse-engineering your code, they will do it. That's true for managed code or native code, obfuscated or not. Sure, obfuscation deters the casual observer, but is your business actually threatened by such people? Every .NET obfuscation method I've seen makes your life as a developer harder.
There are services that offer true encryption, such as SLPS from Microsoft. See http://www.microsoft.com/slps/default.aspx
尽管我们是一家向少数客户销售专业软件的小公司，但我们目前对所有输出进行了混淆。
我们做出这个决定的原因很简单 - 我们发现一位心怀不满的前雇员正在积极向我们的客户索要二进制文件 - 有人担心他打算对新功能进行逆向工程以提供竞争功能。
当然，如果他使用该软件，他仍然可以做到这一点，但没有理由让他变得容易。
We currently obfuscate all our output, even though we are a small outfit who sells specialist software to a small number of clients.
We made this decision for one simple reason - we discovered a disgruntled ex-employee was actively approaching our clients requesting binaries - there was some some concern he was intending to reverse engineer newer features in order to offer competing functionality.
Of course he is still able to do this if he uses the software, but there is no reason to make it easy for him.
没有新的混淆，但自 1.1 以来有很多编译器技巧。
例如，每次使用匿名类型时，您都会得到使用相当晦涩的名称编译回来的 IL。 每次你使用yield你都会得到一个全新的类，它同时实现了IEnumerable和IEnumerator（聪明的优化，不可读的代码）。 每次使用匿名委托时，您都会得到一个新方法，其名称在我所知道的每种 .Net 语言中都无效，但在 IL 中没问题。
No new obfuscation, but lots of compiler tricks since 1.1
For instance every time you use an anonymous type you get IL that compiles back with a pretty obscure name. Every time you use yield you get a whole new class that implements both IEnumerable and IEnumerator (clever optimisation, unreadable code). Every time you use an anonymous delegate you get a new method with a name that's invalid in every .Net language that I know of, but that's fine in the IL.
@罗布·库珀
这不提供任何类型的反汇编保护。 首先，我认为很可能从任何安装包（例如 MSI 或 CAB 文件）中提取原始文件。
但更重要的是，Ngen 在安装程序集后在客户端计算机上运行。 Ngen 只是强制程序集立即编译，而不是稍后使用 JIT。 原始程序集保留且未修改，并且必须保留，因为 Ngen 可能无法编译整个程序集。
Ngen 是为了性能，而不是安全性，并且不会阻止反汇编或使其变得更加困难。
@Rob Cooper
This doesn't offer any kind of protection against disassembly. First I imagine its quite possible to extract raw files from any installation package like an MSI or a CAB file.
But more importantly, Ngen runs on the client machine after the assembly has been installed. Ngen just forces the assembly to compile now instead of later using the JIT. The original assembly remains and is unmodified and it must remain because Ngen might not be able to compile the entire assembly.
Ngen is for performance, not security, and does nothing to prevent disassembly or make it even slightly more difficult.
对我来说很容易 - 如果你需要保护知识产权 - 混淆 - 如果不需要则不要。
使用正确的工具即可轻松完成。
easy for me - if you need to protect intellectual property - obfuicate - if not dont.
Easy to do with the right tools.
我认为在某种程度上我们都应该担心我们的知识产权：）
好问题，因为我很想了解更多（我目前不混淆）。
在工作中与我的经理进行了一些讨论后，他说他不会混淆，但安装时会执行 NGEN，显然这应该足以阻止 Reflector 在您的程序集上工作，但我不知道这是否属实以及程度如何，所以请不要把它当作福音:)
好问题:)+1
I think to some extent we should ALL be worrying about our IP :)
Good question though as its something I am keen to know more about (I currently do not obfuscate).
Having had some discussions with my manager at work, he said he doesn't obfuscate, but does NGEN on install, apparantly that should be enough to stop Reflector working on your assemblies, but I have no idea if this is true and to what extent, so please don't take it as gospel :)
Good question :) +1