有没有一个好的 Perl 代码混淆器？

Question

有谁知道 Perl 有一个好的代码混淆器吗？我被要求在将代码发布给客户之前研究混淆代码的选项。我知道混淆的代码仍然可以进行逆向工程，但这不是我们主要关心的问题。

一些客户正在对我们提供给他们的源代码进行一些小的更改，当出现问题而我们必须修复它时，或者当我们发布的补丁与他们所做的更改不兼容时，这会给我们带来噩梦。所以目的只是为了让他们很难对代码进行自己的更改（无论如何他们都不应该这样做）。

Answer 1

我以前也曾走过这条路，当你必须处理“混淆”的代码时，这绝对是一场噩梦，因为当你作为开发人员无法读取代码时，它会极大地增加尝试在客户端服务器上调试问题的成本。您最终会遇到“反混淆器”，将“真实代码”复制到客户端的服务器或任何其他问题，这些问题只会成为维护的真正麻烦。

我理解您的想法，但听起来管理层有问题，他们希望您实施选定的解决方案，而不是弄清楚正确的解决方案是什么。

在这种情况下，听起来这确实是一个许可或合同问题。让他们将代码开源，但将其作为许可证的一部分，他们提交的任何更改都必须返回给您并获得批准。当您推出补丁时，请检查所有代码的 md5 和，如果与预期不符，则说明它们违反了许可证，并将收取相应费用（而且费用应该高得多）。（我记得有一家公司让我们开源代码，但明确表示，如果我们更改任何内容，我们就以 25,000 美元“购买”代码，并且他们不再负责任何错误修复或升级，除非我们购买了新许可证）。

Answer 2

不。只是不要。

将其写入合同（或在必要时修改合同），您不对他们对软件所做的更改负责。如果他们搞砸了你的代码然后期望你修复它， 您遇到的客户端问题无法通过混淆代码来解决. 。如果你混淆了它并且他们遇到了实际问题，祝他们在错误报告中准确报告行号等。

Answer 3

请不要这样做。如果您不希望人们更改您的 Perl 代码，请将其置于适当的许可证之下并强制执行该许可证。如果人们在您的许可表明他们不应该这样做时更改了您的代码，那么当您的更新不再适用于他们的安装时，这不是您的问题。

看 perlfaq3 对“如何隐藏 Perl 程序的源代码？”的回答 更多细节。

Answer 4

您的主要问题似乎是客户修改代码，这使您很难支持它。我建议您在他们向您寻求支持时询问其文件的校验和（md5、sha 等），并在修补时类似地检查文件的校验和。例如，您可以要求客户端提供所提供程序的输出，该程序将完成安装并对所有文件进行校验。

最终他们拥有了代码，所以他们可以做任何他们想做的事情。您能做的最好的事情就是强制执行您的许可证并确保您只支持未经修改的代码。

Answer 5

在这种情况下，混淆是错误的方法。

当您向客户端发布代码时，您应该保留发送给他们的代码的副本（在磁盘上或最好在版本控制中作为标签/分支）。

然后，如果您的客户进行更改，您可以将他们拥有的代码与您发送给他们的代码进行比较，并轻松发现更改。毕竟，如果他们觉得需要进行更改，则某个地方存在问题，您应该在主代码库中修复它。

Answer 6

将程序转换为二进制文件的另一种选择是免费的 PAR-打包机 工具打开 CPAN. 。甚至还有用于代码混淆的过滤器，尽管正如其他人所说，这可能比它的价值更麻烦。

Answer 7

我同意前面的建议。

不过如果你真的想的话，你可以看看 光合有效辐射 和/或 过滤器::加密货币 CPAN 模块。您也可以一起使用它们。

当我们在光学介质上运输我们的产品时，我使用后者（Filter::Crypto）作为一种真正轻量级的“保护”形式。它不会“保护”您，但会阻止 90% 想要修改您的源文件的人。

Answer 8

这不是一个严肃的建议，但是请看一下 Acme::巴菲.

它至少会照亮你的一天！

Answer 9

混淆的另一种方法是使用类似的方法将脚本转换为二进制文件 ActiveState 的 Perl 开发工具包.

Answer 10

我正在运行 Windows 操作系统并使用 IndigoSTAR 的 perl2exe。生成的 .EXE 文件不太可能在现场进行更改。

正如其他人所说，“我如何混淆它”是错误的问题。“我如何阻止客户更改代码”是正确的。

Answer 11

校验和和合同的想法有助于防止您所描述的“问题”，但如果您的成本是推出升级和错误修复的困难，那么您的客户如何做出不通过的更改 综合测试套件？如果他们有能力进行这些更改（或者至少进行更改来表达他们希望代码执行的操作），为什么不简单地让他们轻松/自动化地打开支持票证并上传补丁呢？顾客永远是对的 关于客户想要什么 （他们可能不知道如何“以正确的方式”做到这一点，但这就是他们付钱给你的原因。）

想要使用混淆器的一个更好的理由是为了大众市场的桌面部署，在这种情况下，您不需要让每个客户都签订长期合同。在这种情况下，有一些东西 喜欢 PAR——任何将加密/混淆逻辑打包到编译的二进制文件中的方法都是可行的。

Answer 12

正如一些人已经说过的：不。

考虑到 Perl 解释器的性质，这几乎是隐含的，在 Perl 得到它之前，你为混淆 Perl 所做的任何事情都必须是可撤销的，这意味着你需要将反混淆脚本/二进制文件留在解释器周围（因此您的客户）可以找到它:)

解决真正的问题：校验和和/或措辞适当的许可证。支持人员接受过培训，会说‘你改变了它？我们正在援引我们许可证的第 34b 条，在我们触及它之前，这将是 $X,000'....

另外，请阅读 为什么我应该使用混淆 以获得更一般的答案。

Answer 13

我只是邀请他们进入他们自己分支上的 SVN 树，这样他们就可以提供更改，我可以看到它们并将他们的更改集成到我的开发树中。

不要对抗它，拥抱它。

Answer 14

正如奥维德所说，这是一个契约性的社会问题。如果他们更改代码，保修就会失效。向他们收取大量费用来解决这个问题，但同时，给他们一个可以提出更改建议的渠道。另外，看看他们想要更改什么，如果可以的话，将其作为配置的一部分。他们有自己想做的事情，在你满足之前，他们会一直试图绕过你。

在 掌握 Perl, ，我谈了一些关于击败混淆者的事情。即使您做了一些无意义的变量名称之类的事情，诸如 B::离开 和 B::反混淆, ，以及 Perl 工具，例如 Perl::整洁, ，让知识渊博、积极进取的人很容易获得您的资源。你不必太担心那些无知和无动力的人，因为他们无论如何也不知道如何处理代码。

当我与经理谈论这个问题时，我们会进行正常的成本效益分析。各种各样的东西都有你 可以 这样做，但其中大部分成本都低于您获得的收益。

祝你好运，

Answer 15

另一个不严肃的建议是使用 Acme::漂白剂, ，它会让你的代码非常干净;-)