[extropy-chat] FWD (SK) RFC: copy protection report

[Adrian Tymes]

And even then, expect to be cracked eventually.  The fundamental
problem is, your software is operating on the user's computer, which is
completely under the user's control.  You're not shipping a black box
that can't be opened without destroying it.  You're shipping a set of
instructions, which sufficiently patient users (and users have a lot of
patience for getting rid of that which annoys them, copy protection
being a prime example) can easily* examine to remove the copy
protection bit (unless it's woven into your code, in a way that either
degrades performance unacceptably or raises development costs far
beyond what can reasonably be paid).

* Part of the problem may stem from if your boss has never
reverse-engineered software, and thus sees a compiled program as an
indecipherable mess of bits.  There are very sophisticated tools for
reverse-engineering out there, available for free or essentially free.
Reverse-engineering is itself a skill that must be learned to be used;
try drawing parallels to some technical skill your boss has that an
average person would not - programming, preferably, since it is very
easy to demonstrate that an average non-programmer sees source code as
a mess of stuff well beyond their understanding, then point out that
"indecipherable" compiled code is merely the same thing to the
untrained.  (And training said boss to see this would likely cost waaay
more than would be appropriate to spend merely to prove this point,
although many of the more advanced of your target users will have the
skill as a job requirement, to be able to better point out where the
bugs they find are.)

Which suggests the one "copy protection" scheme that is actually seeing
fair use these days: never put the code on the user's computer in the
first place.  What the user gets is a client to a service run on
central servers you maintain (although, quite a few of these
applications use common Web browsers - Mozilla and MSIE at a minimum -
as these "clients", so as to avoid installing anything proprietary on
the user's computer).  All of the critical code runs only on your
computers; at no point does the user's computer see (and possibly
capture) this code.  Of course, the downsides are that you have to keep
a constantly-running server farm, which can be quite expensive if your
program is computationally expensive and you have a lot of users, and
your program becomes useless on computers unable to connect to your
computers (or if your company ever goes out of business - which might
be no problem for you, but may be a very big perceived problem for
certain customers who worry about your potential long-term survival,
for instance since you tolerate managers who insist on implementing
long-discredited solutions like copy protection).  You also generally
don't get to "sell" updates to your software (although the recurring
service fees from longtime users, and the lack of need to support older
versions, can counter the impact of this).

In general, it switches your business from a product-based revenue
model to a service-based revenue model, and so should not be undertaken
lightly.  But it really is the only way to make absolutely sure your
software is never pirated.  Making your money off of support contracts
is a halfway step towards this, and would also work (especially if your
software is so complex it can't really be used without support - which
may well be the case, given your application) in the total absence of
hard (and, again, practically worthless) copy protection.

--- Acy Stapp <acy.stapp at gmail.com> wrote:

> Online unlocking can be defeated by capturing the decrypted code
> using
> SoftICE or a hardware in-circuit emulator. There are numeroues
> methods
> for detecting SoftICE and other debuggers, but in the end your only
> solutions are to use an off-the-shelf copy protection package and
> accept that you will be cracked or develop your own copy protection,
> and expect to be cracked unless you hire an expert to develop it
> specifically for your product.
> 
> Acy
> 
> On 12/1/05, Eugen Leitl <eugen at leitl.org> wrote:
> > On Thu, Dec 01, 2005 at 09:34:23AM -0600, Acy Stapp wrote:
> >
> > > At some point in your code you are going to have a function to
> check
> > > the copy protection and a cracker will find this function and
> change
> > > the machine code to return true.
> >
> > Online unlocking (decrypting part of the application with a key
> > obtained from a server or a piece of application itself) would do.
> >
> > > Really your only hope is to be so obscure that noone wants your
> > > product and no crackers want to break it.
> >
> > Another model is charge for support. Then you can even opensource
> > your package.
> >
> > --
> > Eugen* Leitl <a href="http://leitl.org">leitl</a>
> > ______________________________________________________________
> > ICBM: 48.07100, 11.36820            http://www.leitl.org
> > 8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> >
> > iD8DBQFDjx2UdbAkQ4sp9r4RAvYeAKCUIgSJzeiEXDl0/ybqXCHmEWSCqwCfT82C
> > GeRBDlOwn+2f64tgkUJHwls=
> > =ailr
> > -----END PGP SIGNATURE-----
> >
> >
> > _______________________________________________
> > extropy-chat mailing list
> > extropy-chat at lists.extropy.org
> > http://lists.extropy.org/mailman/listinfo/extropy-chat
> >
> >
> >
> _______________________________________________
> extropy-chat mailing list
> extropy-chat at lists.extropy.org
> http://lists.extropy.org/mailman/listinfo/extropy-chat
>