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.

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

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

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!

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.

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.