You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Jonathon M. Robison" <jr...@uniphied.com> on 2002/07/22 04:58:24 UTC
Hiding perl code
Anyone know offhand a good way to hide your perl code when using
mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on
initial test, and then on second test I find that httpd.conf suddenly
got a 'use Acme::Bleach' inserted at line 1 and the whole thing is bleached.
Perhaps perl2exe?
--Jon R
Re: Hiding perl code
Posted by Thomas Klausner <do...@zsi.at>.
Hi!
On Sun, Jul 21, 2002 at 10:58:24PM -0400, Jonathon M. Robison wrote:
> Anyone know offhand a good way to hide your perl code when using
> mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on
You could write an obfuscator. Maybe Acme::EyeDrop works?
See
http://domm.zsi.at/source_code/obfu/O.pm
for an obfuscated mod_perl handler.
A very simple thing to do is eg:
$yourcode=s/\s+/~/gs;
Than, in to be obfuscated module, do:
$_='package~Your::Code'.$yourcode;s/~/ /g;eval;
That's basically what I did in my mod_perl obfu.
This definitly isn't unbreakable, but (if you add some more
obfu-tricks and maybe do some encryption on the code to be evaled)
would require some knowledge to deparse.
I guess you started this thread on perlmonks?
http://www.perlmonks.org/index.pl?node_id=183932
If not, read it.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref(bless[],just'another'perl'hacker)){s-:+-$"-g&&print$_.$/}
Re: Apache::DProf
Posted by Chris Newman <ch...@investis.com>.
Think you need to load in Apache::Registry with :
PerlModule Apache::Registry
before the PerlHandler Apache::Registry bit
Suggest also that you do all the module loading / startup before specifying
any handlers
eg . from my mod_perl.conf
PerlRequire conf/startup.pl
PerlFreshRestart on
PerlSetVar StatusOptionsAll On
PerlSetVar StatusTerse On
PerlSetVar StatusTerseSize On
PerlSetVar StatusTerseSizeMainSummary On
Alias /perl-bin/ /usr/local/apache/mod_perl/
PerlModule Apache::DProf
PerlModule Apache::Registry
PerlModule B::TerseSize
PerlModule Apache::Status
<Location /perl-bin>
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
PerlSendHeader On
allow from all
</Location>
On Wednesday 24 Jul 2002 2:20 pm, Ruslan V. Sulakov wrote:
> I have troubles using Apache::DProf
> I try to use it as described at:
> http://perl.apache.org/docs/1.0/guide/performance.html#Code_Profiling_Techn
>i ques
>
> But when my httpd.conf has a line:
> PerlModule Apache::DProf
> apache reply with error 500 (Internal Server Error) when I request a perl
> script, that runs under mod_perl
>
> Without this line, all works fine!
>
> Errorlog shows following message during each request:
> [Sat Jul 20 07:34:28 2002] [error] Undefined subroutine
> &Apache::Registry::handler called.
>
>
> I have in my httpd.conf
> <Files *.pl>
> SetHandler perl-script
> PerlHandler Apache::Registry
> PerlSendHeader On
> Options +ExecCGI
> PerlModule Apache::DProf
> PerlRequire /path/to/my/modules/modperl_startup.pl
> </Files>
>
> Is here something wrong?
> How can I have Apache::DProf worked for profiling my code?
>
> Thanks in advance.
> Ruslan
Re: @INC
Posted by "Ruslan V. Sulakov" <ru...@zr.ru>.
Thanks, Ilya! You are right!
/usr/bin/perl contains old binary from v5.00503
So, I've change it to a link pointing to /usr/local/bin/perl
Now all works fine!
Ruslan
> Looks like your sys admin had installed perl from core and from ports
> and as result you have two perl installation on systems. Perl from
> core (5.00503) likely to have is binary in /usr/bin/perl and perl from
> ports (5.6.1) in /usr/local/bin/perl.
>
> If your PATH doesn't have /usr/local/bin or it comes after /usr/bin
> than 'perl Makefile.PL' uses perl from core. Try either changing your
> PATH or using full path to perl (i.e. /usr/local/bin/perl
> Makefile.PL).
Re: @INC
Posted by Ilya Martynov <il...@martynov.org>.
>>>>> On Mon, 29 Jul 2002 13:43:13 +0400, "Ruslan V. Sulakov" <ru...@zr.ru> said:
RVS> My @INC contains WRONG directories!!! Help!
RVS> How can I change @INC in perl for installing of Apache::SubProcess and other
RVS> modules?
RVS> At this time I cannot install any Apache::* related modules, because of bad
RVS> @INC
RVS> Platform: FreeBSD
RVS> I have Apache::* modules installed in:
RVS> /usr/local/lib/perl5/site_perl/5.6.1/mach/Apache/
RVS> But I cannot install needed modules:
RVS> oasis2# tar -zxf Apache-SubProcess-0.03.tar.gz
RVS> oasis2# cd Apache-SubProcess-0.03
RVS> oasis2# perl Makefile.PL
RVS> Can't locate Apache/src.pm in @INC (@INC contains: ../lib
RVS> /usr/libdata/perl/5.00503/mach /
RVS> usr/libdata/perl/5.00503 /usr/local/lib/perl5/site_perl/5.005/i386-freebsd
RVS> /usr/local/lib/
RVS> perl5/site_perl/5.005 .) at Makefile.PL line 4.
RVS> BEGIN failed--compilation aborted at Makefile.PL line 4.
RVS> oasis2#
Looks like your sys admin had installed perl from core and from ports
and as result you have two perl installation on systems. Perl from
core (5.00503) likely to have is binary in /usr/bin/perl and perl from
ports (5.6.1) in /usr/local/bin/perl.
If your PATH doesn't have /usr/local/bin or it comes after /usr/bin
than 'perl Makefile.PL' uses perl from core. Try either changing your
PATH or using full path to perl (i.e. /usr/local/bin/perl
Makefile.PL).
--
Ilya Martynov (http://martynov.org/)
@INC
Posted by "Ruslan V. Sulakov" <ru...@zr.ru>.
My @INC contains WRONG directories!!! Help!
How can I change @INC in perl for installing of Apache::SubProcess and other
modules?
At this time I cannot install any Apache::* related modules, because of bad
@INC
Platform: FreeBSD
I have Apache::* modules installed in:
/usr/local/lib/perl5/site_perl/5.6.1/mach/Apache/
But I cannot install needed modules:
oasis2# tar -zxf Apache-SubProcess-0.03.tar.gz
oasis2# cd Apache-SubProcess-0.03
oasis2# perl Makefile.PL
Can't locate Apache/src.pm in @INC (@INC contains: ../lib
/usr/libdata/perl/5.00503/mach /
usr/libdata/perl/5.00503 /usr/local/lib/perl5/site_perl/5.005/i386-freebsd
/usr/local/lib/
perl5/site_perl/5.005 .) at Makefile.PL line 4.
BEGIN failed--compilation aborted at Makefile.PL line 4.
oasis2#
Thanks in advance!
Ruslan
Apache::DProf
Posted by "Ruslan V. Sulakov" <ru...@zr.ru>.
I have troubles using Apache::DProf
I try to use it as described at:
http://perl.apache.org/docs/1.0/guide/performance.html#Code_Profiling_Techni
ques
But when my httpd.conf has a line:
PerlModule Apache::DProf
apache reply with error 500 (Internal Server Error) when I request a perl
script, that runs under mod_perl
Without this line, all works fine!
Errorlog shows following message during each request:
[Sat Jul 20 07:34:28 2002] [error] Undefined subroutine
&Apache::Registry::handler called.
I have in my httpd.conf
<Files *.pl>
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
PerlModule Apache::DProf
PerlRequire /path/to/my/modules/modperl_startup.pl
</Files>
Is here something wrong?
How can I have Apache::DProf worked for profiling my code?
Thanks in advance.
Ruslan
Re: [OT] Re: Hiding perl code
Posted by "Andreas J. Koenig" <an...@anima.de>.
>>>>> On Mon, 22 Jul 2002 10:17:21 -0500 (CDT), Dave Rolsky <au...@urth.org> said:
>> use Filter::decrypt ;
>> ÿ £j¨tBÃavð@¥£hK6' {'ÂÃ^zÂ'
>> [....]
>>
>>
>> Of course, perl itself (or mod_perl) sees the cleartext, so a good
>> hacker will find a way to break it.
> perl -MO=Deparse /path/to/"encrypted"/file(s)
Funny, that would be a nice test. Unfortunately I have only encrypted
files for an old perl and have never tried with a perl that is
Deparse-enabled. If anybody else is willing to test how well Dave's
suggestion works, please post your experience.
--
andreas
[OT] Re: Hiding perl code
Posted by Dave Rolsky <au...@urth.org>.
On Mon, 22 Jul 2002, Andreas J. Koenig wrote:
> >>>>> On Mon, 22 Jul 2002 13:10:25 +1000, Iain Truskett <ic...@eh.org> said:
>
> > As far as I know, there's no good way to do it. It is Perl after all.
> > And with mod_perl things just get trickier.
>
> Filter::decrypt does that. It's very hard to break as you compile a
> self-made key statically into your perl. Filter::decrypt also disables
> the debugger within that perl. Can also be done for mod_perl. The
> encrypted modules look like this:
>
> use Filter::decrypt ;
> ÿ £j¨tBÃavð@¥£hK6' {'ÂÃ^zÂ'
> [....]
>
>
> Of course, perl itself (or mod_perl) sees the cleartext, so a good
> hacker will find a way to break it.
perl -MO=Deparse /path/to/"encrypted"/file(s)
-dave
/*==================
www.urth.org
we await the New Sun
==================*/
Re: Hiding perl code
Posted by "Andreas J. Koenig" <an...@anima.de>.
>>>>> On Mon, 22 Jul 2002 13:10:25 +1000, Iain Truskett <ic...@eh.org> said:
> As far as I know, there's no good way to do it. It is Perl after all.
> And with mod_perl things just get trickier.
Filter::decrypt does that. It's very hard to break as you compile a
self-made key statically into your perl. Filter::decrypt also disables
the debugger within that perl. Can also be done for mod_perl. The
encrypted modules look like this:
use Filter::decrypt ;
ÿ £j¨tBÓavð@¥£hK6' {'Þ^z'
[....]
Of course, perl itself (or mod_perl) sees the cleartext, so a good
hacker will find a way to break it.
--
andreas
Re: Hiding perl code
Posted by John Saylor <jo...@worldwinner.com>.
Hi
( 02.07.22 10:15 -0400 ) Jon:
> At my former employer's, we built an Enterprise Management System out of
> mod_perl. He wants to distribute it to clients w/o risking theft of his
> code.
Well, I'll save the intellectual property rant, but it's going to be
very difficult to do. Perl is set up for sharing, not hiding.
You might be able to use a crypto dependency to accomplish some of the
same ends. You'd need a key pair to make this work.
Take a low level variable and expect it's value to be held in an
encrypted file. Encrypt the file with your private key and have the code
decrypt it to operate. The public key can be contained in the code.
So this file becomes a software 'dongle' of some type. It's not perfect,
and certainly breakable [just rewrite the code with the crypto
dependency], but may be applicable to your case.
--
\js
A thing is not necessarily true because a man dies for it.
Re: Hiding perl code
Posted by Jean-Michel Hiver <jh...@mkdoc.com>.
On Mon 22-Jul-2002 at 10:15:44AM -0400, Jon wrote:
> At my former employer's, we built an Enterprise Management System out of
> mod_perl. He wants to distribute it to clients w/o risking theft of his
> code.
We had the same thoughts here, but we arrived at the conclusion that
there is one very efficient copy protection: it's called the copyright
laws.
After all, if your product is an "Enterprise Management System", I bet
your target has no interest whatsoever to compromise itself with illegal
licenses of your software...
IMHO the only market in which piracy _can_ have a negative impact is the
entertainment market.
<offTopic level="high">
On top of all that, I find it *VERY* outrageous that it is legal for
software to come without the source code... Copyright laws would be a
lot easier to enforce if you could just see the unscrambled and
commented source of every program, and it'd be good for
interoperability too!
</offTopic>
My 2 eurocents,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
================================================================
Jean-Michel Hiver - Software Director
jhiver@mkdoc.com
+44 (0)114 255 8097
================================================================
VISIT HTTP://WWW.MKDOC.COM
Re: Hiding perl code
Posted by Andy Lester <an...@petdance.com>.
> At my former employer's, we built an Enterprise Management System out of
> mod_perl. He wants to distribute it to clients w/o risking theft of his
> code.
If "w/o risking theft" means "eliminating risk of theft", then he can't
do it. He can lower risk to some degree, but it can't be eliminated.
See
http://www.perldoc.com/perl5.6/pod/perlfaq3.html#How-can-I-hide-the-source-for-my-Perl-program-
xoxo,
Andy
--
'Andy Lester andy@petdance.com
Programmer/author petdance.com
Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&)
[unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Re: Hiding perl code
Posted by Jon <jo...@mhost.com>.
At my former employer's, we built an Enterprise Management System out of
mod_perl. He wants to distribute it to clients w/o risking theft of his
code.
--Jon R.
PGP Key fingerprint = 12 DA FC 06 AB 4C D6 A4 DE 03 E0 77 D6 DE E0 73
PGP public key available by fingering jon@mhost.com
On Mon, 22 Jul 2002, Iain Truskett wrote:
> * Jonathon M. Robison (jrobison@uniphied.com) [22 Jul 2002 13:03]:
> > Anyone know offhand a good way to hide your perl code when using
> > mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on
> > initial test [...]
>
> Acme::Bleach is a source filter. Source filters will just screw up your
> mod_perl stuff. IIRC, you get similar problems using Switch and so on.
>
> > Perhaps perl2exe?
>
> Nope. That does weird compiler stuff that will interfere with the fact
> that Apache's using Perl internally.
>
>
> As far as I know, there's no good way to do it. It is Perl after all.
> And with mod_perl things just get trickier.
>
> Out of interest, why?
>
>
> cheers,
> --
> Iain.
>
Re: Hiding perl code
Posted by Iain Truskett <ic...@eh.org>.
* Jonathon M. Robison (jrobison@uniphied.com) [22 Jul 2002 13:03]:
> Anyone know offhand a good way to hide your perl code when using
> mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on
> initial test [...]
Acme::Bleach is a source filter. Source filters will just screw up your
mod_perl stuff. IIRC, you get similar problems using Switch and so on.
> Perhaps perl2exe?
Nope. That does weird compiler stuff that will interfere with the fact
that Apache's using Perl internally.
As far as I know, there's no good way to do it. It is Perl after all.
And with mod_perl things just get trickier.
Out of interest, why?
cheers,
--
Iain.
Re: Hiding perl code
Posted by Nathan Byrd <na...@byrd.net>.
Jon,
I've been doing some thinking along these lines (for website security,
not for releasing code). I don't have a solution, but below are some
thoughts I've had. I would love to hear from anyone who knows solutions
for any of the points below. Most of the thoughts below are based on
encryption, as I don't believe that obfuscating or compiling offer any
real security for an attacker who is determined.
For Apache::Registry (or Apache::PerlRun) scripts, it should be fairly
trivial to write an Apache::RegistryEncrypt, based on
Apache::RegistryNG, that would first decrypt a source file during
compile using a public key stored in a (presumably) safe location before
turning it into a module. The secret key could be stored on a different
(development) server and not be accessible, which would give you fairly
good security, both for reading and writing. Unfortunately, this would
not protect modules (particularly application modules) which are use'd
from these scripts.
For modules, it might be possible to write a module which would first
decrypt a file before using it (would something using the same type of
method as ex::lib::zip* work?). Modules could then be preloaded using
PerlModule from the Apache configuration or use lines from a startup.pl
file. However, I imagine it might be difficult to decide which modules
*have* to be encrypted - if all modules have to be encrypted, that would
affect even standard modules, but if it is selectable, there would have
to be a way of keeping an attacker from simply placing a module earlier
in the @INC path. Maybe something like "everything with the FOOBAR::
prefix has to be encrypted"? The other benefit of this is that the same
solution would also work for encrypting true mod_perl handlers, not just
scripts.
I believe this would be preferable to using a source filter, as a source
filter would only protect reading, not writing. Since a source filter
operates on everything after the use Filter::Whatever; line, an attacker
could simply place code above that line, or replace the file completely
and negate any benefit from using it. Besides that, it might be
difficult to access a public key from a source filter in a secure
manner.
For website security, the other solution I considered was to use
Apache::RegistryBB or something homebrew which wouldn't check the
modification time of a script after the initial compile and use, then
simply unmount the filesystem after Apache startup. Of course, like the
above solution, this only protects the on-disk copy, the code would
still be accessible in memory if debugging was available, etc. Other
than that, this just seems like a "clunky" solution, and not very good
if the filesystem has to be manually mounted to restart the webserver,
but the admin isn't available :-)
Thanks,
Nathan Byrd
* http://search.cpan.org/search?mode=module&query=ex%3A%3Alib%3A%3Azip
On Sun, 2002-07-21 at 21:58, Jonathon M. Robison wrote:
> Anyone know offhand a good way to hide your perl code when using
> mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on
> initial test, and then on second test I find that httpd.conf suddenly
> got a 'use Acme::Bleach' inserted at line 1 and the whole thing is bleached.
>
> Perhaps perl2exe?
>
> --Jon R
>
>