If you're still bent on trying to obfuscate the code for whatever reason, you'll just have to go about it by hand.. Change all of your variable names to, like, $a1, $a2, $a3, etc., remove white space and indentation, and perhaps encrypt static strings (via a simple XOR algorithm) so that it's difficult to read.

Finally, if you want to get real nasty about it, encode your script (via XOR or RSA if you feel it's necessary), put it in an __END__ block, and read/decode/eval on the fly.

Before you go through all of that work, though, ask yourself why you need this obfuscated. Perl code must be distributed in source form. It's not possible to keep people from figuring out how you do it. In the US at least, copyright and contract law (license) should offer you enough protection so that you don't have to worry about silliness like this.

you keep saying that any work done for a third party on a hired basis devolves the copyright to the third party. this is not the case under current U.S. law as i understand it.

for a work to be a "work for hire", it needs either to be created by an employee in the course of execution of his official capacity, or by an independent contractor.

in the case of an independent contractor, written agreement is still necessary for the transfer of copyright to take place. such work does not automatically become the property of the client.

It depends upon the nature of the work involved. If he's hired as a programmer for a company, 99% of the time, this involves him turning over any license/title/copyright to the company he's working for. If this is a customer wanting to license something he's written/writing/will write, by all means keep the copyright and just license out the work.

Most people, however, working with a 'programmer' title for a company, have no claim over the work they're producing. It belongs to the company.

And again, this is all subject to the terms of the contract and whether or not he's working for an employer, or providing a solution to a customer, etc.

What do you mean do it by hand? He's got perl :-) It shouldn't be too challenging to put together some perl that will go through and replace $counter with $a1 and then track the relationships. So when you want to send out your code you just run it through your translator.

If you want to obfuscate, have variables that consist of 1's and l's (that's a digit and a lowercase letter). Same for function's.

-- Randal L. Schwartz, Perl hacker

While it's not impossible to crack, it'll sure put a damper on "quick-code-stealing" stuff. Of course, Perl(or interpreted languages in general) are not best for provided source code restrictions since the source is included with every copy. One thing you may try is Malcolm's perl compiler- he's still working on it, though, I hope.

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

That leads me to one question:
Does anyone of You know a case where the obfuscated code runs faster than the original???
I mean would there be a practical and pragramatical reason to check for this also??
Have a nice day
All decision is left to your taste

Doubtful.. I would imagine they run just the same. If all you're doing is changing the appearance of the code, variable names, etc., the parser isn't going to have any problem with it, and the resulting bytecode will be indistinguishable. If, however, you're encoding your strings, doing some unusual looping or whatever, you're going to incur some slight penalties if a lot of work normally done at compile time is going to be done (esp. repetitively) at run-time. It all depends on how you go about doing it.

Ever read any really highly optimized code? In assmebly perhaps? Some methods like intentionally overflowing, stuff like that? Passing pointers in odd ways. Lots of stuff like that makes code almost unreadable, but can make it MUCH faster. Look at the goto statement! I have heard of old computers that move through data structures quickly by cycling to the end of drum memory, and then cycling foward one to arrive at the head again. Try a full time job maintaining old code, designed on old machines. Almost impossibly to read, but HIGHLY tuned and INCREDIBLY efficient. They used to fit everything in less than 16K on high end computers, and did some pretty crazy cramming to make it work.

Just Another Perl Backpacker

And of course, all the person on the other end needs to do is run your code past the Deparser, and take the resulting code and insert appropriate whitespace and variable names. Failing all that, they could just post it here and someone is more then likely to post an explanation.

My suggestion is to embed your code (and the Perl Interpreter) into a C program and compile it. This is the best way to prepare code for distribution. (And even that can be decompiled.)

eh? What would embedding perl in c accomplish? The perl is still stored as strings- uncompiled. That would end up as zero difference to a hacker. perhaps you meant to refer to Malcolm Beattie's perl compiler which would do a much better job of assembler obfuscation, which is really the trick for ALL commercial software.


AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

RJ's Perl Obfuscator

I have not personally tried it out, not having any need to add extra obfuscation to my already messy code, but it might do what you need. According to the appindex record it randomizes subroutine and variable names, removes whitespace, tabbing and comments from your code.

arg. I used that script on a simple script trying to impress an intern with "perl power." If I remember correctly, the script changes all of your strings as well.

To those who believe this is swimming against the popular tide I say 'Hockey Pucks'.

We often use Rot13 or XORbit7 to protect our code. We do this so that code we have guaranteed cannot be easily tampered with.

The customer still gets source code, but as separate distribution from production code.

mitd -- Made in the Dark
'My favourite colour appears to be grey.'