代码混淆的情况？

从对开发代码的人和运行该代码的企业的真正好处（如果所讨论的代码实际上是商业代码）的角度而言，编写混淆的代码的首要原因是什么？是否有记录在案的案例（可在某些地方在线获得）描述混淆的好处多于坏？是否有众所周知的例子，例如，证明混淆处理会有意义地延迟恶意的第三者获取代码？看来，就像卷起车窗并不会阻止人们打破它们并窃取您的立体声音响一样，混淆代码只会使诚实的人保持诚实。

=========

背景：

这是有意挑战我关于该主题的假设的一种尝试。

我通常反对使用代码混淆，但是我很好奇我是否缺少某些东西。我明白了为什么在JavaScript之类的情况下，缩小可以帮助事情更快地加载并且全部（在那里有真正的，功能上的好处），但是我似乎无法提出代码混淆的单一原因，从而成为障碍。发现一段代码/算法的作用实际上对于任何目的都是有效的。

随着开源软件的疯狂流行，问题似乎是“共享代码，还是专有？” 在商业代码方面，我能理解为什么您不能共享所有内容，并且您有法律来打击盗窃。

顺便说一句，如果有人编写混淆代码的原因是“工作安全性”，那么我将解雇任何被发现是一致的程序员，并故意使用混淆的唯一目的是帮助保持他们的工作，除非他们可以合理地证明它有一些保留。商业利益。它是如此的反团队，以至于很荒谬，它指向的是一个更关心通过误导的做法来保持工作，然后再因为编写出色的软件而保持工作的人。

我仅提及此特定案例，因为尽管我意识到人们通常在开玩笑，但我想阻止任何以其基本目的是仅对工作安全进行迷惑是一个好主意的答案。

混淆的一个非常有趣的用例是追踪非法副本的来源。假设混淆是相对便宜的操作，原始作者可以向每个客户端提供应用程序的不同混淆版本，如果发现非法副本，则作者可以与提供的版本进行比较并追溯盗版的来源。

这是隐写术的一种形式，它是“叛徒追踪”密码方案的启发和变体。我不知道它是否是常见的¹，即使它是一个好主意，但我已经看到它在以下参数下的实际应用：

• 全国竞争激烈的市场，只有两家供应商，
• 大约有50个部署覆盖了市场，
• 两种应用程序的平均开发时间为几年（或多或少），
• 我们应用程序的平均混淆时间是几个小时，
• 两种应用的寿命预计约为十年。

理由当然是一开始就通过默默无闻来实现安全性，并且它在上述方案中的某个时刻²有所发展。两家供应商都可以合法地访问彼此的二进制代码，而且我认为很明显，预计会从两者进行反编译。从长远来看，混淆对安全性无能为力。两家供应商都拥有高度进取心和才华横溢的团队，在一个利润丰厚的利基市场中工作，最终我们的产品比以往更加相似，并且通过其他不太模糊的手段获得了竞争优势。

我真的不能扩展，因为（a）这是我职业生涯的早期，并且我对设计决策或跟踪方案的结果（如果有）没有清晰的概述，并且（b）我的一些参与该项目是在保密协议之下。

混淆的另一个有效用例可能是在法律上有义务将您的代码提交给第三方时：

如果您的公司为技术公司从事知识产权工作，或者涉及涉及软件源代码的案件，则您可能有义务将客户的源代码提交给USPTO，法院或第三方。

由于源代码被认为是商业秘密，因此大多数监管机构都使用“ 50％”规则。提交的源代码被遮盖，因此不能按原样使用。

IANAL，并且该链接与代码的硬拷贝而不是实际的工作代码更相关，因此这可能是完全不相关的。

现在，由于Javascript是混淆的典范示例，因此通常不考虑一个副作用，并且它在混淆的Javascript中隐藏了恶意代码。尽管精简^3种 JavaScript 有明显的优势，但我看不到混淆的任何意义，我很高兴道格拉斯·克罗克福德（Douglas Crockford）同意我的观点：

最后，还有一个代码隐私问题。这是一个失败的原因。没有任何转换可以使坚定的黑客无法理解您的程序。事实证明，这适用于所有语言的所有程序，而JavaScript显然更是如此，因为它以源代码形式提供。混淆提供的隐私利益是一种幻想。如果您不希望别人看到您的程序，请拔下服务器的电源。

