Re: Commercial app demo

[Gidon Wise]

I must confess that I wrote a buggy but small script that makes perl 
code unreadable. I promise. It basically removes comments, excess white space, and 
changes all the
identifiers to weird names. It was during a 
silly moment and I'm not proud. But, if you can get it to be any uglier, 
we can use it to generate secret codes in perl :). I'd suggest moving 
all the strings to the front and doing some random reversible operations 
as a final bit of ugliness.

http://www.gidon.com/scratch/

Matt Sergeant wrote:
> 
> On Thu, 10 Feb 2000, Fabrice Scemama wrote:
> > There's another way. We can't build pre-compiled modules easily,
> > but even when you code in C or Java, desassemblers can extract
> > some source from the binaries you deliver. As far as perl scripts are
> > concerned, a workaround consists in trivially removing all comments
> > and \n from the source, which makes it as hard to understand as
> > raw C desassembled code.
> 
> Maybe the way _you_ write code :)
> 
> --
> 
> 
> Details: FastNet Software Ltd - XML, Perl, Databases.
> Tagline: High Performance Web Solutions
> Web Sites: http://come.to/fastnet http://sergeant.org
> Available for Consultancy, Contracts and Training.

Re: Commercial app demo

[Ask Bjoern Hansen]

On Wed, 9 Feb 2000, Matt Sergeant wrote:

> Has anyone delivered a commericial mod_perl application before? If so, how
> do you handle demo versions, preferably with expiration dates?  [...]

Contracts, Trust and Good Relations to the customer.

Being a small/one man company you could make it a sales argument that they
get the source althought they can't redistribute it. (So they're able to
fix bugs and make some changes even if you discontinue the product). You
could even say in the contract that if you stop supporting the product the
license automagically converts to [insert favorite Open Source license].


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: Commercial app demo

[G.W. Haywood]

Hi there,

On Thu, 10 Feb 2000, Fabrice Scemama wrote:

> There's another way. We can't build pre-compiled modules easily,
> but even when you code in C or Java, desassemblers can extract
> some source from the binaries you deliver. As far as perl scripts are
> concerned, a workaround consists in trivially removing all comments
> and \n from the source, which makes it as hard to understand as
> raw C desassembled code.

Perl is only *semi* free-format.  Removing \n will break much Perl
code, for example because of the use of the print <

Re: Commercial app demo

[Matt Sergeant]

On Thu, 10 Feb 2000, Fabrice Scemama wrote:
> There's another way. We can't build pre-compiled modules easily,
> but even when you code in C or Java, desassemblers can extract
> some source from the binaries you deliver. As far as perl scripts are
> concerned, a workaround consists in trivially removing all comments
> and \n from the source, which makes it as hard to understand as
> raw C desassembled code.

Maybe the way _you_ write code :)

-- 


Details: FastNet Software Ltd - XML, Perl, Databases.
Tagline: High Performance Web Solutions
Web Sites: http://come.to/fastnet http://sergeant.org
Available for Consultancy, Contracts and Training.

Re: Commercial app demo

[Stas Bekman]

> Matt Sergeant <[EMAIL PROTECTED]> writes:
> 
> > Has anyone delivered a commericial mod_perl application before? If so, how
> > do you handle demo versions, preferably with expiration dates? One thought
> > is to simply xor encrypt some of the modules when the user downloads it,
> > mail him a key, and use the Filter module to decrypt at runtime using his
> > key (retrieved from STDIN at server startup time).

Embed a Perl code into a C wrapper or XS glued C code inside perl. Make
sure that it'd be really hard to emulate and reverse engineer the
functionality hidden in this block. Once you thought about it, your
question is non different from all compiled com apps.

I can think of C code calling the rest of the Perl. All the protection
mechanism to exist in C code, and a few tricks to make the Perl code
"unusable" to some degree without this C code.  See 'Advanced Perl
Programming' Ch.19 "Embedding Perl" and perlembed manpage.

The phylosophical, ethical and financial discussion of this issue:

Every determined user will be able to crack it, but people with money in
hand and companies will be honest and buy your final product if they want
it.  Protect your demo version with proper license and not walls.

