Re: Subject: Re: hiding perl code
> You are correct. If you... > > use Hidden::Module > > then use Data::Dumper to reconstruct most of the raw code. This would be > about as useful as decompiling 'B' code. If you had access to the > intrepreter directly, you could probably even capture the decrypt stream > before perl compiles it, but all of that would take a degree of > sophistication that is better used to make real money instead of > hacking stuff apart. > > How about BZS::VeryObscure :-) Be it BZS::VeryObscure or BZS::VeryVeryObscure, all I was asking for is to tell the thruth in the docs probably somewhere at the top. I agree that for certain purposes this module may satisfy those who use it, but not all of them. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Subject: Re: hiding perl code
>> BZS::License performs a similar load operation to BZS::Loader. First, >> however it looks for a hash pointer in the caller program called >> $ptr2_License. >> The hash contains the path to the License file and an optional >>'private' key >> list of modules which will decrypt only with the 'private' key. B, > I thought that somebody has already said here that you cannot hide your > perl code. if you have an access to the perl interpreter you can dump > the source code after it was decrypted. > > wouldn't it be a good idea to add the truth to the POD so not to mislead > the crowd? I've read through the doc but didn't see a word mentioning > this "little" caveat. > > Shouldn't the module be renamed to BZS::Obscure::...? ;) You are correct. If you... use Hidden::Module then use Data::Dumper to reconstruct most of the raw code. This would be about as useful as decompiling 'B' code. If you had access to the intrepreter directly, you could probably even capture the decrypt stream before perl compiles it, but all of that would take a degree of sophistication that is better used to make real money instead of hacking stuff apart. How about BZS::VeryObscure :-) Michael
Re: hiding perl code
Michael Robinton wrote: > see attached [...] > BZS::License performs a similar load operation to BZS::Loader. First, > however it looks for a hash pointer in the caller program called $ptr2_License. > The hash contains the path to the License file and an optional 'private' key > list of modules which will decrypt only with the 'private' key. B, a I thought that somebody has already said here that you cannot hide your perl code. if you have an access to the perl interpreter you can dump the source code after it was decrypted. wouldn't it be a good idea to add the truth to the POD so not to mislead the crowd? I've read through the doc but didn't see a word mentioning this "little" caveat. Shouldn't the module be renamed to BZS::Obscure::...? ;) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
hiding perl code
see attached
=head1 NAME
BZS::License - Perl extension to examine a license file.
=head1 USEAGE
There are two modes of operation:
use BZS::License;1;
__END__
encrypted module here...
The calling routine should define an anonymous hash pointed to by the
variable $ptr2_License. i.e.
use vars qw( $ptr2_License );
$ptr2_License = {
'private' => 'name1, name2,...', # use private key
# module name
'path' => 'path to License file',
};
require licensed_module_name;
Or, for nested modules, a reference pointer to point back to the originating
module containing the License information.
use vars qw( $ptr2_License );
$ptr2_License = { 'next' => 'any value will do', };
require licensed_module_name;
Seconds remaining until License expiration are returned in
$ptr2_License{expires} unless there is no expiration
Warnings if any will be in $ptr2_License->{warn}
It is important the 'require' instead of 'use' loads the module
so that $ptr2_License is visible to the loader and not forgotton
in the case of mod-perl so don't enclose a in BEGIN{} block.
Version checking is not supported via 'use' like statement. It
can be done by examining the module contents.
More automated setup can be accomplished with the BZS::License::Util tools.
use BZS::License::Util;
See BZS::License::Util documentation for complete description
The second module mode is for development use and just loads the module so its
objects can be accessed;
use BZS::License;
$time = BZS::License::date2time(date string);
@file_text = BZS::License::get_file(file_path);
$first_tag_number = BZS::License::extract(\@file_text,\%parms);
BZS::License::get_vals(\%parms);
=head1 DESCRIPTION
See the documentation for BZS::Loader for details of License loading
operation. Only the differences are covered here.
BZS::License performs a similar load operation to BZS::Loader. First,
however it looks for a hash pointer in the caller program called $ptr2_License.
The hash contains the path to the License file and an optional 'private' key
list of modules which will decrypt only with the 'private' key. B, a
hash key of 'next' with no particular value that indicates to look to the
next caller on the stack for the License pointer. If the pointer is not
present or the License file is not found successfully, then
no further action is taken. If the License file is successfully opened, and
the contents validated then the attached encrypted module is loaded and the
seconds remaining until License expiration are returned or now() in the case
of no expiration. Undef is returned for an expired license (module fails to
load).
=over 4
=item This is what is in a certificate
License Text followed by:
ID::unique licensee identifier, date code is fine
NAME: :company or entity name
ADD1: :address line 1
ADD2: :address line 2
CITY: :city
STATE: :state or province
ZIP: :postal code
CTRY: :country
TEL: :telephone number
FAX: fax number
CONT: :contact person
MAIL: :email addy of contact
--
SERV: :http server name * optional
HOST: :hostname * optional
USER: :calling user * optional
GROUP: :calling group * optional
HOME: :called from withing this path * optional
--
DATE: :creation date, mm-dd-yy | or mmm dd yy |
EXP: :expiration * optional
KEY: :hex key
PKEY: :hex public key
--
=item $time = BZS::License::date2time(date string)
Converts a string into a numeric time value as returned by the perl function
'time' else 0;
* acceptable date formats
mm/dd/yy
mm-dd-yy
mm dd yy
month day year month = text or digits
month day, year
actually any combination of separators [/- ] will work
commas are always deleted, white space compressed, etc...
=item @file_text = BZS::License::get_file(file_path)
Takes the file path/name as its argument. Returns the stripped file contents
suitable for MAC calculation in an array. On failure, returns an empty
array.
=item MAC calculation
The MAC signature is created by taking the MD5 sum of the file less MAC the
line (if present). Leading blank lines are removed, all tabs
are converted to single spaces and trailing white space is snipped to
avoid complications caused by cut and paste operations. MAC calculation is
only done on the text portion of the file.
=item $first_tag_num = BZS::License::extract(\@file_text,\%parms)
B takes an input array consisting of the lines of text in the License
and returns the \%parms hash filled wit
Re: Hiding perl code
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. 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! My 2 eurocents, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Hiding perl code
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 > >
Re: [OT] Re: Hiding perl code
> On Mon, 22 Jul 2002 10:17:21 -0500 (CDT), Dave Rolsky <[EMAIL PROTECTED]> 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
On Mon, 22 Jul 2002, Andreas J. Koenig wrote:
> > On Mon, 22 Jul 2002 13:10:25 +1000, Iain Truskett <[EMAIL PROTECTED]> 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
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
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/perlhttp://domm.zsi.at
for(ref(bless[],just'another'perl'hacker)){s-:+-$"-g&&print$_.$/}
Re: Hiding perl code
> 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[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&) [unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Re: Hiding perl code
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 [EMAIL PROTECTED] On Mon, 22 Jul 2002, Iain Truskett wrote: > * Jonathon M. Robison ([EMAIL PROTECTED]) [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
-- [EMAIL PROTECTED] on 07/22/02 09:15:23 -0400 > Thanks, Iain! This helps explain some problems I ran into when I tried to use > Switch. ;-) Wish the Switch docs included some caveats about using it with > mod_perl Switch, Multifiles, Q::S, and A::B all have a Caveat Utilitor note in them. It's a bood bet that Damian hasn't tested any of his code with mod_perl. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Hiding perl code
Thanks, Iain! This helps explain some problems I ran into when I tried to use Switch. ;-) Wish the Switch docs included some caveats about using it with mod_perl Wes Sheldahl Iain Truskett <[EMAIL PROTECTED]> on 07/21/2002 11:10:25 PM To: [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: Hiding perl code * Jonathon M. Robison ([EMAIL PROTECTED]) [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
> On Mon, 22 Jul 2002 13:10:25 +1000, Iain Truskett <[EMAIL PROTECTED]> 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
* Jonathon M. Robison ([EMAIL PROTECTED]) [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.
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
