Real world uses for obfuscation
为了什么目的，您希望混淆您的代码？除了参加比赛之外，我没有遇到任何真正的目的，但我相信一定有一些明智和有用的理由来混淆源代码。
一般来说，为什么要或需要混淆代码？
模糊有什么实际应用程序？
它会减慢(但不会阻止那些已经确定的)逆向工程代码的速度。
- 使盗窃知识产权更加困难
- 隐晦式安全
- 带宽最小化，如javascript minify
在Perl首次发布时，代码混淆就变得流行起来。它实际上是一个让代码更高效的人工制品。在过去的早期，在已建立的"C"编程社区和"叛徒"Perl倡导者之间爆发了一场类似于火焰的战争。很明显，老派的C小子在表演上胜过了Perl小子。Perler(？)作为回应，开始提出性能黑客，而不考虑可读性。因此，混淆。当然，这不再是必需的，因为Perler(？)很早以前就承认了C'ers的表现(不错吧？.obfuscation从未用于我所见过的安全目的。事实上，如果你建议它作为某种安全措施，人们会把你从房间里笑出来。一般来说，试图规避安全的黑客非常了解他们所瞄准的语言和工具集。这就是他们如此成功的原因。混淆并不是对他们的辩护。
假设你与一家公司签订了一份生产软件的合同。他们是一个痛苦的工作，基本上使你的生活地狱。合同的一部分说，项目完成后，你必须移交所有源代码…D
在这里阅读
The goal of obfuscation is to create
confusion. As confusion builds, the
ability of the human mind to
comprehend multi-faceted intellectual
concepts deteriorates. Note that this
precept says nothing about altering
the forward (executable) logic – only
representing it incomprehensibly. When
a well-written obfuscator tool goes to
work on readable program instructions,
a likely side effect is that the
output will not only confuse a human
interpreter, it will break a
decompiler.
我们向用vhdl和verilog设计电路的人销售Obufuscators。因为这样的设计通常都相当大，所以有很多东西需要混淆(通常是数万行)，而且要想对这些进行逆向工程是非常困难的。
最重要的用途是减小尺寸。我总是在JavaScript和Java应用程序上使用它(J2ME)。
一些模糊器也可以做一些小的优化。
代码模糊通常应用于解释语言，如PHP，其中源代码不编译，必须分发给最终用户。事实上，模糊是可以打破的，我只是用它来保持诚实的人诚实。你知道，找到破解的东西要比实际拿到信用卡容易得多。
如果你启动了一个逻辑清晰的应用程序，那么模糊可以在某种程度上防止竞争对手逐字刷你的逻辑。
当你是一个新网站时，击败"我也是"的人群是很重要的。
但预防措施薄弱，不值得花时间。
它可以减缓恶意黑客试图以未经授权或不受欢迎的方式盗版或修改您的软件的速度。不多，但如果你担心街头发布日期，几天或几小时可能很重要。
这是不道德的，但是拥有只有你才能理解的关键任务代码是一些程序员确保工作安全的一种方式。
代码模糊限制了商业应用。然而，它可以帮助以一种独特的方式提高开发人员的工具箱。模糊的代码作为一个极端的对比，以清洁的文件化的代码设计。
模糊化并不会打败一个坚定的黑客或保护你的绝密算法，但在大多数情况下，这不是重点。传统上，它只需要足够好，使公司支付软件支持和更新，而不是采取努力去混淆和维护软件本身。
我第一次遇到混淆是在Unix的早期，当时大多数C程序都必须以源代码的形式交付，因为不同的CPU体系结构太多，缺少聪明的链接器或通用的对象文件格式。
随着解释语言的兴起，模糊技术现在可能比以往更多地用于商业软件。
我在现实项目中使用了代码混淆。我开发了企业软件(JavaServlet)。对于servlet，编译的类必须驻留在服务器上才能运行(war/jar文件)。在大多数情况下，它们驻留在服务器上，我可以a)控制，或者b)信任操作员。
然而，一个客户坚持应用程序驻留在他们的服务器上，用于"Intranet"的使用。由于客户端有一个"不太恒星"的道德历史，所以我首先注意通过一个混淆器运行编译的Java。我还对测试结果进行了相当好的测试，以确保反编译代码几乎不可用。
你可能会问："为什么要和这样的客户打交道？"但是，这个特定应用程序的整体营销超出了我的控制范围，尽管没有任何安全问题。对于特定的情况，这是最好的折衷方案。
干杯，
-R
作为一个具体的例子，看看Gmail背后的脚本。这主要是为了阻止一些有进取心的黑客创建一个与Gmail服务器对话的替代前端。
第二个虽然很重要的好处是减少了脚本大小。