Re: [little OT] Licensing/Implementing in Cocoa/Obj-C
Re: [little OT] Licensing/Implementing in Cocoa/Obj-C
- Subject: Re: [little OT] Licensing/Implementing in Cocoa/Obj-C
- From: Greg Hurrell <email@hidden>
- Date: Tue, 20 Apr 2004 19:03:55 +0200
El 20/04/2004, a las 17:47, Alastair Houghton escribis:
Yes, it was me. The reason is that, as Nicko also pointed-out and as
I pointed-out when I first said public key crypto was overkill for
this task, it is relatively easy for an attacker to replace the
verification key, at which point they can generate keys. Or they
could just disable the licensing code altogether.
To play devil's advocate, the paper that Nicko links to --
<
http://www.ncipher.com/scripts/download.php?document=40> -- talks
about a couple of methods for making it harder to replace the
verification key. And there are others too.
But the key point is not that public key crypto makes it impossible to
crack an app (it doesn't), but that it makes it effectively impossible
to generate fake serial numbers. The damage done by a crack is always
going to be less than getting a serial number for your product leaked
to the monthly SerialBox (which surely has a circulation among tens of
thousands, and perhaps even hundreds of thousands of users), because
cracking the app requires a patch to be developed and distributed,
which is orders of magnitude harder than distributing a mere serial
number.
3. Those crackers who do it for a challenge. You *really* aren't
going to stop this group; at best, you might achieve a short lull
while they figure-out how your latest copy protection works, but it's
an arms race, and one that's stacked against you.
One advantage you have is that you have the source code. They have to
painstakingly reverse engineer your code, whereas you can edit in
Xcode. If crackers enjoy the challenge, programmers can enjoy it too.
And from my perspective, I'd rather be playing my end of the game from
within Xcode than from within gdb!
I basically agree with your typology of attackers. From an economic
perspective, you've got to weigh up what you do in terms of costs and
benefits. When designing and implementing your security measures, you
should spend 95% of your time addressing that portion of the user
population which will pay for the software if casually pirating it
isn't straightforward. By all means, spend another 5% playing games
with the hard-core hackers who will never pay, but only if you can
justify it in terms of enjoying the job, professional development, or
whatever. And for those who would in theory pay but can't afford it
(for example, students), consider offering handsome student discounts.
Cheers
Greg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.