有没有人知道一个很好的Perl代码遮挡器?我被要求在将代码发布给客户之前,先研究一下是否可以使代码变得模糊。我知道模糊的代码仍然可以进行逆向工程,但这不是我们主要关心的问题。
一些客户对我们提供给他们的源代码做了一些小改动,当出现问题而我们必须修复它时,或者当我们发布一个不适用于他们所做更改的补丁时,这会给我们带来噩梦。因此,这样做的目的只是为了让他们很难对代码进行自己的更改(他们无论如何都不应该这样做)。
发布于 2008-09-16 10:42:23
我以前也经历过这种情况,当你不得不处理“混淆”的代码时,这绝对是一场噩梦,因为当你作为开发人员无法阅读代码时,在客户端服务器上调试问题会大大增加成本。你最终得到了“deobfuscator”,将“真正的代码”复制到客户端的服务器,或者其他许多问题中的任何一个,这些问题只会成为维护的真正麻烦。
我理解你的想法,但听起来管理层遇到了问题,他们希望你实现一个选定的解决方案,而不是找出正确的解决方案。
在这种情况下,这听起来像是一个许可或合同问题。让他们将代码开源,但使其成为许可证的一部分,即他们提交的任何更改都必须返回给您并获得批准。当你推出补丁时,检查所有代码的md5和,如果它与预期的不匹配,它们就违反了许可,并将相应地收取费用(费率应该高得多)。(我记得有一家公司允许我们将代码开源,但明确表示,如果我们做了任何更改,我们已经花了25,000美元“购买”了代码,除非我们购买了新的许可证,否则他们不再负责任何错误修复或升级)。
发布于 2008-09-16 10:39:50
不要,就是不要。
将其写入合同(或在必要时修改合同),表明您不对他们对软件所做的更改负责。如果他们搞乱了你的代码,然后期望你修复它,那么你的客户端问题不会通过混淆代码来解决。如果你混淆了它,他们遇到了一个实际的问题,那么祝你好运,让他们在bug报告中准确地报告行号等。
发布于 2008-09-16 10:36:53
请不要那样做。如果您不希望人们修改您的Perl代码,那么将其置于适当的许可之下,并强制执行该许可。如果人们更改了你的代码,而你的许可证说他们不应该这样做,那么当你的更新不再与他们的安装一起工作时,这不是你的问题。
有关更多详细信息,请参阅perlfaq3's answer to "How Can I hide the source for my Perl programs?。
https://stackoverflow.com/questions/71057
复制相似问题