>Sorry if this is the wrong group, but it seems that many folks here
>have probably had to deal with creating a scheme to enforce the
>registration of their app. I can't seem to find any good tutorials
>or info on producing/validating serial numbers for my end users.
>I suspect the whole thing revolves around checksums, but I know
>nothing about this area of "marketing" software. How does somebody
>go about protecting their product with serial numbers? Web sites,
>FAQs, Books, or examples appreciated. Thanx!
I haven't really seen any FAQs on the subject.
There are a few ways to implement some sort of 'registration
key' or 'checksum' for application registration. Note that
the purpose of a registration key is *not* to prevent
piracy--as a pirate can easily retransmit the key and other
registration codes necessary to allow the application to
run. Even complex registration schemes which use checksum
validation of certain key properties of the machine can
be hacked by the determined pirate.
No, registration schemes are for discouraging "casual"
piracy--that is, to encourage those who would really want
an application to actually register the application. It
also is used for preventing someone from mindlessly
distributing the application around.
There are a couple of ways to create a registration system.
One easy mechanism which is used more often than not is to
have your application use a fixed key code or other hidden
"trick" for unlocking the application--for example, you
could have an application unlock when someone enters a fixed
code like "12345".
A slightly more complex mechanism is to create a checksum
based on a property like someone's name. One app I've
developed, World Calendar, uses exactly this scheme: I
create an 8-digit hex 'checksum' based on the person's
name; to unlock, the person enters his name and the 8-digit
key, and an internal routine matches the 8-digit key
against the key expected from the person's name. (Kagi
supports this sort of thing; you should contact the
folks at Kagi for more information.)
Other alternatives include generating a 'key-response'
mechanism, where you have the program generate a random
number based on things like the size of the hard disk or
the MAC Ethernet hardware code, and they send the key to
you--then you generate a "response" which the application
expects to unlock the program. Adobe's Type On Demand
system uses a system like this, where you call Adobe
with the application's "code", and they read off a
response which unlocks the font you want.
The easiest way to generate a key, by the way, is to use
a combinations of rotate and XOR; for example, to generate
a random key based on a person's name, you could do the
following:
key = constant_seed_value;
for each char 'c' in 'name'
rotate 'key' by one bit left.
'key' = 'key' xor 'c'
next char
This has the advantage of being hard to decipher unless
you know the initial name and seed value--and given the
name, you can reverse the algorithm and get the seed
value back.
(Variants include rotating right instead of left, and
rotating more than one bit.)
Note that you should store the fact that the application
is registered somewhere other than in the application
itself. Aside from the dangers of self-modifying code,
it makes it harder for someone to pirate your application
than dragging and dropping the unlocked app onto a
floppy disk.
Well, that's enough for now; hopefully this will help.
And as I noted before, the primary purpose of having a
key sceme is to help remind honest people to register,
not to prevent crooks. So your key scheme could be as
simple as telling the person to shift-click the 'cancel'
key in a dialog box or some other hidden mechanism.
By the way, I have some code for getting the Ethernet
MAC address which randomly generates a substitute if
such a MAC address is not available on my web site at
http://www.pandawave.com/uuidlib/
- Bill Woody
The PandaWave