Bookmarks

Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries

w2ksp4.exe, WwwxxXdbf, procmail "FROM_MAILER" patch, Use of assignment to $[ is deprecated at /usr/local/sbin/apxs line 86. , wwwxxx vim, mysql closing table and opening table, 800c5000, setgid operation not permitted, pciehp: acpi_pciehprm on IBM, WWWXXX.DBF

Links

XODOX
Impressum

#1: Perl obfuscator

Posted on 2010-08-20 19:32:25 by Tobias Eichner

Hello, I'm in search for a Perl obfuscator; I know there are several c=
ommercial =0Aproducts available, but all (at least the one I found) are qui=
te expensive. Maybe you know of a reliable and feature-rich tool that =
is more affordable or =0Adistributed as open source ? =0A

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#2: Re: Perl obfuscator

Posted on 2010-08-20 19:35:46 by Uri Guttman

>>>>> "TE" == Tobias Eichner <tobiaseichner77@yahoo.de> writes:

TE> I'm in search for a Perl obfuscator; I know there are several
TE> commercial products available, but all (at least the one I found)
TE> are quite expensive.

TE> Maybe you know of a reliable and feature-rich tool that is more
TE> affordable or distributed as open source ?

the cheapest and best way is to not do it. there is an FAQ on this too.
you make money from trusted customers. others will steal it regardless
of obsfucation.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#3: Re: Perl obfuscator

Posted on 2010-08-20 20:27:29 by chas.owens

On Fri, Aug 20, 2010 at 13:32, Tobias Eichner <tobiaseichner77@yahoo.de> wrote:
> Hello,
>
> I'm in search for a Perl obfuscator; I know there are several commercial
> products available, but all (at least the one I found) are quite expensive.
>
> Maybe you know of a reliable and feature-rich tool that is more affordable or
> distributed as open source ?
snip

There are no good obfuscators. A user can always get the source back
out. Depending on what you want either [Acme::Bleach][0] or
[PAR::Packer][1] is about as good as you are going to get.

[0]: http://search.cpan.org/dist/Acme-Bleach/lib/Acme/Bleach.pm
[1]: http://search.cpan.org/dist/PAR-Packer/lib/pp.pm


--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#4: Re: Perl obfuscator

Posted on 2010-08-20 20:43:50 by Shawn H Corey

On 10-08-20 01:32 PM, Tobias Eichner wrote:
> Hello,
>
> I'm in search for a Perl obfuscator; I know there are several commercial
> products available, but all (at least the one I found) are quite expensive.
>
> Maybe you know of a reliable and feature-rich tool that is more affordable or
> distributed as open source ?
>
>
>
>

Why do you need any obfuscator? If you want to protect your code from
web access, put it in a module in a directory that cannot be access from
the web and put a stub that calls the module at the site.


--
Just my 0.00000002 million dollars worth,
Shawn

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#5: Re: Perl obfuscator

Posted on 2010-08-20 21:46:37 by Tobias Eichner

> Why do you need any obfuscator? If you want to protect your code from =
=0A> web access, put it in a module in a directory that cannot be access fr=
om =0A> the web and put a stub that calls the module at the site. It's=
not as easy as this, since people receive the source code files. I kn=
ow that obfuscation is nothing that can prevent a pro from reading the =0As=
cripts, but it's my aim to prevent the average user to read the code. =
Guess that Acme::Bleach module is also required at the target system ? Have=
n't =0Aclosely looked at it, but will do so shortly. Thanks for the hint.=


--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#6: Re: Perl obfuscator

Posted on 2010-08-20 22:06:33 by Shawn H Corey

On 10-08-20 03:46 PM, Tobias Eichner wrote:
>> Why do you need any obfuscator? If you want to protect your code from
>> web access, put it in a module in a directory that cannot be access from
>> the web and put a stub that calls the module at the site.
>
> It's not as easy as this, since people receive the source code files.
>

No, they don't. The code is executed on the web server. They don't
have access to the code at all.

Put your code in a module, say /projects/foo/Foo.pm

Then put this program in the cgi-bin:

#!/usr/bin/perl

use strict;
use warnings;

use lib '/projects/foo';

use Foo.pm;

__END__

Since the web server does not offer /projects/foo as a URL, it cannot be
accessed from the web.


--
Just my 0.00000002 million dollars worth,
Shawn

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#7: Re: Perl obfuscator

Posted on 2010-08-20 22:09:40 by Bob goolsby

Morn-n' --

You might want to consider a couple of things --

1) "Obfuscation" in an interpreted language can't really be done.
You can make it harder for the User to read you code, but you can't do
anything that makes in hard (or impossible) for the User to *run* the
code. Source code distribution and all that.

