有没有好的 Perl 代码混淆器？
有谁知道 Perl 有一个好的代码混淆器吗？ 我被要求在将代码发布给客户之前研究混淆代码的选项。 我知道混淆的代码仍然可以被逆向工程，但这不是我们主要关心的问题。
一些客户正在对我们提供给他们的源代码进行一些小的更改，当出现问题而我们必须修复它时，或者当我们发布的补丁与他们所做的更改不兼容时，这会给我们带来噩梦。 所以目的只是为了让他们很难对代码进行自己的更改（无论如何他们都不应该这样做）。
Does anyone know of a good code obsfucator for Perl? I'm being ask to look into the option of obsfucating code before releasing it to a client. I know obsfucated code can still be reverse engineered, but that's not our main concern.
Some clients are making small changes to the source code that we give them and it's giving us nightmares when something goes wrong and we have to fix it, or when we release a patch that doesn't work with what they've changed. So the intention is just to make it so that it's difficult for them to make their own changes to the code(they're not supposed to be doing that anyway).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
另一个不太严重的建议是使用 Acme::Bleach，它会让你的代码非常干净;-)
Another not serious suggestion is to use Acme::Bleach, it will make your code very clean ;-)
正如奥维德所说，这是一个契约性的社会问题。 如果他们更改代码，保修就会失效。 向他们收取大量费用来解决这个问题，但同时，给他们一个可以提出更改建议的渠道。 另外，看看他们想要更改什么，如果可以的话，将其作为配置的一部分。 他们有自己想做的事情，在你满足之前，他们会一直试图绕过你。
在 掌握 Perl 中，我谈论了一些关于击败混淆器的内容。 即使您做了一些无意义的变量名称之类的事情，诸如 B::Deparse< 之类的模块/a> 和 B::Deobfuscate，以及 Perl 工具，例如 Perl::Tidy，让知识渊博、积极进取的人很容易获得您的源代码。 你不必太担心那些无知和无动力的人，因为他们无论如何也不知道如何处理代码。
当我与经理谈论这个问题时，我们会进行正常的成本效益分析。 您可以做各种各样的事情，但其中大部分的成本都低于您获得的收益。
祝你好运，
As Ovid says, it's a contractual, social problem. If they change the code, they invalidate the warranty. Charge them a lot to fix that, but at the same time, give them a channel where they can suggest changes. Also, look at what they want to change and make that part of the configuration if you can. They have something they want to do, and until you satisfy that, they are going to keep trying to get around you.
In Mastering Perl, I talk a bit about defeating obfucators. Even if you do things like making nonsense variables names and the like, modules such as B::Deparse and B::Deobfuscate, along with Perl tools such as Perl::Tidy, make it pretty easy for the knowledgable and motivated person to get your source. You don't have to worry about the unknowledgable and unmotivated so much because they don't know what to do with the code anyway.
When I talk to managers about this, we go through the normal cost benefit analysis. There is all sorts of stuff you could do, but not much of it costs less than the benefit you get.
Good luck,
我只是邀请他们进入他们自己分支上的 SVN 树，这样他们就可以提供更改，我可以看到它们并将他们的更改集成到我的开发树中。
不要对抗它，拥抱它。
I would just invite them into my SVN tree on their own branch so they can provide changes and I can see them and integrate their changes into my development tree.
Don't fight it, embrace it.
正如一些人已经说过的：不要。
考虑到 Perl 解释器的性质，这几乎是隐含的，在 Perl 得到它之前，你为混淆 Perl 所做的任何事情都必须是可撤销的，这意味着你需要将反混淆脚本/二进制文件留在解释器周围（因此您的客户）可以找到它:)
解决真正的问题：校验和/或措辞适当的许可证。 支持人员接受过培训，会说‘你改变了它？ 我们正在调用许可证的第 34b 条，在我们触及它之前，这将是 $X,000'....
另外，请阅读 why-should-i-use-obfuscation 以获得更一般的答案。
As several folks have already said: don't.
It's pretty much implicit, given the nature of the Perl interpreter, that anything you do to obfuscate the Perl must be undoable before Perl gets its hands on it, which means you need to leave the de-obfuscation script/binary lying around where the interpreter (and thus your customer) can find it :)
Fix the real problem: checksums and/or a suitably worded license. And support staff trained to say 'you changed it? we're invoking clause 34b of our license, and that'll be $X,000 before we touch it'....
Also, read why-should-i-use-obfuscation for a more general answer.
混淆的另一种方法是使用 ActiveState 的 Perl Dev Kit。
An alternative to obfuscation is converting your script to a binary using something like ActiveState's Perl Dev Kit.
我正在运行 Windows 操作系统并使用 IndigoSTAR 的 perl2exe。 生成的 .EXE 文件不太可能在现场进行更改。
正如其他人所说，“我如何混淆它”是错误的问题。 “我如何阻止客户更改代码”是正确的。
I am running a Windows O/S and use perl2exe from IndigoSTAR. The resulting .EXE file will be unlikely to be changed on-site.
As others have said, "how do I obfuscate it" is the wrong question. "How do I stop the customer from changing the code" is the right one.
校验和和合同的想法有助于防止您描述的“问题”，但如果您的成本是推出升级和错误修复的困难，那么您的客户如何进行不通过的更改综合测试套件？ 如果他们有能力进行这些更改（或者至少进行更改以表达他们希望代码执行的操作），为什么不简单地让他们轻松/自动化地打开支持票证并上传补丁呢？ 对于客户想要什么，客户总是正确的（他们可能不知道如何“以正确的方式”做到这一点，但这就是他们付钱给你的原因。）
需要混淆器的更好理由适用于大众市场的桌面部署，在这种情况下，您不会让每个客户都签订长期合同。 在这种情况下，像 PAR 这样的东西——任何将加密/混淆逻辑打包到编译的二进制文件中的东西都是可行的方法。
The checksum and contract ideas are good for preventing the "problems" you describe, but if the cost to you is the difficulty of rolling-out upgrades and bug-fixes, how are your clients making changes that don't pass the comprehensive test suite? If they are capable of making these changes (or at least, making a change which expresses what they want the code to do), why not simply make it easy/automated for them to open a support ticket and upload the patch? The customer is always right about what the customer wants (they might not have a clue how to do it "the right way", but that's why they are paying you.)
A better reason to want an obfuscator would be for mass-market desktop deployment where you don't have every customer on a standing contract. In that case, something like PAR -- anything which packs the encryption/obfuscation logic into a compiled binary is the way to go.
这不是一个严肃的建议，但是请查看 Acme::Buffy。
它至少会照亮你的一天！
This isn't a serious suggestion, however take a look at Acme::Buffy.
It will at least brighten your day!
我同意前面的建议。
但是，如果您确实愿意，可以查看 PAR 和/或 Filter::Crypto CPAN 模块。 您也可以一起使用它们。
当我们在光学介质上运输我们的产品时，我使用后者（Filter::Crypto）作为一种真正轻量级的“保护”形式。 它不会“保护”您，但会阻止 90% 想要修改您的源文件的人。
I agree with the previous suggestions.
However if you really want to, you can look into PAR and/or Filter::Crypto CPAN modules. You can also use them together.
I used the latter (Filter::Crypto) as a really lightweight form of "protection" when we were shipping our product on optical media. It doesn't "protect" you, but it will stop 90% of the people that want to modify your source files.
将程序转换为二进制文件的另一种选择是免费的 PAR-Packer 工具CPAN。 甚至还有用于代码混淆的过滤器，尽管正如其他人所说，这可能比它的价值更麻烦。
Another alternative for converting your program into a binary is the free PAR-Packer tool on CPAN. There are even filters for code obfuscation, though as others have said, that's possibly more trouble than it's worth.
在这种情况下，混淆是错误的方法。
当您向客户端发布代码时，您应该保留发送给他们的代码的副本（在磁盘上或最好在版本控制中作为标签/分支）。
然后，如果您的客户进行更改，您可以将他们拥有的代码与您发送给他们的代码进行比较，并轻松发现更改。 毕竟，如果他们觉得需要进行更改，则某个地方存在问题，您应该在主代码库中修复它。
In this case obfuscating is the wrong approach.
When you release the code to the client you should keep a copy of the code you send them (either on disk or preferably in your version control as a tag/branch).
Then if your client makes changes you can compare the code they have to the code you sent them and easily spot the changes. After all if they feel the need to make changes there is a problem somewhere and you should fix it in the master codebase.
您的主要问题似乎是客户修改代码，这使您很难支持它。 我建议您在他们向您寻求支持时询问其文件的校验和（md5、sha 等），并在修补时类似地检查文件的校验和。 例如，您可以要求客户端提供所提供程序的输出，该程序将完成安装并对所有文件进行校验。
最终他们拥有了代码，所以他们可以做任何他们想做的事情。 您能做的最好的事情就是强制执行您的许可证并确保您只支持未经修改的代码。
It would seem your main issue is clients modifying code which then makes it difficult for you to support it. I would suggest you ask for checksums (md5,sha, etc) of their files when they come to you for support, and similarly check files' checksums when patching. For example, you can ask the client to provide the output of a provided program which goes through their install and checksums all the files.
Ultimately they have the code, so they can do whatever they want to it. The best you can do is enforce your licenses and to make sure you only support unmodified code.
请不要这样做。 如果您不希望人们更改您的 Perl 代码，请将其置于适当的许可证之下并强制执行该许可证。 如果人们在您的许可表明他们不应该这样做时更改了您的代码，那么当您的更新不再适用于他们的安装时，这不是您的问题。
请参阅 perlfaq3回答“如何隐藏 Perl 程序的源代码？”以获取更多详细信息。
Please don't do that. If you don't want people to alter your Perl code then put it under an appropriate licence and enforce that licence. If people change your code when you licence says that they shouldn't do that, then it's not your problem when your updates not longer work with their installation.
See perlfaq3's answer to "How Can I hide the source for my Perl programs? for more details.
不。 只是不要。
将其写入合同（或在必要时修改合同），您不对他们对软件所做的更改负责。 如果他们搞砸了你的代码，然后期望你修复它，那么你的客户端问题就无法通过混淆代码来解决。。 如果你混淆了它并且他们遇到了实际问题，祝他们在错误报告中准确报告行号等。
Don't. Just don't.
Write it into the contract (or revise the contract if you have to), that you are not responsible for changes they make to the software. If they're f-ing up your code and then expecting you to fix it, you have client problems that aren't going to be solved by obfuscating the code. And if you obfuscate it and they encounter an actual problem, good luck in getting them to accurately report line number, etc., in the bug report.
我以前也曾走过这条路，当你必须处理“混淆”的代码时，这绝对是一场噩梦，因为当你作为开发人员无法读取代码时，它会极大地增加尝试在客户端服务器上调试问题的成本。 您最终会遇到“反混淆器”，将“真实代码”复制到客户端的服务器或任何其他问题，这些问题只会成为维护的真正麻烦。
我理解您的想法，但听起来管理层有问题，他们希望您实施选定的解决方案，而不是弄清楚正确的解决方案是什么。
在这种情况下，听起来这确实是一个许可或合同问题。 让他们将代码开源，但将其作为许可证的一部分，他们提交的任何更改都必须返回给您并获得批准。 当您推出补丁时，请检查所有代码的 md5 和，如果与预期不符，则说明它们违反了许可证，并将收取相应费用（而且费用应该高得多）。 （我记得有一家公司让我们开源代码，但明确表示，如果我们更改任何内容，我们就以 25,000 美元“购买”了代码，并且他们不再负责任何错误修复或升级，除非我们购买了新许可证）。
I've been down this road before and it's an absolute nightmare when you have to work on "obfuscated" code because it drives up costs tremendously trying to debug a problem on the client's server when you, the developer, can't read the code. You wind up with "deobfuscators", copying the "real code" to the client's server or any of a number of other issues which just become a real hassle to maintain.
I understand where you're coming from, but it sounds like management has a problem and they're looking to you to implement a chosen solution rather than figuring out what the correct solution is.
In this case, it sounds like it's really a licensing or contractual issue. Let 'em have the code open source, but make it a part of the license that any changes they submit have to come back to you and be approved. When you push out patches, check the md5 sums of all code and if it doesn't match what's expected, they're in license violation and will be charged accordingly (and it should be a far, far higher rate). (I remember one company which let us have the code open source, but made it clear that if we changed anything, we've "bought" the code for $25,000 and they were no longer responsible for any bug fixes or upgrades unless we bought a new license).