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