至于对“工作安全性”的迷惑，这是一种永远不应该通过代码审查的行为，并且如果识别出这种行为，则不应容忍。首先，我不会解雇罪魁祸首，但至少要重复犯案的人肯定值得打屁股。

总而言之，混淆是通过掩盖安全性的典型示例，唯一明显的优点是具有威慑力，仅此而已。我可能不知道会有创造性的用例⁴，但总的来说，好处最多是最小的。

_{¹写完这篇文章后，我发现了这个答案，它基本上描述了相同的方案，所以我认为可能更常见。
²尽管隐秘术仍然是默默无闻的安全措施。
³缩小〜删除空格并缩短标记，而不要故意遮盖。
⁴ 国际混淆式C代码竞赛是否计数？}

代码混淆的情况是，它提高了第三方确定代码工作方式/方式的标准。

然而，这并不意味着开发人员都不应当编写混淆代码。

瞧，这是我认为您的问题所缺少的一点：代码混淆（就像JavaScript压缩一样）不需要-也不应该-由开发人员手动完成。同样，也不应将其作为核心源文件存储在版本控制中。

代码混淆应在编译为生产版本时作为后处理步骤进行。也有很多第三方产品可以执行此操作，因此几乎没有理由在内部执行此操作。

例如：Dotfuscator

IEEE有一篇关于代码混淆有效性的论文

结果表明，标识符重命名显着降低了攻击的效率，至少使完成一次成功攻击所需的时间加倍（即使在最坏的情况下，即针对最佳攻击者）。另外，混淆处理缩小了新手和熟练的攻击者之间的距离，使后者的效率降低，并使易于攻击的系统与本质上更难以破坏的系统更加相似。

强调我的。

我参与了MMORPG的开发。这涉及服务器逻辑和客户端逻辑。在整个项目的长达数年的开发过程中，只要我们考虑客户端与服务器之间的接口，就应遵循以下规则：在假定客户端已被黑客入侵的情况下，服务器应始终对客户端进行处理。换句话说，必须以这样一种方式编写服务器，即不会有来自客户端的响应，该响应可能导致服务器故障或使客户端作弊。尽管如此，从一开始就知道黑客将不可避免地在系统中发现漏洞并加以利用以作弊。过了一会儿，他们做到了。

当然，在将客户运送到广阔的世界之前，我们一定要对它进行混淆。我们认为混淆会产生以下影响：

1. 它甚至阻止了非专家黑客的尝试。
2. 它延迟了专家级黑客的入侵。
3. 它减少了由专家黑客实现的黑客数量。
4. 它限制了黑客的有效性。
5. 最重要的是：这导致黑客在实现正常的黑客攻击之前，对被黑客攻击的客户端针对我们的服务器执行了更多的测试运行，这增加了我们通过在服务器日志中查找不规则活动来发现它们的机会。

被发现的黑客的游戏帐户被终止且无退款，因此这使黑客业务成本更高且吸引力更低。

因此，由于上述所有原因，我相信混淆对我们的游戏产生了整体的积极影响，并且从广义上讲，混淆对任何容易被黑客入侵的软件都可以产生整体的积极影响。（例如，包含复制保护措施的软件。）

混淆对维护的影响几乎没有。在一些地方，一些经验不足的程序员正在对标识符的名称进行假设（他们使用了反射），但是一旦这些标识符被整理出来，一切就很好了。混淆步骤刚刚成为游戏生产版本整体构建步骤的一部分，因此我们大多数开发人员都不必担心它或与它有任何关系。我们已经有了查看游戏日志的工具，因此我们对工具进行了修改，以使用混淆器生成的关联表（将混淆后的标识符映射到适当的标识符），以便为我们实时翻译日志，因此我们从来没有甚至在根据从现场收集的日志进行验尸检查时，甚至必须看到任何混淆的标识符。

阅读和理解（显然是写作）混淆的代码可能是一个有趣的精神挑战。它可能不在您要求的范围之内，但是像IOCCC这样的例子可能既是娱乐又是恐怖的来源。