Re: protecting perl script source

[Tim Valdez <timv () uidaho edu>]

I haven't seen anyone mention the the Perl "source filter" capability. As 
the language parses it immediately goes through any "use" or "require" 
modules and writes out a temp file for later compilation (yes, even if you 
use the -e switch.) The source stream goes through the filter before 
getting to the Perl parser. You can compress your program source text, and 
use the filter to decode it (in memory) at runtime. The only "human 
understandable" thing in your program would be:

#!/usr/bin/perl
use DeCrypt.pm
GF23SW;*!#@^JKG@#JKG^%$J$^&I$
@GJ!$%^$!GKH   [and so on...]

You can also use them as a 'C'-like preparses, perhaps for using 
conditional compilation variables (similar to #IFDEF items).  You can even 
write a source filter in 'C' if you like, although I haven't tried this--I 
don't have the required knowledge of the internal source-code hooks in Perl 
you need.

Please note: this is "security through obscurity" again, and as we ALL (had 
better) know, this simply isn't good enough for anything but deterring the 
casual observer. Yes, it is only decoded in memory, but causing a coredump 
gives you the goodies, and anyone at the console could just grab memory and 
write it to disk, etc...  but, it might be just the ticket, and is 
certainly easy to use! This seems to be one of those little "secrets" that 
the Perl gurus keep to themselves...heh heh...information wants to be free!

Grab the "decrypt.pm" module from CPAN and read the pod for more info...

Tim

At 11:58 AM 1/24/2003 -0700, you wrote:
> Hi. Let's assume someone wrote a perl script that figured out how to make a
> lot of money on the stock market, but that they wanted to protect the script
> because if others began using it, it would dimish its returns. The new
> millionaire would want to protect her creation, but it has to run on a
> computer with access to the internet. She puts it on a box which she tries
> to keep patched, it's behind a firewall, and only root has access to the
> scripts. The scripts need to run unattended, and the system needs to boot
> unattended. She fears two things: a remote root vulnerability, and that
> someone would physically walk off with the box.
>
> My impression is that under these conditions, besides vigilance, limiting
> running processes, working on physical security, keeping up on patches,
> possibly some sort of IDS -- there really isn't anything she can do to
> protect the source. If it's booting unattended, and running scripts
> unattended there's no sort of crypto strategy that could protect either
> against an intruder with root access or physical access to the hard drive.
>
> What do you think?
> John