On Sat, Aug 21, 2010 at 22:18, Peter Scott <pe...@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 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.
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 = "/etc/passwd";
open FILE;
print <FILE>;
It even runs with strict turned on, but change the name of $FILE and you get:
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 = 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).
--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
