[prog] 'protecting' perl code

[Jacinta Richardson]

> I guess the problem at hand is a little unusual:  I've been asked
> whether it would be possible to 'protect' existing perl scripts from
> prying eyes - such that you can give them away to people who are not
> supposed to see what the code does...  Comparable to having some
> compiled binary executable, that you can't easily reverse engineer.
> Interesting question, I thought :-)  but as you can imagine, I wasn't
> yet able to give my client any substantial info on the subject...

Not particularly unusual at all unfortunately.  :(  A regularly denounced
objective by the Perl community.  The simple answer there isn't a
particularly good way to achieve this.  Perl sits in the middle of
compiled and interpreted programs.  perl compiles the program immediately
before executing it.  It's a bit fuzzier than that because you can
dynamically construct Perl code during program execution and then run that
too.

The longer answer is as follows:

Whilst there are lots of ways to obscure the source, the Perl
compiler/interpreter needs to undo those things in order to compile and
then execute the script.  Any determined person can single step the
program to the point where you call the Perl interpreter's eval method
with with the re-translated source code.

Hiding the source code does not increase its security.

Having said that, if the target machine for the code is Windows then you
might have some advantage in trying:

Activestate PerlApp : 
http://www.activestate.com/Products/ASPN_Perl/more_information.plex

or 

the Perl Archive Toolkit:
http://search.cpan.org/~autrijus/PAR-0.80/lib/PAR.pm

or

perl2exe 
http://www.indigostar.com/perl2exe.htm
	

These do not "compile" your scripts.  They encrypt it (or obscure it in
some way) and then bundle it into an exe file.  As the Perl interpreter
is also placed in the exe (so that you can distribute a single exe to
machines without Perl) the exe can be sizable.

If your target machine is a *nix, then it's harder.  (ActiveState's tool
may actually work here too)

> I googled a bit, but all I found were a few commercial solutions (source
> code obfuscators like Perlguardian, Perl-obfus, etc.), and rather
> heated discussions about why you should never ever do such a thing at
> all, as it would be a breach of the open source philosophy, ethically.

In my opinion it would be a breach of code maintainability, patchability,
and system resource usage policies.  But that might just be me.  :)  I'd
normally say that if you were determined to do this you should get a
commercial package to do it for you.  And for Windows I highly recommend
ActiveState's tools.  However, having seen some of the other commercial
solutions... well some of them break things badly.

> Well, I'm afraid this is a little over my head anyway - at least I'd
> probably have to learn a couple of things along the way...
> Still, does anyone have any ideas how one could go about it?  I'd hate
> to give up before having had a go at it.  I've come across mentions of
> the perl compiler (B::*, or so) in that context. Would that be the way
> to go?

The B:: modules will be more useful in undoing the
compilation/encryption/obfuscation than achieving it if you ask me.

> Is this doable at all within a reasonable project time span, or should
> I rather tell my client to use some commercial solution right away?

If there's a commercial solution (like ActiveState) that does what you
need then I'd recommend to the client they use that.  Even after all of my
experience in Perl I would hate to have to write such a tool.  There are
too many edge cases.  I recommend that you explain to your client the
issues involved in attempting this problem.  Perl wasn't written in such a
way as to make this easy and so it isn't easy.

A great quote from the author of a perl2exe analysis:

	I started to wonder why people use these Perl compilers, and
	then it hit me. They're obviously not used for security, since
	they provide no security. They're obviously not used for licence
	enforcement, since Bad Guys aren't going to stop to think about
	licences anyway, and Good Guys won't rip you off.

	They're actually used out of shame; most of the code I've seen
	packaged up with these things is of amazingly poor quality, and
	I can understand why you wouldn't want people to look at that
	kind of code if you're making a commercial product out of it.
	People don't want to expose the fact that they're selling really
	quite bad programs for really too much money. If these
	programmers had a bit more pride in their Perl abilities and a
	little bit more honesty with their customers, the need for these
	sort of "compilers" would go away, and the problem would be
	solved.

To hide your source code does not stop pirating any way. Most of the
time, they don't care your source code at all, what they want to steal
is the functionality your code delivers. What they want is money without
effort, to study your source code is too long a way to go.

I guess your client has to work out why they want to do this.  Illegally
copying and distributing obscured Perl is just as easy as non-obscured
Perl.

I'm sorry I haven't really answered the question at hand.

	Jacinta

--
   ("`-''-/").___..--''"`-._          |  Jacinta Richardson         |
    `6_ 6  )   `-.  (     ).`-.__.`)  |  Perl Training Australia    |
    (_Y_.)'  ._   )  `._ `. ``-..-'   |      +61 3 9354 6001        |  
  _..`--'_..-_/  /--'_.' ,'           | contact at perltraining.com.au |
(il),-''  (li),'  ((!.-'              |   www.perltraining.com.au   |