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: René van Amerongen <email@hidden>
- Date: Thu, 8 Apr 2004 10:02:18 +0200
The items that you are talking about are good points.
And I think that if the app has a weak base of safety in Obj-C, why
dont talk more about this kind of things to make it more save.
I rememeber a article about this with some ideas and explanation. Some
thing about the omnigroup.
Someone remember this also? I would like to find it gain. Also do
people have pointers to this kind of information, on what we can do.
R
Op 7-apr-04 om 10:29 heeft Alastair Houghton het volgende geschreven:
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.
_______________________________________________
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.