如何有效的是混淆？ [英] How effective is obfuscation?
问题描述
有一个不同的问题，即最佳的.NET混淆工具/战略，询问是否模糊处理是很容易实现使用的工具。
A different question, i.e. Best .NET obfuscation tools/strategy, asks whether obfuscation is easy to implement using tools.
我的问题，虽然是，是混淆有效？在评论答复<一个href="http://stackoverflow.com/questions/551554/can-you-compile-c-without-using-the-net-framework/551565#551565">this回答，有人说的如果你担心源盗窃......混淆几乎是微不足道的一个真正的破解的。
My question though is, is obfuscation effective? In a comment replying to this answer, someone said that "if you're worried about source theft ... obfuscation is almost trivial to a real cracker".
我看着从Dotfuscator的社区版的输出：它看起来混淆给我！我不想维护！
I've looked at the output from the Community Edition of Dotfuscator: and it looks obfuscated to me! I wouldn't want to maintain that!
据我所知，只是开裂模糊处理的软件可能会相对简单：因为你只需要找到该软件的任何位置实现不管它是什么，你要破解（一般授权保护），并添加一个跳跳过
I understand that simply 'cracking' obfuscated software might be relatively easy: because you only need to find whichever location in the software implements whatever it is you want to crack (typically the license protection), and add a jump to skip that.
如果忧的是不仅仅是由最终用户或'海盗'虽然破裂：如果担心的是源盗窃也就是说，如果你是一个软件供应商，你的担心是另一家供应商（潜在的竞争对手）反向工程源，他们可以再使用或添加到自己的产品......到什么程度是简单模糊处理的适当或不适当的防范这种风险？
If the worry is more than just cracking by an end-user or a 'pirate' though: if the worry is "source theft" i.e. if you're a software vendor, and your worry is another vendor (a potential competitor) reverse-engineering your source, which they could then use in or add to their own product ... to what extent is simple obfuscation an adequate or inadequate protection against that risk?
1日编辑：
在code的一个问题是关于20 KLOC运行在最终用户设备（用户控件，而不是一个远程服务）。
The code in question is about 20 KLOC which runs on end-user machines (a user control, not a remote service).
如果混淆真的是的几乎微不足道真正的破解的，我想一些深入的为什么这是无效的（而不仅仅是多少这不是有效）。
If obfuscation really is "almost trivial to a real cracker", I'd like some insight into why it's ineffective (and not just "how much" it's not effective).
2日编辑：
我不担心某人的扭转算法：更担心他们再利用实际的执行的算法（即源$ C $ C）纳入自己的产品
I'm not worried about someone's reversing the algorithm: more worried about their repurposing the actual implementation of the algorithm (i.e. the source code) into their own product.
盘算，20 KLOC是几月的工作，制定，将它拿比这个（数月）或多或少地反混淆这一切？
Figuring that 20 KLOC is several month's work to develop, would it take more or less than this (several months) to deobfuscate it all?
它甚至需要反混淆的东西，以'偷'了：也可能一个理智的竞争对手只是批发市场将其纳入自己的产品，同时还混淆，接受，因为，它是一个维护的噩梦，并希望它需要很少保养？如果这种情况下的是的一种可能性则是模糊的.Net code任何更容易受到这种比编译机code是？
Is it even necessary to deobfuscate something in order to 'steal' it: or might a sane competitor simply incorporate it wholesale into their product while still obfuscated, accept that as-is it's a maintenance nightmare, and hope that it needs little maintenance? If this scenario is a possibility then is obfuscated .Net code any more vulnerable to this than compiled machine code is?
是大多数混淆军备竞赛的目的主要是为preventing人的百姓，从开裂的东西（如查找和删除它实现的许可保护/执法code段），超过在preventing'源盗窃？
Is most of the obfuscation "arms race" aimed mostly at preventing people people from even 'cracking' something (e.g. finding and deleting the code fragment which implements licensing protection/enforcement), more than at preventing 'source theft'?
推荐答案
我已经讨论过，为什么我不认为模糊处理是保护对这里开裂的有效手段：
<一href="http://stackoverflow.com/questions/506282/protect-net-$c$c-from-reverse-engineering/506301#506301">Protect从逆向工程 .NET code
I've discussed why I don't think Obfuscation is an effective means of protection against cracking here:
Protect .NET Code from reverse engineering
不过，你的问题是专讲的的来源盗窃的，这是一个有趣的话题。在伊利达Eiliams书，逆转：逆向工程的秘密，作者讨论了源盗窃反向背后的原因之一在头两章工程。
However, your question is specifically about source theft, which is an interesting topic. In Eldad Eiliams book, "Reversing: Secrets of Reverse Engineering", the author discusses source theft as one reason behind reverse engineering in the first two chapters.
基本上，它归结为是，你有被针对源盗窃的唯一机会是，如果你有一些非常具体的，很难工程师，算法与你的域名，让你一条腿在你的竞争对手。这只是唯一的一次将是经济有效的尝试反向工程应用的一小部分。
Basically, what it comes down to is the only chance you have of being targeted for source theft is if you have some very specific, hard to engineer, algorithm related to your domain that gives you a leg up on your competition. This is just about the only time it would be cost-effective to attempt to reverse engineer a small portion of your application.
所以，除非你有一些你不希望你的竞争对手有绝密算法，您不必担心源盗窃。涉及扭转任何显著金额源 - code你的应用程序的成本迅速超过了从头开始重写它的成本。
So, unless you have some top-secret algorithm you don't want your competition to have, you don't need to worry about source theft. The cost involved with reversing any significant amount of source-code out of your application quickly exceeds the cost of re-writing it from scratch.
即使你确实有一些算法，你不希望他们有，没有什么可以做的反正得到它（如果应用程序正在执行他们的计算机上），以阻止决定和技能的个人。
Even if you do have some algorithm you don't want them to have, there isn't much you can do to stop determined and skilled individuals from getting it anyway (if the application is executing on their machine).
一些常见的抗扭转措施是：
Some common anti-reversing measures are:
- 模糊处理 - 不保护你的源或$ P $被破解pventing这方面做太多。但是，我们还不如不让它完全容易吧？
- 在第三方包装工 - Themida 是一个更好的。包可执行文件转换为加密的Win32应用程序。 prevents反思，如果应用程序是一个.NET应用程序也是如此。
- 在自定义包装工 - 有时编写自己的包装，如果你有技巧这样做是有效的，因为很少有信息裂解现场有关如何解开你的应用程序。这可以阻止没有经验可再生能源的。该<一href="http://www.$c$cbreakers-journal.com/downloads/cbj/2006/CBM_1_2_2006_BigBoote_Own_Packer.pdf">tutorial给出了编写自己的包装一些好的信息。
- 在保持行业秘密的算法关闭用户计算机。执行它们作为一个删除服务，这样的指令从来没有本地执行。保护的唯一的傻瓜型的方法。
- Obfuscating - Doesn't do much in terms of protecting your source or preventing it from being cracked. But we might as well not make it totally easy, right?
- 3rd Party Packers - Themida is one of the better ones. Packs an executable into an encrypted win32 application. Prevents reflection if the application is a .NET app as well.
- Custom Packers - Sometimes writing your own packer if you have the skill to do so is effective because there is very little information in the cracking scene about how to unpack your application. This can stop inexperienced RE's. This tutorial gives some good information on writing your own packer.
- Keep industry secret algorithms off the users machine. Execute them as a remove service so the instructions are never executed locally. The only "fool-proof" method of protection.
不过，封隔器可以被解压缩，并混淆并没有真正阻碍那些谁希望看到你的应用程序在做什么。如果在程序运行的用户机上则是脆弱的。
However, packers can be unpacked, and obfuscation doesn't really hinder those who want to see what you application is doing. If the program is run on the users machine then it is vulnerable.
最后的code必须执行的机code，这是正常发射了调试器，设置几个断点和监控指令的相关操作过程中被执行的问题，有的时候翻翻这数据。
Eventually its code must be executed as machine code and it is normally a matter of firing up debugger, setting a few breakpoints and monitoring the instructions being executed during the relevant action and some time spent pouring over this data.
您提到，你花了几个月的时间来写〜20kLOC为您的应用程序。这将需要将近一个量级更长的时间来扭转从您的应用程序转化为可行源的等效20kLOC如果你把最低限度precautions。
You mentioned that it took you several months to write ~20kLOC for your application. It would take almost an order of magnitude longer to reverse those equivalent 20kLOC from your application into workable source if you took the bare minimum precautions.
这就是为什么它是唯一符合成本效益，从您的应用程序反向小，行业特定的算法。还有什么，这是不值得的。
This is why it is only cost-effective to reverse small, industry specific algorithms from your application. Anything else and it isn't worth it.
看看下面虚构的例子：比方说我刚刚开发的iTunes即有一吨花俏的一个全新的竞争应用程序。让我们说了几个10万LOC和2年的开发。一个关键的功能，我所能做的就是根据你把你的音乐聆听品味提供了音乐的新途径。
Take the following fictionalized example: Lets say I just developed a brand new competing application for iTunes that had a ton of bells and whistles. Let say it took several 100k LOC and 2 years to develop. One key feature I have is a new way of serving up music to you based off your music-listening taste.
这篇关于如何有效的是混淆？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
