Is there a good obfuscater for Perl code?

Question

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 s

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

Another not serious suggestion is to use Acme::Bleach, it will make your code very clean ;-)

Answer 6

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).