代码混淆有两个好处：

1. 它清除了攻击者池的浅端。难以理解您的代码的脚本小子将去其他地方。
2. 它增加了熟练的攻击者所需的工作量。不管他们多么熟练，混淆比去混淆更便宜，而且结果通常比原始的更难理解（变量名称将保持通用，例如，原始是描述性的）。

@SteveSether 在他的评论中是双重正确的 -几乎不可能找到 实际测量结果，并且许多代码库由于专有原因*而不是安全原因而被混淆。

但是出于安全和专有的原因，代码混淆的价值与其不对称的质量有关——混淆比去混淆更便宜。

*“专有原因”是指“为了保持市场竞争优势，希望保持代码和算法更私密或更难复制”。公司和个人都容易出现这种倾向。

• 只要我在可能从 Internet 接收的所有内容（邮件、ftp、web、dns 等，在请求、日志、文件传输中）上看到了混淆代码（主要是在病毒和rootkits中），在去混淆中涉及的人工时间代码足以找到基本信息，例如僵尸网络的服务器地址、管理员 ID和散列密码，或敏感字符串或病毒库调用，大多以分钟计。

  因此，就防止奇怪代码而言，这不是一项大工作（如果不是微不足道的）。

• 另一方面，从这种代码构建可编辑的源代码可能会花费大量时间（如果代码很大，则以天、几周甚至更长的时间计算。无论如何，反混淆过程进展得越多，它们的效率和效率就越高。快，就像光明来临的时候一样）。

• 关于 OWASP 的建议，我同意：混淆意味着人力资源，因此它们代表一些成本，使盗版的吸引力降低。

• 关于...对不起measurablility，security benefit但我不能！取决于谁可能对破解您的代码感兴趣，您的代码的哪一部分以及为什么。

总的来说，我自己的建议是：使用混淆本质上不是一个坏主意，但它不能被视为重大的安全改进！

更清楚一点：永远不要考虑混淆代码来隐藏密钥/功能，这样它就会比没有混淆的地方更安全！

混淆的另一点是使攻击者更难否认他们的逆向工程活动。

如果您的服务器允许任何向他们发送“Hello foobar”字符串的客户端进入，并且有人利用了它，那么可能很难在法庭上证明犯罪者确实有攻击意图，而不仅仅是误解了您的许可协议并假设这是允许的。如果您的客户端使用模糊的密钥（包含在客户端本身中）向服务器进行身份验证，那么您在安全性方面获得的收益很少，但是利用您的服务器的人将很难证明他们偶然获得了该密钥，而不是通过有意的逆向工程努力。

混淆显着增加了对程序进行逆向工程的时间成本。虽然从混淆程序中提取一些小秘密可能很快，但制作该程序的非混淆版本的工作只需重写它即可。提取一种新颖的算法是可能的，但并非易事。

本质上混淆的代码可以推理，但不能重用。

代码混淆是大量 CS 研究的主题……您关于混淆本质上毫无价值的公理将是有争议的。

我建议阅读《秘密软件：软件保护的混淆、水印和防篡改》一书。作者：Christian Collberg 和 Nagra Jasvir。