People without money, won't buy it anyway, so you cannot reach their
wallets no matter what you do. So give them the "free" version, by leaving
an opportunity to reverse engineer the code. Here is the example showed by
our beloved neighbour M$.

M$ has helped to pirate Windoze dists in Russia, understanding that they
cannot ask for $100+ from people whose monthly salary is less than $30. It
didn't cost them a cent, yet they had a much bigger user base. You can buy
a CD with Windoze and all M$ products for as little as $5 on the black
market.  Another aspect of M$ sanity is that in a long run, some of the
Russians became rich and could afford to buy the official version of the
product. 

But I'm sure they won't because of the history, 99% of the sw in Russia is
pirated. 95% in Israel (In Israel when you buy a PC, you get Windoze and
office preinstalled for free... it's being changed now though.) These are
the places called "one disk/per country". Someone is stupid enough to buy
the original version, the moment this happens everybody else have it for
free. 
 
Back to mod_perl :)

___
Stas Bekmanmailto:[EMAIL PROTECTED]  http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.orgmodperl.sourcegarden.org   perlmonth.comperl.org
single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com

Re: Commercial app demo

[Chip Turner]

Fabrice Scemama <[EMAIL PROTECTED]> writes:

> There's another way. We can't build pre-compiled modules easily,
> but even when you code in C or Java, desassemblers can extract
> some source from the binaries you deliver. As far as perl scripts are
> concerned, a workaround consists in trivially removing all comments
> and \n from the source, which makes it as hard to understand as
> raw C desassembled code.

Unfortunately, this doesn't work.  cperl mode in emacs can prettify
perl code, not to mention B::Deparse.  For instance:

perl -MO=Deparse -e 'print while 1'
prints...
-e syntax OK
print $_ while 1;

It basically deparses the perl parse tree.  It gives pretty good
output; not perfect, but getting there.  Plus it expands and
simplifies some things, such as the implied $_ above.  It's quite
useful for figuring out messy obfuscated perl.

Even compiled perl would suffer from this problem.  At least when you
compile to C or Java the parse tree doesn't follow you around :)

Chip

-- 
Chip Turner   [EMAIL PROTECTED]
  Programmer, ZFx, Inc.  www.zfx.com
  PGP key available at wwwkeys.us.pgp.net

Re: Commercial app demo

[Fabrice Scemama]

There's another way. We can't build pre-compiled modules easily,
but even when you code in C or Java, desassemblers can extract
some source from the binaries you deliver. As far as perl scripts are
concerned, a workaround consists in trivially removing all comments
and \n from the source, which makes it as hard to understand as
raw C desassembled code.

Chip Turner wrote:
> 
> Matt Sergeant <[EMAIL PROTECTED]> writes:
> 
> > Has anyone delivered a commericial mod_perl application before? If so, how
> > do you handle demo versions, preferably with expiration dates? One thought
> > is to simply xor encrypt some of the modules when the user downloads it,
> > mail him a key, and use the Filter module to decrypt at runtime using his
> > key (retrieved from STDIN at server startup time).
> 
> (cut)
> 
> The problem is that no matter how you encrypt the system, it has to
> know how to decrypt itself.  That is, if you xor, or even used DES or
> IDEA or whatnot, the key (password, etc) has to be included with the
> modules, and therefore a suitably sophisticated programmer could
> extract the key, decrypt your code, and have his way with your
> source.
> 
> It can be very frustrating to not be able to compile perl :(
> 
> Even without the key, they could use some kind of B::Deparse trick to
> get just about all of the code anyway.
> 
> It's a problem we've run up against where I work.  We've considered a
> number of possibilities, but none are perfect.
> 
> Unfortunately all you can hope for is to make it very, very hard for
> them to modify; with enough resources, a sufficiently sophisticated
> attacker could change your code and make it non-trial without a huge
> amount of labor.
> 
> Chip
> 
> --
> Chip Turner   [EMAIL PROTECTED]
>   Programmer, ZFx, Inc.  www.zfx.com
>   PGP key available at wwwkeys.us.pgp.net

Re: Commercial app demo

[Ken Williams]

How about only shipping part of the software, with the remaining part of the
software running on your own (not the client) machine?  For instance, certain
subroutines could be split off, and the input & output could be passed back and
forth between the client and the vendor.  Then you can easily tell who's
running the demo by monitoring requests.

The downside, of course, is that the demo will be quite slow compared to the
real thing, if it has to send data all over the internet.  Perhaps another
reason to upgrade to the real version. =)


