develooper Front page | perl.bootstrap | Postings from July 2000

Re: Obscuring code?

Thread Previous | Thread Next
Chaim Frenkel
July 25, 2000 18:13
Re: Obscuring code?
Message ID:
Unless you make your own lexer/parser, I can't see how you can protect
the source. 

Since perl is open a slight change to the lexer would spew out the
entire un-obscured source.

And if all you want is some shrouding write a pre-processor in perl that
would kill the indentation, kill all meaningful variables, and move the
code around.


>>>>> "p" == phil  <> writes:

p> I see a method of compiling to a binary or some other means of
p> obscuring code (encryption?) helpful in keeping users from abusing
p> licensing, and as some term it, keeping job security.  Most languages
p> don't have an issue with this, but Perl does since it is an
p> 'interpretive' language (OK, well at least from the pov of this
p> discussion).  And, I experience most of my code (as a server-side web
p> developer) residing on machines owned and managed by others. 

p> Gosh, it would be great if a password or something could get me into
p> the source code and let me modify it directly.  Of course, Perl will
p> always have to have access to the source to run.  Perhaps some sort of
p> secure dual-key system??  I'm sure some smarter people out there than
p> I can see a solution... or already know of an existing one?!  :') 

p> In the least, a one-way binary compiler or source code 'scrambler'
p> (obscurator) would handle this, but wouldn't be optimal...  perhaps a
p> two-way obscurator which was password based??

p> Thoughts? Comments?

Chaim Frenkel					     Nonlinear Knowledge, Inc.				               +1-718-236-0183

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About