Re: Protecting source code

[Boysenberry Payne <suppressed>]

What about products like CPANEL, how do they do it?
There must be some standard usage already with Perl
being as prevalent as it is.

Currently we've separated our perl code out onto its own server
and use proxies to get to and fro.

It keeps a level of protection on our code.

We just serve the output to our clients instead.

Obviously it means we have an overhead to maintain, but our code
is worth it to us.

Originally it was written in php, I had to migrate it all.  Was easy  
with perl.

Security seems to be such a big issue in so many areas besides
the code even, that one just settles for the best one can do.

Keeping control of the code seems to be the most secure approach
in my mind.  Once you give it to someone else, given enough time
they will "figure it out".

Same is true with security everywhere, banks, homes, dvds, etc...


Thanks,
Boysenberry

boysenberrys.com | habitatlife.com | selfgnosis.com

On Aug 25, 2006, at 2:00 PM, David Nicol wrote:

> > I think that if obfuscating the source code (by compiling or
> > encrypting or whatever) is a high priority for you, then Perl may not
> > be the best choice of language for your software. And even for Java
> > there are decompilers and for PHP the code must be unencrypted to
> > run. So maybe C is the best choice.
>
> Bleach.pm is pretty fun, as are the other ones like it.  Making all  
> the
> variable names difficult and easy-to-confuse; adding garbage that  
> looks
> like code and making the code look like garbage; there is a lot of  
> room
> to improve code obfuscators.  Obfuscation and pretty-printing are  
> two sides
> of the same problem.  Why don't people decompile and disassemble as  
> much
> as they used to?  It's difficult.  Obfuscation works the same way.
>
> At my company, we wound up distributing a demonstration of a system  
> that
> was largely written in perl as a locked VMware virtual machine in  
> order to
> draw a clear box around it.  Sure someone who was knowlegable w/  
> vmware
> would be able to reset the config password on the virtual bios and  
> so on, but
> the line would have been crossed, as surely as removing the hard  
> drive and
> mounting it in another system would have.