Re: Licences 101 - Copy Protection for Newbies
Re: Licences 101 - Copy Protection for Newbies
- Subject: Re: Licences 101 - Copy Protection for Newbies
- From: Peter Sichel <email@hidden>
- Date: Mon, 23 Sep 2002 11:08:27 -0400
I think you have the basics below. I would offer some possible
refinements based on my experience:
(1) If you use a key checking algorithm (some hash of the users
name, organization, date, etc...) do not include the code
needed to generate valid keys within the software you supply to
customers. You can avoid this by encrypting the generated key
and then decrypting it in your application before applying
your key checking algorithm.
(2) If your registration keys are distributed electronically, consider
using an XML plist file as your registration key.
The user simply places the file in the same folder as the application,
or copies (drags) the entire contents to a designated input field.
[You want the user to do as little typing as possible.]
The plist format gives you the flexibility to evolve your
registration mechanism as needed by adding expiration dates,
hardware identifiers, or stronger cryptography if desired.
Reading or writing the registration data to or from an
NSDictionary is a single line of code. Once in dictionary
form, checking or modifying registration attributes is easy.
(3) If you want to offer a fully functional trial period, on the
first run calculate an expiration date some time in the
future and write this date in a few different places on
the users hard drive. On subsequent runs, check each location
and use the earliest expiration date found. [People will often
try deleting preferences files to reset the trial]
(4) Do not try to roll your own encryption scheme or cryptography.
There are many good techniques widely available (consider SHA1
for hashing). Designing such algorithms is an advanced art.
(5) Even the best systems can be problematic for some customers
so think ahead how you will help them. If a customer has trouble
getting their registration key in time (check in the mail, etc.),
we send them a temporary 21-day key right away while we sort out
any registration problems.
(6) Tell your story. Let people know you are a real person
who works and needs to make a living. Explain your
protection system (without giving away any secret keys).
If your scheme phones home or sends an email, inform users up
front that's what the software is about to do and give them
a way to cancel. Users are more likely to pay for software
from an honest and trustworthy developer.
Enjoy!
- Peter
I've been hesitating for a while now over broaching this subject
again, especially as it's a bit OT. However, after reading through
all the contributions to the two big threads on copy protection that
have occurred here during the past four months, I feel there's one
aspect that hasn't really been covered: guidance in first principles
for people with no experience of copy protection and little or no
knowledge of the coding techniques involved. Lots of fascinating,
tantalising stratagems, but no how-tos. This, therefore, is my
request.
Below I've outlined what I believe is the fundamental structural
paradigm for basic copy protection. (I don't need anyone writing in
to say the scheme is no good - I know it's no good, it's just a
paradigm. A teaching aid, if you like.)
FIRST RUN
1. App knows it is running for the first time, so puts up an
"Unlicensed Copy" window which invites the user to either use the
product unlicensed in limited demo mode, or enter the licence code
they've obtained (honestly, we hope). If they do the latter, then:
2. App compares the entered value with a valid value (or array of
valid values) held internally. If it gets a match, then:
3. App stores the value (or something derived from it) in a file somewhere.
4. App triggers an email message to developer registering the transaction.
5. App sets boolean variable isLicensed to YES (or sets up variables
to be used in some mathematical process).
6. App periodically queries isLicensed (or performs its maths) when
deciding whether or not to execute certain functions.
SUBSEQUENT RUNS
7. App queries file referred to in 3 (above) and retrieves value
from it (and reverse-processes it if it's a derived value). Repeats
step 2. If it gets a match, then:
8. Repeat steps 5 and 6.
Now, this seems to me the foundation on which all *basic* software
copy protection is built. What I'm humbly asking for is to have the
fundamental weak areas pointed out and explained. You'll note that I
emphasise *basic*. I'm not asking for someone to tell me how to
protect my software (I'm inexperienced, not naive), but to help me
get a grasp of the basic techniques of copy protection. For the
record, I've gathered enough from previous threads to be aware that:
a) Defeating crackers and serial pirates is impossible, and effort
expended in any attempt to do so is wasted, so
b) The best we can hope for is to avoid handing them our app on a plate, and
c) Concentrate on encouraging the "honest" to pay, which means
d) Not teasing and tormenting them with over-elaborate registration remedies.
So, apologies to those who are sick of the sight of this subject,
but can anyone help?
-Jeremy
_______________________________________________
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.