Re: Protecting Software w/ Software License Keys...
Re: Protecting Software w/ Software License Keys...
- Subject: Re: Protecting Software w/ Software License Keys...
- From: "Erik J. Barzeski" <email@hidden>
- Date: Sat, 15 Jun 2002 17:24:23 -0400
On 6/15/02 3:40am, "Jeffrey T. Hazelwood" <email@hidden>:
>
From: "Jeffrey T. Hazelwood" <email@hidden>
>
Date: Fri, 14 Jun 2002 23:01:24 -0400
>
To: email@hidden
>
Subject: Protecting Software w/ Software License Keys...
>
>
I'm interested in creating commercial applications in Cocoa and am
>
wondering
>
what type of licensing, registration, demo mode and copy protection
>
schemes people
>
are using. Is there any software that you recommend to do this for Cocoa
>
apps? Or are there
>
easier homegrown methods you recommend?
I still ask that you IM me if you want more information, but here's how our
software works... (below).
>
I could probably make my own, but am having trouble deciding how to
>
"unlock" the app once a valid license key is entered. On OSX, where
>
would you store the bit that says, "Hey, I'm registered now." It can't
>
be the system defaults otherwise, someone can just enter the default and
>
the program is cracked.
>
>
Does anyone have any advice or more information on this subject that
>
they can share?
My app (to be released Tuesday) will work as follows...
1. user defaults "empty" by default (of course): obviously the app is
unregistered (and they've not changed any other prefs either).
2. when the app launches, a dialog appears asking for the license key (and
name, and email, etc.) pops up because my "isRegistered" method says "NO"
(more on this method later).
3. they can ignore this dialog, but until they fill it out properly, the
function "- (BOOL) isRegistered" returns NO. Our app, for example, simply
has a few:
if([self isRegistered]) ...
in our app. We limit the functionality or whatever of the app if we get NO
back from the method.
4. When they register the software (entering in name, email, etc. -
obviously you've provided them with some kind of P1234-5678-9000 type code)
properly, we use the MAC address of the machine and perform some math on it
and the license code. The result of this math, again on both the MAC and the
code is what we store in the user defaults (along with their name, email,
etc.). Whatever math or string operations you want to do with the two pieces
are up to you, and I'm not telling you what mine are :)
5. isRegistered performs the same math and the reverse math and, if both
match, returns YES, because the reg code (encoded against the MAC, decoded
against the MAC) in the defaults matches the freshly generated code.
There are of course ways to speed it up so that all this math doesn't occur
every time "isRegistered" is called.
We think that this method prevents anyone from copying the "registration
code" that we store in the defaults file to anyone else: it won't "math"
agains the MAC properly. It won't "math" against someone else's
name/email/etc.
It allows the same user to move the app to a new computer: the math is
simply done using the new MAC the first time they launch and then enter
their license code, name, email, etc. A user copying his prefs from one
machine to another will have to re-enter the code every time... But who
copies their prefs that frequently from one machine to another? Nobody...
Anyway, this limits the app to one machine, not just one user... As anyone
on that machine could read the other person's defaults file and - if they
don't mind using that person's name as their "Registered To:", take the
code.
How prominent you make the "registered to:" bit is a tad important too,
perhaps. Otherwise someone can register your software as "Steve Jobs" and
use "email@hidden" as the address and get a code from you that they don't
mind sharing at all with the hacker community, but they'd have to have at
least registered one copy.
Most crackers who want to crack your app:
A) won't spend money for it just to give the code away for free
B) don't mind using someone else's name as their "Registered To:"
The goal then becomes getting the honest people to pay. I think that by
preventing "registration" of the app simply by copying someone else's
defaults .plist, you've done a pretty good job of that.
Of course, we put our system to the test very soon... And our app isn't one
that crackers are really going to care to crack (I think). I'm not too
worried. I think we'll be okay...
Anyone else have an opinion or input?
--
Best wishes,
Erik J. Barzeski
If you don't know where you're going
You will probably not end up there.
*******************************************************************
Email: erik@(anything below)
AIM: iacas ICQ: 8186546
http://barzeski.com/ http://weims.net/
http://techstra.net/ http://cocoadevcentral.com/
http://soundsetcentral.com/ http://applescriptcentral.com/
*******************************************************************
_______________________________________________
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.