Re: Implementing Licensing in C/ObjC/Cocoa (was: Re: [now OT] Licensing/Implementing in Cocoa/Obj-C - Interest in product?)
Re: Implementing Licensing in C/ObjC/Cocoa (was: Re: [now OT] Licensing/Implementing in Cocoa/Obj-C - Interest in product?)
- Subject: Re: Implementing Licensing in C/ObjC/Cocoa (was: Re: [now OT] Licensing/Implementing in Cocoa/Obj-C - Interest in product?)
- From: Stefan Pantke <email@hidden>
- Date: Thu, 8 Apr 2004 16:57:38 +0200
Am 07.04.2004 um 10:29 schrieb Alastair Houghton:
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.
Thus, a product may be bundled in several flavors - standard and high
security.
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.
Yes, your are right. I see problems at this point as well.
Performing frequent check operations might help a bit, but is
not perfect.
But since even very large company's software got cracked, I
don't know how elaborate a protection schema should be.
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...
Good points!
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 :-)
In fact our current solution is pure C. Calling the stuff might be
performed from C functions or ObjC methods.
Moreover, I think inline expansion of functions or including code by
means of #define macros might help.
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.
Got the point! Does someone know of some article about debugger
protection?
Maybe this might be some good article for MacDev Magazin from O'Reilly.
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.
Thanks for these details, Alastair!
Stefan
_______________________________________________
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.