Implementing Licensing in C/ObjC/Cocoa (was: Re: [now OT] Licensing/Implementing in Cocoa/Obj-C - Interest in product?)
Implementing Licensing in C/ObjC/Cocoa (was: Re: [now OT] Licensing/Implementing in Cocoa/Obj-C - Interest in product?)
- Subject: Implementing Licensing in C/ObjC/Cocoa (was: Re: [now OT] Licensing/Implementing in Cocoa/Obj-C - Interest in product?)
- From: Alastair Houghton <email@hidden>
- Date: Wed, 7 Apr 2004 09:29:20 +0100
On 7 Apr 2004, at 06:21, j o a r wrote:
>
On 2004-04-06, at 22.56, Stefan Pantke wrote:
>
>
> Moreover, it is technical impossible to generate new license files,
>
> since
>
> only the LinceseBuilder application can do, since only the
>
> LicenseBuilder knows
>
> both - the public and the private key.
>
>
While that sounds nice, I don't think it matters much as most apps are
>
pirated either via a distribution of the serial number (or in this case
>
licence file), or by patching the application to not even perform the
>
license check. This approach is safer than a simple serial number only
>
by being tougher to break via a brute force attack. Right?
Indeed. If you want to protect your code from piracy, a simple
registration key will stop casual pirates, especially if its use is
linked to their name. Determined crackers are much harder to stop, and
no amount of security in the key *generation* will prevent them from
writing nops over crucial instructions in your licensing code, or even
(in the case of public key crypto-based solutions) writing their own
public key into your executable file so that they can generate key
files themselves.
The best way to prevent crackers from pirating your program is to make
it awkward for them to debug it, for instance by spreading license
checks throughout your code, or by running timers to detect debuggers
(but be careful... a slow machine or one that's swapping heavily
shouldn't fall foul of your licensing checks), by parallelising loops
in your license checking code, by obfuscating comparisons so that
they're harder to find, by accessing the same variables using different
fixed addresses, using global variables rather than locals (since you
can't tell that they won't be accessed from other places in the code,
so you have to look), etc... Checksumming your code occasionally is
also a pain in the neck, as is calling the licensing or checksumming
routines from multiple threads (not necessarily simultaneously),
because it means that breakpoints set in them can fire at unexpected
moments.
As a rule of thumb, writing your program *badly* (lots of gotos, few
functions or far too many functions [either extreme is good], lots of
global variables, no OO) makes it harder to debug, although there is
obviously a balance to be struck... after all, you have to maintain it
once you've finished :-)
Anyway, you get the idea. Crackers will attack your program *with a
debugger*; that's what you need to defend against. Whether it's easy
(or possible) for them to generate keys makes very little difference to
their ability to pirate your software.
BTW, ObjC is *exceptionally* bad for licensing code; the runtime leaks
*way* to much information, which would make it very much easier for a
cracker to break your licensing scheme. I'd keep your licensing code
in C, if I were you, and I'd take care to run licensing checks from a
sprinkling of unrelated ObjC methods if you're interfacing it with
ObjC... that way, at least they can't disable it in one place in your
app.
Kind regards,
Alastair.
--
http://www.alastairs-place.net
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.