[EMAIL PROTECTED] (Matt Sergeant) wrote:
>Has anyone delivered a commericial mod_perl application before? If so, how
>do you handle demo versions, preferably with expiration dates? One thought
>is to simply xor encrypt some of the modules when the user downloads it,
>mail him a key, and use the Filter module to decrypt at runtime using his
>key (retrieved from STDIN at server startup time).

  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum

Re: Commercial app demo

[Jeffrey W. Baker]

Chip Turner wrote:
> 
> The problem is that no matter how you encrypt the system, it has to
> know how to decrypt itself.  That is, if you xor, or even used DES or
> IDEA or whatnot, the key (password, etc) has to be included with the
> modules, and therefore a suitably sophisticated programmer could
> extract the key, decrypt your code, and have his way with your
> source.
> 
> It can be very frustrating to not be able to compile perl :(
> 
> Even without the key, they could use some kind of B::Deparse trick to
> get just about all of the code anyway.
> 
> It's a problem we've run up against where I work.  We've considered a
> number of possibilities, but none are perfect.
> 
> Unfortunately all you can hope for is to make it very, very hard for
> them to modify; with enough resources, a sufficiently sophisticated
> attacker could change your code and make it non-trial without a huge
> amount of labor.

Or you could just ship the product with the source code, and prohibit
redistribution in the sales contract.

-jwb

Re: Commercial app demo

[Chip Turner]

Matt Sergeant <[EMAIL PROTECTED]> writes:

> Has anyone delivered a commericial mod_perl application before? If so, how
> do you handle demo versions, preferably with expiration dates? One thought
> is to simply xor encrypt some of the modules when the user downloads it,
> mail him a key, and use the Filter module to decrypt at runtime using his
> key (retrieved from STDIN at server startup time).

(cut)

The problem is that no matter how you encrypt the system, it has to
know how to decrypt itself.  That is, if you xor, or even used DES or
IDEA or whatnot, the key (password, etc) has to be included with the
modules, and therefore a suitably sophisticated programmer could
extract the key, decrypt your code, and have his way with your
source.

It can be very frustrating to not be able to compile perl :(

Even without the key, they could use some kind of B::Deparse trick to
get just about all of the code anyway.

It's a problem we've run up against where I work.  We've considered a
number of possibilities, but none are perfect.

Unfortunately all you can hope for is to make it very, very hard for
them to modify; with enough resources, a sufficiently sophisticated
attacker could change your code and make it non-trial without a huge
amount of labor.

Chip

-- 
Chip Turner   [EMAIL PROTECTED]
  Programmer, ZFx, Inc.  www.zfx.com
  PGP key available at wwwkeys.us.pgp.net

Commercial app demo

[Matt Sergeant]

Has anyone delivered a commericial mod_perl application before? If so, how
do you handle demo versions, preferably with expiration dates? One thought
is to simply xor encrypt some of the modules when the user downloads it,
mail him a key, and use the Filter module to decrypt at runtime using his
key (retrieved from STDIN at server startup time).

Please don't flame me about how this isn't secure - I know all the issues.
The point is to provide a timeing out demo version - not protect the source
code. I just want to prevent the user from editing and removing the "die if
time > " line as much as possible.

Another alternative, which I've seen, is severely limited demo versions
(e.g. wwwthreads takes that approach - shipping an earlier demo version).
I'd rather not go down that route, as it means I have to code in a way that
allows major functionality to simply be removed.

Another is to ship some of the code built in pre-compiled XS. But then I'm
architecture dependant and I'd rather not be.

The final alternative is just an online demo, which are never particularly
satisfactory for highly customisable systems.

-- 


Details: FastNet Software Ltd - XML, Perl, Databases.
Tagline: High Performance Web Solutions
Web Sites: http://come.to/fastnet http://sergeant.org
Available for Consultancy, Contracts and Training.