2) If you obfuscate, the User is quite likely to wonder what you
are hiding -- what back-door or malware are you *really* trying to
hide? Personally, if I am handed a package that is "protected", I lob
it back at the Bosses: "If they don't have anything to hide, then why
did they go to such lengths to hide something....?" On a couple of
occasions this has lead the offending software getting dropped from
consideration. We make it a contract deal-breaking clause that we
will receive the "clear" source as well as the Documentation set,
particularly for Software under wither the GPL or the Artistic
License.

3) Consider where you as a Perl Developer would be if the Perl
run-time were 'obfuscated' (I know, oxymoron, but.); the beauty of
Open Source tools is that you *can* look under the covers and learn
*how* the Magic is done.

Build a good tool, charge reasonably and fairly, and people will not
think twice about the cost (how many copies of WinZip have I installed
(at $14.99 a pop) in my lifetime?). Besides, you make your money on
the Consulting/Customized features in the product.


B

On Fri, Aug 20, 2010 at 12:46 PM, Tobias Eichner
<tobiaseichner77@yahoo.de> wrote:
>> Why do you need any obfuscator? =A0If you want to protect your code from
>> web access, put it in a module in a directory that cannot be access from
>> the web and put a stub that calls the module at the site.
>
> It's not as easy as this, since people receive the source code files.
>
> I know that obfuscation is nothing that can prevent a pro from reading th=
e
> scripts, but it's my aim to prevent the average user to read the code.
>
> Guess that Acme::Bleach module is also required at the target system ? Ha=
ven't
> closely looked at it, but will do so shortly. Thanks for the hint.
>
>
>
> --
> To unsubscribe, e-mail: beginners-unsubscribe@perl.org
> For additional commands, e-mail: beginners-help@perl.org
> http://learn.perl.org/
>
>
>



--=20

Bob Goolsby
bob.goolsby@gmail.com

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#8: Re: Perl obfuscator

Posted on 2010-08-20 23:05:12 by chas.owens

On Fri, Aug 20, 2010 at 16:09, Bob goolsby <bob.goolsby@gmail.com> wrote:
> Morn-n' --
>
> You might want to consider a couple of things --
>
>   1) "Obfuscation" in an interpreted language can't really be done.
> You can make it harder for the User to read you code, but you can't do
> anything that makes in hard (or impossible) for the User to *run* the
> code.  Source code distribution and all that.

It doesn't matter if it is interpreted or not. Even complied code can
be decompiled. Otherwise I pretty much agree with your statements.

--=20
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#9: Re: Perl obfuscator

Posted on 2010-08-22 04:18:47 by Peter Scott

On Fri, 20 Aug 2010 14:27:29 -0400, Chas. Owens wrote:
> There are no good obfuscators. A user can always get the source back
> out.

But the names (variables, subroutines) can be rendered meaningless.
Since picking good names is one of the most important contributions a
good programmer can make, trying to understand and change a large body of
code that has the worst names possible may not be impossible, but still
is excruciating.

--
Peter Scott
http://www.perlmedic.com/ http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=0137001274
http://www.oreillyschool.com/courses/perl1/

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#10: Re: Perl obfuscator

Posted on 2010-08-22 09:40:33 by chas.owens

On Sat, Aug 21, 2010 at 22:18, Peter Scott <Peter@psdt.com> wrote:
> On Fri, 20 Aug 2010 14:27:29 -0400, Chas. Owens wrote:
>> There are no good obfuscators.  A user can always get the source ba=
ck
>> out.
>
> But the names (variables, subroutines) can be rendered meaningless.
> Since picking good names is one of the most important contributions a
> good programmer can make, trying to understand and change a large body of
> code that has the worst names possible may not be impossible, but still
> is excruciating.
snip

