4

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

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

4

15 回答 15

31

我以前一直走这条路，当您必须处理“混淆”代码时，这绝对是一场噩梦，因为当您（开发人员）无法阅读代码时，尝试在客户端服务器上调试问题会大大增加成本. 您最终会遇到“反混淆器”，将“真实代码”复制到客户端的服务器或许多其他问题中的任何一个，这将成为维护的真正麻烦。

我了解您来自哪里，但听起来管理层有问题，他们希望您实施选定的解决方案，而不是找出正确的解决方案是什么。

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

于 2008-09-16T10:42:23.300 回答
15

不。只是不要。

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

于 2008-09-16T10:39:50.497 回答
8

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

有关详细信息，请参阅perlfaq3 对“如何隐藏我的 Perl 程序的源代码？”的回答。

于 2008-09-16T10:36:52.610 回答
5

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

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

于 2008-09-16T10:45:44.430 回答
4

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

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

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

于 2008-09-16T10:46:41.027 回答
4

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

于 2008-09-16T11:36:57.677 回答
4

我同意前面的建议。

但是，如果您真的想要，您可以查看PAR和/或Filter::Crypto CPAN 模块。您也可以一起使用它们。

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

于 2008-09-16T15:57:42.387 回答
3

这不是一个严肃的建议，但是看看Acme::Buffy。

它至少会照亮你的一天！

于 2008-09-16T11:32:51.137 回答
2

混淆的替代方法是使用ActiveState 的 Perl Dev Kit 之类的东西将脚本转换为二进制文件。

于 2008-09-16T11:13:57.983 回答
2

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

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

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

另外，请阅读Why-should-i-use-obfuscation以获得更一般的答案。

于 2008-09-16T12:34:57.413 回答
2

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

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

于 2008-09-16T15:17:21.657 回答
2

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

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

于 2008-09-17T04:25:48.657 回答
1

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

不要抗拒它，拥抱它。

于 2008-09-17T14:34:16.323 回答
1

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

在Mastering Perl中，我谈到了如何打败混淆器。即使您做一些诸如创建无意义的变量名称之类的事情，诸如B::Deparse和B::Deobfuscate之类的模块，以及诸如Perl::Tidy之类的 Perl 工具，也可以让知识渊博和积极进取的人轻松获得你的来源。你不必太担心那些不可知和没有动力的事情，因为他们无论如何都不知道如何处理代码。

当我与经理谈论这个时，我们会进行正常的成本效益分析。您可以做各种各样的事情，但其中的成本并不低于您获得的收益。

祝你好运，

于 2008-09-20T22:03:29.173 回答
0

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

于 2014-05-15T08:00:04.077 回答