You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Miha Lampret <ml...@vo-ka.si> on 2006/08/23 14:01:08 UTC
Protecting source code
Hello all,
I am writting web application for mod_perl which will be installed on
client's server. Application is almost finished and now I am wondering
which is the best way to protect source code.
Already checked Module::Crypt but cound't get it to work. It doesn't
create any output file. I came a cross with schroud+ perl obfuscator
which looks ok, but I would like protect strings too. By strings I meen
text that is hardcoded in source and it is printed to web application
user. Do you have any experiences with other obfuscators or converters
to XS code?
Any information is welcome.
Thank you,
Miha
Re: Protecting source code
Posted by Boysenberry Payne <bo...@humaniteque.com>.
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.
>
>
Re: Protecting source code
Posted by David Nicol <da...@gmail.com>.
> 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.
Re: Protecting source code
Posted by Jonathan Vanasco <mo...@2xlp.com>.
On Aug 25, 2006, at 2:34 PM, David E. Wheeler 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.
Zend doesn't really encrypt php code.
It does essentially a 2 pass optimization. First it rewrites the
variable and function names ( which is essentially obfuscation ).
Then it parses the php and saves it in a format to run on the zend
platform, which is more efficient than the stock php base. and i
believe there is some license key that you can toss into files too.
i know a lot of people who use zend encoding, but not for any of the
'obfuscating' reasons- for performance: its the only php code
optimizer that actually works and is stable. if you've got a 4
machine cluster and need a 5th, $1k/yr is way cheaper than another
server and the associated maintenance.
If you *really* wanted to, you could run a compression/obfuscation
routine on your perl code -- though i don't know if there is a perl
version. I use the Dojo one for JS all the time - cuts down
whitespace and variable names by quite a bit, in turn saving a ton on
bandwidth resources.
it would be neat if mod_perl had some sort of optimization routine-
rewrite all the variable/function names as steamlined stuff
ie:
sub foobarbaz {}
sub f1 {}
it would be a nightmare to write, could never work with apache
reload, and would probably only save about 100k per 10mb of mp
code. but still.
Re: Protecting source code
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Aug 25, 2006, at 11:05, Octavian Rasnita wrote:
> Hi americans :-)
Heh. Nailed me. ;-)
> So the programmer works for the source code, makes it open source,
> and then
> comes another programmer that gets it, delete the name of the
> author, make
> some changes, and then sell the program pretending it is his code, and
> sometimes the second programmer has more relations and can contact
> more
> clients. In USA there are ways of protections, but in other
> countries there
> are not.
This issue is inherent in all open source software, of course, not
just Perl software.
> I think that if mod_perl programs could be very well encrypted, this
> technology would be a little more used than it is now, but they
> can't, and
> if this is a disadvantage for some of us, we shouldn't say that the
> programmers shouldn't need such a thing.
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.
But you should know that there are no perfect solutions to this
issue. Ultimately, it's a social and political issue, not a
technological issue.
Best,
David
Re: Protecting source code
Posted by Adrian Howard <ad...@quietstars.com>.
On 25 Aug 2006, at 19:56, Tim Pushor wrote:
[snip]
> I think it may also be useful to be able to prove in a court that
> you took steps to keep your secrets away from prying eyes, and that
> whoever belonged to those prying eyes deliberately took steps to
> uncover your secret - Regardless of the actual level of security
> provided by those steps ..
[snip]
IANAL but, to the best of my knowledge, this is untrue. Copyright is
what defines whether copying is legal or not.
I guess in the US you might be able to get they under the DMCA in
addition to copyright violation, but not having to overcome copy
protection doesn't make copying any more legal.
Cheers,
Adrian
Re: Protecting source code
Posted by Tim Pushor <ti...@crossthread.com>.
Danny Brian wrote:
> It will always be true that a dedicated hacker will be able to
> decompile, dump opcodes, or otherwise reverse engineer the work of
> another, regardless of the language or file format. But the value of
> compiling a program is not so much its security, but its illusion of
> security, and discouragement of all but the most determined folks from
> stealing the work of another. It's incorrect to claim that compiling
> or encrypting code does not protect it to a large degree, especially
> when the usual suspects are running CGI's hosted in a shared
> environment on some big web server, with no real programming know-how.
>
I think it may also be useful to be able to prove in a court that you
took steps to keep your secrets away from prying eyes, and that whoever
belonged to those prying eyes deliberately took steps to uncover your
secret - Regardless of the actual level of security provided by those
steps ..
Tim
Re: Protecting source code
Posted by Danny Brian <da...@brians.org>.
> I think that if mod_perl programs could be very well encrypted, this
> technology would be a little more used than it is now, but they
> can't, and
> if this is a disadvantage for some of us, we shouldn't say that the
> programmers shouldn't need such a thing.
Teddy makes a good point. This discussion comes and goes on various
Perl lists once a year or so, and the general consensus tends to be
that Perl programs should not try to encrypt or obfuscate themselves.
I think this stems more from the ideals of Open Source, and less from
the practical issues involved with copyright protection and the
possibility of prosecuting infringers, even within the USA. Is anyone
aware of a successful lawsuit by an independent Perl programmer for
breaking copyright? I doubt most have the resources to pursue
lawsuits, much less monitor for infringements. It's surprising to me
that the same Perl programmers who have a traditionally libertarian
[?] bent would in the same breath argue that the court is the
solution to our desire to protect our code. Eesh!
It will always be true that a dedicated hacker will be able to
decompile, dump opcodes, or otherwise reverse engineer the work of
another, regardless of the language or file format. But the value of
compiling a program is not so much its security, but its illusion of
security, and discouragement of all but the most determined folks
from stealing the work of another. It's incorrect to claim that
compiling or encrypting code does not protect it to a large degree,
especially when the usual suspects are running CGI's hosted in a
shared environment on some big web server, with no real programming
know-how.
Anyway, I do regret that there isn't an elegant way to do this with
Perl. If you need this ability, Perl is not a good choice for your
project, unless you're wiling to compile a perl/mod_perl against some
C lib that will handle the job pre-interpreter. I know of places that
has been done before.
- Danny
Re: Protecting source code
Posted by Octavian Rasnita <or...@gmail.com>.
Hi americans :-)
Please try to understand that the situation is not everywhere like in USA
regarding the respect for copyright, including the respect for open source
licenses.
I have seen the suggestion for protecting the code by a license for many
times, but there are countries where those licenses don't have any real
value, even if the laws theoreticly protect the copyright.
So the programmer works for the source code, makes it open source, and then
comes another programmer that gets it, delete the name of the author, make
some changes, and then sell the program pretending it is his code, and
sometimes the second programmer has more relations and can contact more
clients. In USA there are ways of protections, but in other countries there
are not.
If the programmer who made the program cannot protect it in any way, he
won't be able to survive by creating open source programs then providing
different type of services, because there will be other guys that will take
his potential clients, using his work.
This is one of the reasons perl has a big disadvantage. The programmers
prefer to be able to encrypt the programs made in PHP using Zend Encoder or
other tools.
I think that if mod_perl programs could be very well encrypted, this
technology would be a little more used than it is now, but they can't, and
if this is a disadvantage for some of us, we shouldn't say that the
programmers shouldn't need such a thing.
Teddy
----- Original Message -----
From: "David E. Wheeler" <da...@kineticode.com>
> On Aug 25, 2006, at 09:58, Jonathan Vanasco wrote:
>
> > at that point, i realized two things:
> >
> > a- encrypting/obfuscating perl code just doesn't work when you
> > need to decrypt it. it also doesn't work when there are
> > decompilers and stuff out there. the best you can do is make
> > something marginally difficult.
> > b- given the ease in decrypting the code, and the code itself, it
> > became pretty obvious that they weren't trying to protect the code,
> > as much as they were making it unreadable as it was some of the
> > worst stuff i've ever seen.
Re: Protecting source code
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Aug 25, 2006, at 09:58, Jonathan Vanasco wrote:
> at that point, i realized two things:
>
> a- encrypting/obfuscating perl code just doesn't work when you
> need to decrypt it. it also doesn't work when there are
> decompilers and stuff out there. the best you can do is make
> something marginally difficult.
> b- given the ease in decrypting the code, and the code itself, it
> became pretty obvious that they weren't trying to protect the code,
> as much as they were making it unreadable as it was some of the
> worst stuff i've ever seen.
Great story!
Cheers,
David
Re: Protecting source code
Posted by Jonathan Vanasco <jo...@2xlp.com>.
On Aug 25, 2006, at 11:13 AM, Hendrik Van Belleghem wrote:
> The reason for me not to use any of these encryption or obfuscation
> tools (even though I wrote one), is purely for logical reasons. Source
> readability is part of the perl featureset for me. If you don't want
> people to read it, don't develop in a language that has it as one of
> it's primary advantages.
a few years ago the company i worked for decided they wanted to
market in-store kiosks. one of the owners got drunk with a high
school friend, and they decided to market a line of french made
scanner kiosks that the friend had some business connection to.
the scanners basically read a barcode, and showed some image / video.
the next day, the boss smokes way too much pot before a lunch
meeting ( 50yr old depressed guy who just got high every day. not
fun to be near ), and comes back saying that we need to deliver 2 of
these with new 'upgraded features' in 2 weeks time. We contact the
french people, they say "oh yeah, sure the units can do that", not a
problem. Then they laugh (deservedly) when we say 2 weeks, and
quoted 6months.
So i take a torx driver, disassemble the unit, and try to figure out
what makes it tick. the plan is we buy the units from them ( under
contract ), but reverse engineer the software so it can do what the
idiot marketer promised.
The units ran a crapped out linux distro with xfree86. i think it
was debian-unmaintained.
An encrypted perl daemon bridged a serial scanner with an Opera
browser ( they could only get opera to fullscreen correctly. it was
kind of funny, hook up a keyboard and hit ctl-f, and the opera ad
frame appears. and i'm pretty sure it was crazy illegal doing it that
way ) and a bad compile of mplayer for video
The perl daemon looked like it would be hard to beat, then i remembered:
perl is an interpreted language
if the source code is encrypted , it must be unencrypted before
being fed into the interpreter
so i figured out which cpan module they used to encrypt with, used
that to figure out where the password was, and in about 75 seconds
of total work , got the password and decrypted their daemon.
at that point, i realized two things:
a- encrypting/obfuscating perl code just doesn't work when you need
to decrypt it. it also doesn't work when there are decompilers and
stuff out there. the best you can do is make something marginally
difficult.
b- given the ease in decrypting the code, and the code itself, it
became pretty obvious that they weren't trying to protect the code,
as much as they were making it unreadable as it was some of the worst
stuff i've ever seen.
FWIW we ended up using a twisted-python server + a custom flash
framework running in Konqueror ( it fs'd right, and no quasi-legal
issues with what we were doing ) on a custom linux kernel ( i tweaked
the hell out of it. got video playing *really* well ). i think i
ended up using VLC or a custom mplayer too. i heard my old company
sold the upgrades to the french company for a few hardware units.
====================================
On Aug 25, 2006, at 10:44 AM, Saltbreez wrote:
> You write that you [are] "writting web application for mod_perl which
> will be installed on client's server". That is to say that you are
> using a product licensed as either GNU or Artistic. I am not an
> attorney, but my understanding of the intent of these licenses is to
> prevent people from doing just what you describe.
I suggest you read through the various licenses- there's a large
listing at opensource.org/licenses. Its pretty clear that you're not
an attorney, and you should really have a better understanding of the
licenses and what they mean.
i'm not an attorney, but most of my friends are and I did a lot of
law in undergrad, so i'm familiar with what to look for:
The artistic perl license covers the actual perl code and the any
modules released under it. It clearly ( and purposefully ) does not
apply the license to the user-defined subroutines that interact with
the perl internals or CPAN modules.
If you build an app that relies on GPL'd libraries to function , or
is a just a version of a GPL app ( ie a custom perl interprete), the
app is crippled by the GPL. I don't know what the legal approach to
distributing Perl with your app is (that might complicate GPL), but
few people do that.
If all code written in perl/python/php/erlang/c/etc were required to
be GPL'd, nobody would use those languages.
Re: Protecting source code
Posted by Hendrik Van Belleghem <he...@gmail.com>.
Hi,
Just because you're using Apache (Apache License), mod_perl (Apache
License) and Perl (GPL/Artistic), it doesn't mean anything you develop
has to use any of those licenses. It is perfectly legal to license
your perl applications under any license you choose. It's also
perfectly ok to open-source an application written in a proprietary
language. Last I checked, programming language of choice has nothing
to do with the EULA (unless ofcourse the code was generated by a tool
that has a EULA which states that generated code cannot be
redistributed etc.. but that's just far-fetched). Protecting your
source the hard way by encrypting/obfuscating/compiling is still not
foolproof. There is no 100% safe way to do this. I'd stick to the EULA
and cross your fingers.
Then again, I'm not an attorney.
The reason for me not to use any of these encryption or obfuscation
tools (even though I wrote one), is purely for logical reasons. Source
readability is part of the perl featureset for me. If you don't want
people to read it, don't develop in a language that has it as one of
it's primary advantages.
my 2 cents
Hendrik
On 8/25/06, Saltbreez <sa...@gmail.com> wrote:
> This conversation disturbs me at a level more fundamental than source
> code or business requirements.
>
> You write that you [are] "writting web application for mod_perl which
> will be installed on client's server". That is to say that you are
> using a product licensed as either GNU or Artistic. I am not an
> attorney, but my understanding of the intent of these licenses is to
> prevent people from doing just what you describe.
>
> If you want to protect your work, develop in a proprietary language.
> If you want to use the fruits of decades of open source enthusiasts
> work, then open your source.
>
> Christian Werner Sr.
>
> On 8/23/06, Miha Lampret <ml...@vo-ka.si> wrote:
> > Hello all,
> >
> > I am writting web application for mod_perl which will be installed on
> > client's server. Application is almost finished and now I am wondering
> > which is the best way to protect source code.
> >
> > Already checked Module::Crypt but cound't get it to work. It doesn't
> > create any output file. I came a cross with schroud+ perl obfuscator
> > which looks ok, but I would like protect strings too. By strings I meen
> > text that is hardcoded in source and it is printed to web application
> > user. Do you have any experiences with other obfuscators or converters
> > to XS code?
> >
> > Any information is welcome.
> >
> > Thank you,
> > Miha
> >
>
>
> --
> Do you know how high... The Salt Breez
> the Robin flies, Also Know As ...
> Or why the Mint leaf... Christian Werner Sr
> smells so sweet? saltbreez@gmail.com
> The Salt Breez
>
--
Hendrik Van Belleghem
Spine - The backbone for your website - http://spine.sf.net
Re: Protecting source code
Posted by Saltbreez <sa...@gmail.com>.
This conversation disturbs me at a level more fundamental than source
code or business requirements.
You write that you [are] "writting web application for mod_perl which
will be installed on client's server". That is to say that you are
using a product licensed as either GNU or Artistic. I am not an
attorney, but my understanding of the intent of these licenses is to
prevent people from doing just what you describe.
If you want to protect your work, develop in a proprietary language.
If you want to use the fruits of decades of open source enthusiasts
work, then open your source.
Christian Werner Sr.
On 8/23/06, Miha Lampret <ml...@vo-ka.si> wrote:
> Hello all,
>
> I am writting web application for mod_perl which will be installed on
> client's server. Application is almost finished and now I am wondering
> which is the best way to protect source code.
>
> Already checked Module::Crypt but cound't get it to work. It doesn't
> create any output file. I came a cross with schroud+ perl obfuscator
> which looks ok, but I would like protect strings too. By strings I meen
> text that is hardcoded in source and it is printed to web application
> user. Do you have any experiences with other obfuscators or converters
> to XS code?
>
> Any information is welcome.
>
> Thank you,
> Miha
>
--
Do you know how high... The Salt Breez
the Robin flies, Also Know As ...
Or why the Mint leaf... Christian Werner Sr
smells so sweet? saltbreez@gmail.com
The Salt Breez
Re: Protecting source code
Posted by "JupiterHost.Net" <ml...@jupiterhost.net>.
>> > I am writting web application for mod_perl which will be installed
>> > on client's server. Application is almost finished and now I am
>> > wondering which is the best way to protect source code.
>> >
>> > Already checked Module::Crypt but cound't get it to work. It
>> > doesn't create any output file. I came a cross with schroud+ perl
>> > obfuscator which looks ok, but I would like protect strings too. By
>> > strings I meen text that is hardcoded in source and it is printed
>> > to web application user. Do you have any experiences with other
>> > obfuscators or converters to XS code?
>> >
>> > Any information is welcome.
Legal protection is the best way. Other than that see Acme::Enc its
pretty sexxy
Re: Protecting source code
Posted by Hendrik Van Belleghem <he...@gmail.com>.
As the author of Filter::CBC, another source code encryption module,
I can officially state that module encryption is not supported by my
module either. You might want to look at Filter::Crypto but I have no
experience with it.
HTH
On 8/23/06, Jonathan Vanasco <mo...@2xlp.com> wrote:
>
> On Aug 23, 2006, at 8:01 AM, Miha Lampret wrote:
>
> > Hello all,
> >
> > I am writting web application for mod_perl which will be installed
> > on client's server. Application is almost finished and now I am
> > wondering which is the best way to protect source code.
> >
> > Already checked Module::Crypt but cound't get it to work. It
> > doesn't create any output file. I came a cross with schroud+ perl
> > obfuscator which looks ok, but I would like protect strings too. By
> > strings I meen text that is hardcoded in source and it is printed
> > to web application user. Do you have any experiences with other
> > obfuscators or converters to XS code?
> >
> > Any information is welcome.
> >
> > Thank you,
> > Miha
>
> Best way- fill it with copyright notices, use a restrictive license,
> get them to sign a document.
>
> That's really the only way to protect perl code-- by legally
> protecting it.
> And then suing the ass off of your client if they break it.
>
> You can not 'protect' perl source the way you are likely thinking.
> All you can do is obfuscate it, and that is easily broken. You can
> compile it (perlcc or activestate), but then someone who wants it /
> needs it bad enough will decompile it.
>
>
>
--
Hendrik Van Belleghem
Spine - The backbone for your website - http://spine.sf.net
Re: Protecting source code
Posted by Adrian Howard <ad...@quietstars.com>.
On 25 Aug 2006, at 12:41, Ali ISIK wrote:
> How about stunnix, folks, does anyone have any experience
> with their product?
Ahhh... Stunnix.
You may find <http://www.perlmonks.org/index.pl?node_id=243011>,
<http://www.perlmonks.org/index.pl?node_id=245430> and <http://
www.theregister.co.uk/2003/07/03/open_source_company_wants_cash/>
interesting reads.
I wouldn't spend money on it myself.
Adrian
Re: Protecting source code
Posted by Ali ISIK <fe...@gmail.com>.
How about stunnix, folks, does anyone have any experience
with their product?
--Ali Isik
On 8/23/06, Jonathan Vanasco <mo...@2xlp.com> wrote:
>
> On Aug 23, 2006, at 8:01 AM, Miha Lampret wrote:
>
> > Hello all,
> >
> > I am writting web application for mod_perl which will be installed
> > on client's server. Application is almost finished and now I am
> > wondering which is the best way to protect source code.
> >
> > Already checked Module::Crypt but cound't get it to work. It
> > doesn't create any output file. I came a cross with schroud+ perl
> > obfuscator which looks ok, but I would like protect strings too. By
> > strings I meen text that is hardcoded in source and it is printed
> > to web application user. Do you have any experiences with other
> > obfuscators or converters to XS code?
> >
> > Any information is welcome.
> >
> > Thank you,
> > Miha
>
> Best way- fill it with copyright notices, use a restrictive license,
> get them to sign a document.
>
> That's really the only way to protect perl code-- by legally
> protecting it.
> And then suing the ass off of your client if they break it.
>
> You can not 'protect' perl source the way you are likely thinking.
> All you can do is obfuscate it, and that is easily broken. You can
> compile it (perlcc or activestate), but then someone who wants it /
> needs it bad enough will decompile it.
>
>
>
Re: Protecting source code
Posted by Jonathan Vanasco <mo...@2xlp.com>.
On Aug 23, 2006, at 8:01 AM, Miha Lampret wrote:
> Hello all,
>
> I am writting web application for mod_perl which will be installed
> on client's server. Application is almost finished and now I am
> wondering which is the best way to protect source code.
>
> Already checked Module::Crypt but cound't get it to work. It
> doesn't create any output file. I came a cross with schroud+ perl
> obfuscator which looks ok, but I would like protect strings too. By
> strings I meen text that is hardcoded in source and it is printed
> to web application user. Do you have any experiences with other
> obfuscators or converters to XS code?
>
> Any information is welcome.
>
> Thank you,
> Miha
Best way- fill it with copyright notices, use a restrictive license,
get them to sign a document.
That's really the only way to protect perl code-- by legally
protecting it.
And then suing the ass off of your client if they break it.
You can not 'protect' perl source the way you are likely thinking.
All you can do is obfuscate it, and that is easily broken. You can
compile it (perlcc or activestate), but then someone who wants it /
needs it bad enough will decompile it.