RE: protecting perl script source

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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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