Re: protecting perl script source

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
Received on Wed Jan 29 23:11:03 2003