RE: protecting perl script source

["Ogston, Iain M" <iain.ogston () eds com>]

Perl source filters indeed provide a powerful way to deploy
encrypted/obfuscated code and implement preprocessors.  I use them
regularily to produce debug/production versions of scripts - set a flag at
the top of the script and all the debug code disappears when the script is
run.  

This is much nicer than a bunch of messy 'print "x=1" if $DEBUG' statements
all over the code.  Instead you can have constructs like:
## DEBUG SECTION
print "x = 1";
## END DEBUG

These can be delimited from the main body of the code or even hived off into
sub procedures (such that you'd say _DEBUG(x,1) and the preprocessor would
remove these lines).

Some time ago I wrote a simple proof of concept encrypt script/decrypt
filter pair which produced DES3 encrypted output of the original script in
base64 form. The deployed script needed to include the decryption key as a
comment before the encrpypted content for the script to run.

A system such as this could be used in some sort of licensing scenario where
each customer received the source encrypted with a different key.  

I am not sure how strong DES3 encryption of script is, but I assume it might
defeat someone with limited cryptographic knowledge.  Of course if the key
is recovered (say by compromising the box) then the script could be
decrypted and saved out in plain text.  I believe that the debugger is
little help without the key as the script won't compile but I could be
wrong.

i.e. simple plaintext script section:
{
print "HELLO!!!\n";
}

Encoded script:
#!perl
use SomeFilter;
#KEY=ABCD43
2cf985e3b68db4c3e0e7e6b3165f05a74e1da3050b4b29ac

Somefilter basically ignores anything in the script until it encounters a
#KEY= and then it decodes all further script content by translating from
base64, then des3 decrypts with the given key.

Regards,

Iain Ogston
ISIS Development Team Leader
EDS UKNESSC
Royfold House
Hill of Rubislaw
Aberdeen AB15 6GZ
United Kingdom

Tel: +44 (0)1224 382511 (8-933-2511)
Fax: +44 (0)1224 312015

Mailto:iain.ogston () eds com
Find out more about EDS at http://www.eds.com

 


-----Original Message-----
From: Tim Valdez [mailto:timv () uidaho edu]
Sent: 30 January 2003 01:36
To: webappsec () securityfocus com
Subject: 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