我在another question提出了一个关于混淆的观点，有人回答说“混淆不会停止太多”。
我没有在评论中开始讨论，而是希望在使用X，Y或Z混淆器进行模糊处理时，我的代码是如何安全的，以及任何混淆工具是否能真正完成工作。
我也对任何解释感兴趣，以获得对混淆器如何工作的基本理解。
根据我的理解，混淆不能阻止反射和检测方法等，但它通过扭曲变量名使得方法中的代码不易被读取。那是错的吗？它还做了什么？
答案 0 :(得分：5)
混淆永远不会真正安全，因为始终可以查看MSIL。即使有一个好的混淆器，人们也可以简单地从MSIL复制你的大部分代码，因为你别无选择，只能编译成MSIL，你真的无能为力。
答案 1 :(得分：1)
有很多方法可以做这种事情 - 例如，你有没有试过自己运行Reflector？
在一天结束时，如果你有商业软件，人们会为它付费获得支持的版本，无论他们是否能看到源代码 - 这就是有多少开源项目赚钱。混淆基本上就是它所说的 - 它使代码更难理解，但实际上并没有隐藏它。是否值得，你必须根据具体情况来判断。
如果您向公司客户销售软件，我的观点是不值得打扰。如果您向零售客户销售并且真的想要隐藏代码，那么.NET可能不是答案。
答案 2 :(得分：0)
答案 3 :(得分：0)
如果某人有足够的专注力来获得他们的计划，那么任何混淆都不会改变这一点。我认为Joel Coehoorn's answer对Securing a .NET Application总结得很好：
您无法完全保护自己的应用。 谢天谢地，你真的不想。 根据我的经验，你需要保证安全 你的应用程序就足够了 不能不小心盗版你的 产品，而不是更多。
维基百科在Obfuscation上有一个不错的部分，特别是他们通过manual obfuscation来了解发生了哪些步骤：
同时重写。使用 特殊价值观。 更改迭代 进入递归 混淆 构造和无意义的变量 姓名 删除中间人 变量和文字 混淆 再次命名 删除文字 删除多余文本
答案 4 :(得分：0)
以下是我在ISSA期刊上发表的一篇文章“Assessing and Managing Security Risks Unique to Java and .NET” - 这是一个PDF文件，但它涵盖了混淆和一些相关技术。更重要的是，它涵盖了减轻这些风险的过程，以及如何使所有上述内容与这些风险的重要性符合您的具体情况的一些建议。