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.
