RE: protecting perl script source

["Eyal Udassin" <eyal () webcohort com>]

Hi

As mentioned a here quite a few times, source filters are far from being
a worthy solution to this problem.
In case you're using a windows box, I strongly suggest moving your
sensitive code to a dll, and call it from perl using Win32::API.

There's no place like C :-)

Eyal Udassin
WebCohort Inc.

-----Original Message-----
From: Peter Sergeant [mailto:pete () clueball com] 
Sent: Thursday, January 30, 2003 10:26 AM
To: webappsec () securityfocus com
Subject: Re: protecting perl script source


> I haven't seen anyone mention the the Perl "source filter" capability.

This is because it provides next to no security. Unless you're willing
to jump through a huge amount of hoops, it's laughably easy to get the
code of any 'Filtered' code - remember, at the end of the day, perl
needs to be able to read the source.

It's as simple as: perl -MO=Deparse test.pl

> 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!

Information may want to be free, bad advice that leads to false feelings
of security wants to be terminated. 

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

Including the part where it says:

"Also, with the introduction of the Perl Compiler backend modules, and
the B::Deparse module in particular, using a Source Filter to hide
source code is becoming an increasingly futile exercise."

+Pete