一个不同的问题，即Best .NET obfuscation tools/strategy，询问是否易于使用工具实现混淆 .
我的问题是， is obfuscation effective? 在回复this answer的评论中，有人说“如果你担心来源被盗......混淆对于一个真正的破解者来说几乎是微不足道的” .
我查看了Dotfuscator社区版的输出：它看起来对我来说是模糊的！我不想保持这一点！
我知道简单地“破解”混淆软件可能相对容易：因为您只需要找到软件中的任何位置即可实现您想要破解的任何位置（通常是许可证保护），并添加跳转以跳过它 .
如果担心的不仅仅是最终用户或“盗版者”的破解：如果担心“来源被盗”，即如果您是软件供应商，而您担心的是另一个供应商（潜在的竞争对手）逆转 - 设计你的来源，然后他们可以使用或添加到他们自己的产品......简单混淆在多大程度上是对这种风险的充分或不充分的保护？
1st edit:
有问题的代码大约是20个KLOC，它运行在最终用户机器上（用户控件，而不是远程服务） .
如果混淆真的“对于一个真正的破解者来说几乎是微不足道的”，我想要了解一下它的效果是不是很有效 .
2nd edit:
我正在逆转算法：更担心他们将算法的实际实现（即源代码）重新用于他们自己的产品 .
确定20个KLOC是几个月的开发工作，是否需要多于或少于这个（几个月）对其进行反混淆处理？
是否有必要对某些东西进行反混淆处理以便：或者一个理智的竞争对手可能只是将它批量地整合到他们的产品中，同时仍然模糊不清，接受它是一个维护噩梦，并希望它几乎不需要维护？如果这种情况是可能的，那么混淆.Net代码比编译的机器代码更容易受到这种影响吗？
大多数混淆“军备竞赛”的目的主要是阻止人们甚至“破解”某些东西（例如查找和删除实施许可保护/执法的代码片段），而不是防止“来源盗窃”？
9 回答
您担心人们窃取您产品中使用的特定算法 . 要么你是Fair Isaac，要么你需要使用的不仅仅是x的方式来区分自己 . 如果你解决了代码中的一些问题，而这个问题是别人困惑几个小时无法解决的问题，你应该拥有计算机科学博士学位和/或专利来保护你的发明 . 99％的软件产品不成功或特殊，因为算法 . 他们之所以成功，是因为他们的作者做了大量工作，将众所周知且易于理解的概念整合到一个产品中，这个产品能够满足客户的需求并以低于支付其他人重新购买成本的成本出售 .
这样看吧;您输入问题的WMD编辑器由SO团队进行逆向工程，以修复一些错误并进行som增强 . 该代码被混淆了 . 你永远不会阻止聪明的动机人员破解你的代码，你可以希望的最好的方法是让诚实的人保持诚实并使其有点难以打破 .
我倾向于认为，如果你想保护你的来源，混淆真的不是很有效 . 对于该领域的真正专家（我不是指这里的软件专家或破解者，我指的是代码功能领域的专家），通常他或她不需要看代码，只是了解它如何对特殊输入，边缘情况等做出反应，以了解如何实现与受保护功能等效的副本或代码 . 因此，在保护您的专有技术方面没有多大帮助 .
如果您的代码中的IP必须不惜一切代价受到保护，那么您应该在安全的远程服务器上将您的软件功能作为服务提供 .
好的混淆会保护你到一定程度，但这完全取决于打破代码的“奖励”所需的努力程度 . 如果您正在谈论停止普通业务用户，那么商业混淆器应该足够了 .
如果您曾见过反汇编程序的输出，您就会意识到为什么混淆总会失败 .
我认为混淆是防止破解的有效手段：
Protect .NET Code from reverse engineering
但是，您的问题具体是关于 source theft ，这是一个有趣的话题 . 在Eldad Eiliams的书“Reversing: Secrets of Reverse Engineering”中，作者讨论了源头盗窃是前两章逆向工程背后的原因之一 .
基本上，它归结为唯一的机会是你有一个非常具体的，难以设计的，与你的领域相关的算法，让你在竞争中占据优势 . 这是尝试对应用程序的一小部分进行逆向工程的唯一时间 .
所以，除非你有一些绝密的算法，你不希望你的竞争对手，你不需要担心来源被盗 . 从应用程序中撤消任何大量源代码所涉及的成本很快超过了从头开始重写代码的成本 .
即使你确实有一些你不希望它们拥有的算法，你也无法阻止确定的和技术娴熟的人获得它（如果应用程序在他们的机器上执行） .
一些常见的反转措施是：
混淆 - 在保护您的来源或防止其被破解方面做得不多 . 但我们不妨让它变得简单，对吧？
第三方包装工 - Themida是最好的包装工之一 . 将可执行文件打包到加密的win32应用程序中 . 如果应用程序也是.NET应用程序，则防止反射 .
自定义打包程序 - 如果您有这方面的技能，有时候编写自己的打包程序是有效的，因为在破解场景中有关如何解压缩应用程序的信息非常少 . 这可以阻止没有经验的RE . 这个tutorial提供了一些关于编写自己的打包器的好信息 .
保持用户机器的行业秘密算法 . 将它们作为删除服务执行，因此指令永远不会在本地执行 . 唯一的"fool-proof"保护方法 .
但是，打包机可以解压缩，混淆并不能真正阻碍那些想要的人看你的应用程序在做什么 . 如果程序在用户计算机上运行，那么它很容易受到攻击 .
最终，它的代码必须作为机器代码执行，通常需要启动调试器，设置一些断点并监视相关操作期间执行的指令以及花费一些时间来查看这些数据 .
你提到你花了几个月的时间为你的应用程序写了~20kLOC . 如果您采取最低限度的预防措施，那么将这些等效的20kLOC从您的应用程序转换为可行的来源将需要几乎一个数量级的时间 .
这就是为什么从您的应用程序中反转小型行业特定算法的成本效益 . 还有别的东西，不值得 .
采取以下虚构的例子：让我说我刚开发了一个全新的iTunes竞争应用程序，它有很多花里胡哨的东西 . 让我们说它花了几十亿的LOC和两年的时间来开发 . 我拥有的一个关键功能是根据您的音乐聆听品味为您提供音乐的新方式 .
苹果公司（他们是海盗）得到了这方面的风，并决定他们真的喜欢你的音乐建议功能，所以他们决定扭转它 . 然后，他们将仅使用该算法进行磨合，反向工程师最终将提出一种可行的算法，该算法在给定相同数据的情况下提供相同的建议 . 然后他们在他们自己的应用程序中实现所述算法，称之为“Genius”并使其下一个10万亿美元 .
这就是源头盗窃的原因 .
没有人会坐在那里反转所有100k LOC来窃取你编译的应用程序的重要部分 . 它只是太昂贵而且太耗时 . 大约90％的时间他们将扭转无聊，非行业秘密的代码，只需处理按钮按下或处理用户输入 . 相反，他们可以聘请他们自己的开发人员从头开始重写大部分资金，只需花费更少的资金，简单地扭转难以设计的重要算法，并为您提供优势（即音乐建议功能） .
混淆是security through obscurity的一种形式，虽然它提供了一些保护，但安全性显然非常有限 .
出于您描述的目的，默默无闻肯定会有所帮助，并且在许多情况下，是足以防止代码被盗的风险 . 但是，如果有足够的时间和精力，代码仍然存在“未经模糊处理”的风险 . 对整个代码库进行不模糊处理实际上是不可能的，但如果感兴趣的一方只希望确定您如何执行某些部分，则风险会更高 .
最后，只有您可以确定风险对您或您的企业是否值得 . 但是，在许多情况下，如果您希望将产品销售给客户以在其自己的环境中使用，则这是您唯一的选择 .
关于“为什么它无效” - 原因是因为无论使用何种混淆技术，破解者都可以使用调试器来查看代码的运行位置 . 然后，他们可以使用它来解决您已经实施的任何保护机制，例如序列号或“电话回家”系统 .
我不相信评论实际上引用了“代码盗窃”，因为您的代码将被盗并在另一个项目中使用 . 因为他们使用了“cracker”这个词，我相信他们在谈论软件盗版方面的“盗窃” . Crackers专注于解决保护机制;他们对将源代码用于其他目的不感兴趣 .
大多数人倾向于编写看似混淆的代码并且没有阻止破解者，那么有什么区别？
编辑：
好的，认真的时间 . 如果你真的想做一些难以打破的东西，那就看多态编码（不要混淆多态） . 制作自我变异的代码，破坏是一种严重的痛苦并且会让他们猜测 .
http://en.wikipedia.org/wiki/Polymorphic_code
最后，没有什么是不可能逆向工程的 .
简短的回答是肯定的，不是;这完全取决于你想要阻止的东西 . Secure Programming Cookbook的第12节在第653页上有一些有趣的评论（在谷歌图书预览中很方便） . 它将反篡改分为四类：零日（减慢攻击者因此需要很长时间才能完成他们想要的事情），保护专有算法以防止逆向工程，我可以通常拥有它对于试图弄乱你的应用程序的人来说只是一个烦恼，就像任何好的安全措施一样，当它与其他防篡改技术结合使用时效果最好 .