Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Protection for Perl Scripts

by locked0wn (Acolyte)
on Jul 08, 2010 at 03:36 UTC ( #848604=perlquestion: print w/ replies, xml ) Need Help??
locked0wn has asked for the wisdom of the Perl Monks concerning the following question:

Hello All,

I came across a post in a forum this evening. It talked about using several different perl modules for protecting scripts/modules against tampering. I wouldn't do this for anything I distribute to the world, but some scripts I custom make for a server could probably benefit from tampering eyes. Here is the post I came across:


There are 3 options of encrypting perl code: 1. Use PAR with PAR::Filter::Obfuscate or PAR::Filter::Crypto 2. Use Filter::Crypto::CryptFile (will require some modules installed +on target OS) 3. Turn into module and encrypt into Module::Crypt.


Can any Monk tell me if they recommend any of these modules? I tried Module::Crypt, but it aborted before completion without any details as to why. I completely understand I can't expect complete protection with these, but looking for something to prevent quick and easy tampering.

Thank you for your suggestions.

Comment on Protection for Perl Scripts
Download Code
Re: Protection for Perl Scripts
by afoken (Parson) on Jul 08, 2010 at 04:52 UTC

    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

    --
    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!

      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.

Re: Protection for Perl Scripts
by CountZero (Bishop) on Jul 08, 2010 at 07:54 UTC
    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.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: Protection for Perl Scripts
by sundialsvc4 (Monsignor) on Jul 08, 2010 at 20:58 UTC

    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

Re: Protection for Perl Scripts
by jdrago999 (Pilgrim) on Jul 11, 2010 at 19:42 UTC

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

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://848604]
Approved by Corion
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (11)
As of 2014-08-29 06:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (276 votes), past polls