There is NO technical way to protect a perl script. PAR and friends can be unpacked (see Uncool Use Of Perl: perl2exe. decompile quick steps), obfuscation can be removed (perl -MO=Deparse obfu.pl), and even the most advanced encryption algorithm is useless because you have to provide both the decryption algorithm and the decryption key to run the script. Break before the parser starts reading the decrypted code, print the code, done.

This is not a Perl problem, you will have the same problem with any interpreted language, and, to a lesser extend, even with compiled languages. There are some very good decompilers around for C, C++, Java, and all other major languages.

If you need to protect your code, consult a lawyer.

If you want to avoid accidental changes to your code, set the read-only attribute (DOS/Win, attrib +r your.pl) or remove the writeable attribute (Unix, chmod -w your.pl).

As a side node, the skype executable is an example of a very aggressive protection attempt, it uses obfuscation, encryption, runtime checks, anti-debugger tricks, and some other techniques in parallel and in multiple layers. It even encrypts unused code in memory. It is really hard to find out what really happens inside the code, but with enough work, even that is breakable.

Alexander

There is no technical way to build an impenetrable fence. Yet people build fences around their houses and gardens. Some of them fairly low. So low that an adult would have no problems crossing the fence. But the fences are still not without their use. They show where the limits are and they prevent the intrusion of little kids ... locked0wn said he doesn't need an impenetrable fence, just a kid preventing one!

Jenda
Enoch was right!
Enjoy the last years of Rome.

locked0wn said he doesn't need an impenetrable fence, just a kid preventing one!

PAR is that fence, OP needs something on-top of that

There is NO technical way to protect a perl script. PAR and friends can be unpacked (see Uncool Use Of Perl: perl2exe. decompile quick steps), obfuscation can be removed (perl -MO=Deparse obfu.pl), and even the most advanced encryption algorithm is useless because you have to provide both the decryption algorithm and the decryption key to run the script. Break before the parser starts reading the decrypted code, print the code, done.

Really?

One way which comes to mind is to split the script into two parts, one of which runs on a trusted system where you get to define "trusted". The source on the untrusted portion may as well be regarded as open to view. The trusted portion of the source should be well hidden and perform a service sufficiently complicated that an attacker finds it cheaper to play by your rules than to write or pay for a re-implementation.

Paul

Really?

One way which comes to mind is to split the script into two parts, one of which runs on a trusted system where you get to define "trusted". The source on the untrusted portion may as well be regarded as open to view. The trusted portion of the source should be well hidden and perform a service sufficiently complicated that an attacker finds it cheaper to play by your rules than to write or pay for a re-implementation.

Yes, really. Splitting it into 2 parts isn't sufficiently complicated. Making it sufficiently complicated entails some kind of quantum computing that hasn't been invented yet.

some scripts I custom make for a server could probably benefit from tampering eyes

Read that again, slowly ... and think about it for a moment.

Protect from whose tampering eyes? root or the sysadmin's eyes? That is no use: they are god and can probably read, decompile, delete and change anything they want.

The client of the server? He/she/it will never see your module if you have configured the server to run rather than show your module's code.

Someone you have sold/licensed your module to? Then your protection is in the contract and not in encrypting the code.

As others have said, you cannot prevent a Perl script from being disclosed to the sysadmins ... nor to anyone else who has read-access to the directory in which the script has been stored.

You can, however, use ordinary directory-access rules on the server to ensure that no web user ever has the ability to “purloin” any source-code from the machine.

Incidentally... you do need to pay close attention to the directory permissions that you establish on your stuff if you've deployed to a shared hosting environment!   You’d be rather amazed (and shocked) by what is available to even a casually-curious fellow subscriber to whatever web-hosting service you happen to be using . . .   :-O

Simply use Acme::Bleach; and be done with it.

Read more about Acme::Bleach. Basically it turns all your code into "non-printable characters" (like spaces and tabs) to help prevent tampering.

After running your code with a use Acme::Bleach; statement in there, it will look like this:

use Acme::Bleach;
# Nothing else below.
[download]

Meh.

Filters w/ stronger encryption have already be discussed above. This just provides a visually interesting result.