一个不同的问题，即 Best .NET obfuscation tools/strategy , 询问使用工具是否容易实现混淆。
我的问题是，混淆有效吗？ 在回复 this answer 的评论中，有人说“如果你担心源被盗......混淆对于一个真正的破解者来说几乎是微不足道的”。
我查看了 Dotfuscator 社区版的输出:我觉得它很模糊!我不想保持那个!
我知道简单地“破解”混淆软件可能相对容易:因为您只需要找到软件中的任何位置实现您想要破解的任何内容(通常是许可证保护)，然后添加跳转以跳过它。
如果担心不仅仅是最终用户或“盗版者”破解:如果担心是“源盗窃”，即如果您是软件供应商，而您担心的是另一家供应商(潜在竞争对手)，则相反-设计您的来源，然后他们可以将其用于或添加到他们自己的产品中……简单的混淆在多大程度上可以充分或不充分地防止这种风险？
第一次编辑:
有问题的代码大约是 20 KLOC，它在最终用户机器上运行(用户控制，而不是远程服务)。
如果混淆真的“对真正的破解者来说几乎是微不足道的”，我想了解一下 为什么它是无效的(不仅仅是“多少”它无效)。
第二次编辑:
我不担心有人颠倒算法:更担心他们将算法的实际实现(即源代码)重新用于他们自己的产品中。
考虑到 20 KLOC 是几个月的开发工作，去混淆它需要更多还是更少的时间(几个月)？
是否有必要对某些东西进行反混淆以“窃取”它:或者一个理智的竞争对手可能只是在仍然混淆的情况下将其批发并入他们的产品中，接受它是维护的噩梦，并希望它几乎不需要维护？如果这种情况是可能的，那么混淆的 .Net 代码是否比编译的机器代码更容易受到这种攻击？
大多数混淆“军备竞赛”的主要目的是防止人们甚至“破解”某些东西(例如，查找和删除实现许可保护/执行的代码片段)，而不是防止“源代码盗窃”？
最佳答案
我已经讨论了为什么我不认为混淆是防止破解的有效手段:
Protect .NET Code from reverse engineering
但是，您的问题特别是关于 源盗窃 ，这是一个有趣的话题。在 Eldad Eiliams 的书“Reversing: Secrets of Reverse Engineering”中，作者在前两章讨论了源窃取作为逆向工程背后的一个原因。
基本上，归根结底，您成为源盗窃目标的唯一机会是，如果您有一些非常具体、难以设计的与您的域相关的算法，可以让您在竞争中脱颖而出。这几乎是唯一一次尝试对您的应用程序的一小部分进行逆向工程具有成本效益的时间。
因此，除非您拥有某些您不希望竞争对手拥有的绝密算法，否则您无需担心源代码被盗。从应用程序中撤消大量源代码所涉及的成本很快就会超过从头开始重写的成本。
即使您确实有一些您不希望他们拥有的算法，您也无法阻止有决心且技术娴熟的人获得它(如果应用程序在他们的机器上执行)。
一些常见的反逆转措施是:
然而，打包器可以被解包，并且混淆并不会真正阻碍那些想要查看您的应用程序正在做什么的人。如果程序在用户机器上运行，那么它很容易受到攻击。
最终，它的代码必须作为机器代码执行，这通常是启动调试器、设置几个断点和监视在相关操作期间执行的指令以及花一些时间研究这些数据的问题。
你提到你花了几个月的时间为你的应用程序编写~20kLOC。如果您采取最低限度的预防措施，将那些等效的 20kLOC 从您的应用程序转换为可行的源需要几乎一个数量级的时间。
这就是为什么从您的应用程序中逆向小型的、行业特定的算法是唯一具有成本效益的原因。其他任何东西都不值得。
以下面虚构的例子为例:假设我刚刚为 iTunes 开发了一个全新的竞争应用程序，它有很多花里胡哨的东西。假设花了几个 100k LOC 和 2 年的时间来开发。我拥有的一个关键功能是一种根据您的音乐聆听品味为您提供音乐的新方式。
苹果(他们是盗版者)闻到了这一点，并决定他们真的很喜欢你的音乐推荐功能，所以他们决定扭转它。然后他们将只研究该算法，逆向工程师最终会提出一个可行的算法，在给定相同数据的情况下提供等效的建议。然后他们在自己的应用程序中实现上述算法，称其为“天才”并赚取下一个 10 万亿美元。
这就是来源盗窃的下降方式。
没有人会坐在那里并反转所有 100k LOC 来窃取已编译应用程序的重要部分。这只会太昂贵且太耗时。大约 90% 的时间，他们会逆转无聊的、非行业 secret 的代码，这些代码只是简单地处理按钮按下或处理用户输入。相反，他们可以聘请他们自己的开发人员以更少的钱从头开始重写大部分内容，并简单地反转难以设计并为您提供优势的重要算法(即音乐建议功能)。
关于.net - 混淆有多有效？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/551892/