我在another question 中提出了一个关于混淆的观点，有人回答说“混淆并没有停止太多”。
与其在 cmets 上展开辩论，我更希望得到社区的严肃回答，以了解我的代码在使用 X、Y 或 Z 混淆器进行混淆时的安全性，以及是否有任何混淆工具真正完成了工作。
我也对任何解释感兴趣，以便对混淆器的工作原理有一些基本的了解。
据我了解，混淆不能阻止反射和检测方法等，但它会通过歪曲变量名称使方法中的代码可读性降低。那是错的吗？它还有什么作用？
【问题讨论】：
标签： .net security reflection obfuscation
混淆永远不可能真正安全，因为总是可以查看 MSIL。即使有一个好的混淆器，人们也可以简单地从 MSIL 复制你的大部分代码，因为你别无选择，只能编译到 MSIL，所以你真的无能为力。
【讨论】：
有很多方法可以做这种事情——例如，你有没有尝试过自己运行 Reflector？
归根结底，如果您有商业软件，人们会为它付费以获得支持的版本，无论他们是否可以看到源代码 - 这就是有多少开源项目可以赚钱。混淆基本上就是它所说的 - 它使代码更难理解，但实际上并没有隐藏它。值不值，得根据具体情况来判断。
如果您要向企业客户销售软件，我的观点是不值得费心。如果您正在向零售客户销售并且真的想隐藏代码，那么 .NET 可能不是答案。
【讨论】：
如果有人足够专注于获得您的程序，他们就会这样做，再多的混淆也无法改变这一点。我认为Joel Coehoorn's answer 到Securing a .NET Application 总结得很好：
您无法完全保护您的应用。 谢天谢地，你真的不想。 根据我的经验，您需要确保 您的应用程序足以让某人 不能不小心盗版你的 产品，仅此而已。
维基百科在Obfuscation 上有一个不错的部分，特别是他们通过manual obfuscation 让您了解发生的步骤：
暂时重写。采用 特殊值。 更改迭代 进入递归 混淆 构造和无意义的变量 名字 移除中间体 变量和文字 混淆 再次命名 删除文字 删除多余的文本
【讨论】：
这是我在“Assessing and Managing Security Risks Unique to Java and .NET”上发表在 ISSA 期刊上的一篇文章 - 这是一个 PDF 文件，但它涵盖了混淆和许多相关技术。更重要的是，它涵盖了减轻这些风险的过程，以及关于如何将上述所有内容与这些风险的重要性与您的具体情况保持一致的一些建议。
【讨论】：