有谁知道 Perl 有一个好的代码混淆器吗？我被要求在将代码发布给客户之前研究混淆代码的选项。我知道混淆代码仍然可以被逆向工程，但这不是我们主要关心的问题。
一些客户正在对我们提供给他们的源代码进行微小的更改，当出现问题而我们必须修复它时，或者当我们发布的补丁与他们所做的更改不兼容时，这会让我们做噩梦.所以目的只是为了让他们很难对代码进行自己的更改（无论如何他们都不应该这样做）。
【问题讨论】：
标签： perl obfuscation
请不要那样做。如果您不希望人们更改您的 Perl 代码，请将其置于适当的许可下并执行该许可。如果人们在您的许可要求他们不应该这样做时更改您的代码，那么当您的更新不再适用于他们的安装时，这不是您的问题。
更多详情请见perlfaq3's answer to "How Can I hide the source for my Perl programs?。
【讨论】：
不要。只是不要。
将其写入合同（或在必要时修改合同），您不对他们对软件所做的更改负责。如果他们正在修改您的代码，然后期望您修复它，您的客户问题无法通过混淆代码来解决。如果你混淆了它并且他们遇到了实际问题，那么祝他们在错误报告中准确地报告行号等。
【讨论】：
我以前曾走这条路，当您必须处理“混淆”代码时，这绝对是一场噩梦，因为当您（开发人员）无法在客户端服务器上调试问题时，它会极大地增加成本阅读代码。您最终会遇到“反混淆器”，将“真实代码”复制到客户端的服务器或任何其他问题，这些问题只会成为真正的维护麻烦。
我了解您来自哪里，但听起来管理层有问题，他们希望您实施选定的解决方案，而不是找出正确的解决方案是什么。
在这种情况下，听起来确实是许可或合同问题。让他们将代码开源，但将其作为许可证的一部分，他们提交的任何更改都必须返回给您并获得批准。当您推出补丁时，检查所有代码的 md5 总和，如果它与预期不符，则它们违反了许可证并将相应地收费（而且应该是高得多的费率）。 （我记得有一家公司让我们将代码开源，但明确表示，如果我们更改任何内容，我们已经以 25,000 美元的价格“购买”了该代码，并且他们不再负责任何错误修复或升级，除非我们购买了新许可证）。
【讨论】：
您的主要问题似乎是客户修改代码，这使您难以支持它。我建议您在他们向您寻求支持时询问他们文件的校验和（md5、sha 等），并在修补时同样检查文件的校验和。例如，您可以要求客户端提供所提供程序的输出，该程序会通过其安装并对所有文件进行校验和。
他们最终拥有了代码，因此他们可以为所欲为。您能做的最好的事情就是强制执行您的许可证并确保您只支持未修改的代码。
【讨论】：
在这种情况下，混淆是错误的方法。
当您将代码发布给客户端时，您应该保留一份您发送给他们的代码的副本（在磁盘上，或者最好在您的版本控制中作为标签/分支）。
然后，如果您的客户进行了更改，您可以将他们拥有的代码与您发送给他们的代码进行比较，并轻松发现更改。毕竟，如果他们觉得有必要进行更改，那就是某个地方出了问题，您应该在主代码库中修复它。
【讨论】：
混淆的替代方法是使用ActiveState's Perl Dev Kit 之类的东西将您的脚本转换为二进制文件。
【讨论】：
这不是一个严肃的建议，但是看看Acme::Buffy。
它至少会让你的一天变得更加美好！
【讨论】：
将程序转换为二进制文件的另一种方法是CPAN 上的免费PAR-Packer 工具。甚至还有用于代码混淆的过滤器，尽管正如其他人所说，这可能比它的价值更麻烦。
【讨论】：
正如一些人已经说过的：不要。
考虑到 Perl 解释器的性质，这几乎是隐含的，你为混淆 Perl 所做的任何事情都必须在 Perl 得到它之前是可撤消的，这意味着你需要留下去混淆脚本/二进制文件口译员（以及您的客户）可以在哪里找到它:)
解决真正的问题：校验和和/或适当措辞的许可证。支持人员受过训练，会说“你改变了它？我们正在调用我们许可证的第 34b 条，在我们触及它之前，这将是 $X,000 美元......
另外，请阅读why-should-i-use-obfuscation 以获得更一般的答案。
【讨论】：
我正在运行 Windows 操作系统并使用 IndigoSTAR 的 perl2exe。生成的 .EXE 文件不太可能在现场进行更改。
正如其他人所说，“我如何混淆它”是一个错误的问题。 “我如何阻止客户更改代码”是正确的。
【讨论】：
我同意前面的建议。
但是，如果您真的愿意，可以查看 PAR 和/或 Filter::Crypto CPAN 模块。也可以一起使用。
当我们在光学介质上运送我们的产品时，我使用了后者（Filter::Crypto）作为一种非常轻量级的“保护”形式。它不会“保护”您，但会阻止 90% 的人想要修改您的源文件。
【讨论】：
校验和和合同想法有助于防止您描述的“问题”，但如果您的成本是推出升级和错误修复的难度，那么您的客户如何进行未通过的更改综合测试套件？如果他们有能力做出这些改变（或者至少做出表达他们想要代码做什么的改变），为什么不简单地让他们轻松/自动化地打开支持票并上传补丁呢？客户对于客户想要的东西总是正确的（他们可能不知道如何“以正确的方式”做到这一点，但这就是他们付钱给你的原因。）
需要混淆器的更好理由是用于大众市场桌面部署，在这种情况下，您不会让每个客户都签订长期合同。在这种情况下，类似 PAR——任何将加密/混淆逻辑打包到编译二进制文件中的东西都是可行的。
【讨论】：
我会邀请他们加入我自己分支上的 SVN 树，这样他们就可以提供更改，我可以看到他们并将他们的更改集成到我的开发树中。
不要抗拒它，拥抱它。
【讨论】：
正如 Ovid 所说，这是一个合同性的社会问题。如果他们更改代码，就会使保修失效。向他们收取很多费用来解决这个问题，但同时，给他们一个可以提出更改建议的渠道。另外，看看他们想要改变什么，如果可以的话，把它作为配置的一部分。他们有他们想做的事情，在你满足之前，他们会一直试图绕过你。
在Mastering Perl 中，我谈到了一些关于击败混淆器的内容。即使你做了一些无意义的变量名称之类的事情，B::Deparse 和 B::Deobfuscate 等模块，以及Perl::Tidy 等 Perl 工具，也可以让知识渊博和积极进取的人轻松获得你的源代码。你不必太担心那些不可知和没有动力的事情，因为他们无论如何都不知道如何处理代码。
当我与经理讨论这个问题时，我们会进行正常的成本效益分析。您可以做各种各样的事情，但其中的成本并不低于您获得的收益。
祝你好运，
【讨论】：
另一个不严肃的建议是使用Acme::Bleach，它会让你的代码非常干净;-)
【讨论】：