If you do that in Perl 5, you run the risk of breaking the code.
Anything that used a symbolic reference would break. And other
constructs could break. For instance, this is legal (if bad) code:

#!/usr/bin/perl

use strict;
use warnings;

our $FILE =3D "/etc/passwd";
open FILE;
print <FILE>;

It even runs with strict turned on, but change the name of $FILE and you ge=
t:

Use of uninitialized value $FILE in open at bad.pl line 7.
readline() on closed filehandle FILE at bad.pl line 8.

Anything that works with the symbol table will have problems as well:

#!/usr/bin/perl

use strict;
use warnings;

our $foo =3D 10;

print "${$main::{foo}}\n";

Change the name of $foo and you get:

Can't use an undefined value as a SCALAR reference at bad.pl line 8.

And there are probably other corner cases I haven't thought of yet.
This is why all Perl 5 obfuscators, that I know of, work by encoding
the text somehow, not by modifying what perl sees. And if perl sees
it, I can see it.

The hardest thing to get at would be a C program that embeds both perl
and the Perl 5 code (in an encoded or encrypted form, otherwise the
strings program would reveal it), but even that is subject to
decompilation.

I am sympathetic to the desire to hide the code. I worked in an
environment where operations thought nothing of changing any code they
could see, and since they had root there was no way to hide the code
with permissions. After the third production failure due to
tinkering, I turned to PAR::Packer. You can easily get the code back
out, but it requires effort and it has the added benefit that you can
use any module you want with no separate install (PAR::Packer bundles
them all into one file with a Perl 5 interpreter).

Of course, that has its own problems. I can't upgrade one module and
have all programs benefit from the upgrade. The size of each program
is huge: a 67 byte "hello world" program ballons into 5.7 megabytes.
The runtime goes from .003 seconds to .28 seconds (but that is all
startup costs).



--=20
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#11: Re: Perl obfuscator

Posted on 2010-08-22 18:52:49 by Jenda Krynicky

From: Shawn H Corey <shawnhcorey@gmail.com>
> On 10-08-20 03:46 PM, Tobias Eichner wrote:
> >> Why do you need any obfuscator? If you want to protect your code from
> >> web access, put it in a module in a directory that cannot be access from
> >> the web and put a stub that calls the module at the site.
> >
> > It's not as easy as this, since people receive the source code files.
> >
>
> No, they don't. The code is executed on the web server. They don't
> have access to the code at all.

Not everything is web Shawn. The fact that if you run your code on
your server (and set things right) the visitors of your website do
not see the code is nice ... but irrelevant.

If you are writing some code for a client and then give the code to
the client to run on HIS computers then the client can see the code.
And there's nothing you can do about it.

Jenda
===== Jenda@Krynicky.cz === http://Jenda.Krynicky.cz =====
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery


--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#12: Re: Perl obfuscator

Posted on 2010-08-22 19:05:27 by Shawn H Corey

On 10-08-22 12:52 PM, Jenda Krynicky wrote:
> If you are writing some code for a client and then give the code to
> the client to run on HIS computers then the client can see the code.
> And there's nothing you can do about it.

Of course there is: SOAP


--
Just my 0.00000002 million dollars worth,
Shawn

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message

#13: Re: Perl obfuscator

Posted on 2010-08-23 15:07:18 by Peter Scott

On Sun, 22 Aug 2010 03:40:33 -0400, Chas. Owens wrote:
>> But the names (variables, subroutines) can be rendered meaningless.
>> Since picking good names is one of the most important contributions a
>> good programmer can make, trying to understand and change a large body
>> of code that has the worst names possible may not be impossible, but
>> still is excruciating.
> snip
>
> If you do that in Perl 5, you run the risk of breaking the code.
> Anything that used a symbolic reference would break. [snip] This
> is why all Perl 5 obfuscators, that I know of, work by encoding the text
> somehow, not by modifying what perl sees.

http://www.stunnix.com/prod/po/overview.shtml :

Now, I haven't used it. But it does claim to be an exception to your
rule. The users manual has a section on what to do about symbolic name
construction.

--
Peter Scott
http://www.perlmedic.com/ http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=0137001274
http://www.oreillyschool.com/courses/perl1/

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Report this message