Hello,
Providing a licensing system can be difficult. There are many
approaches you can take.
On the simple end, you can use a simple algorithm with an encryption
algorithm. An example of this would be to use an int32 and every
number divisible by 13 is valid. Then encrypt the number with
Rijndael and use that as the key. Simple to generate, looks random to
the user.
More advanced, you could require some input from the user to generate
the code, via registration. In this scenario you'd have the user
register his name, and you'd issue a key that is linked to his name.
Again, using Rijndael or some other encryption algorithm would provide
the necessary key. Another way is using a hash and then requiring
some characteristics of the output. This requires you to spend a lot
of computing time finding hashes that work, but can be successful at
limiting key-generators.
For even more protection, you could use a hardware dongle, or require
per-computer activation (like Windows XP). This is best way to
prevent "casual" piracy, where a company buys 1 license, and installs
it on multiple computers.
Regardless, you should most likely develop your own algorithm. Using
a prepackaged protection system can be easier to crack because many
times most of the work has been done before for another product. To
give them to the client, you'll just need to print off one key out of
the sequence of keys available. Your CD manufacturer can give you
more details. Sometimes it's possible to have each CD have a serial
or volume encoded on it, which you can use to require a specific key.
Again, your CD manufacturer can give you more details.
Another thing you need to do are find a way to transfer the licenses
(sending a long binary or Base64 string isn't nice for users). A
packed (where the transform works on one byte at a time instead of
multiple bytes), modified (modify the output so that the 32 characters
are easy to distinguish, for instance, don't use 0 and O, I and l)
Base32 algorithm is a good way to do this.
The most important issue, no matter which scheme you use, is
providing anti-cracking measures. Ignoring this is like having a door
with an advanced digital lock, but having the actual door made of
rotten wood - an attacker will just bypass the lock and break down the
door. If your app just simply does something like this:
If CheckForLicense() Then
MessageBox.Show("Valid license!")
Else
MessageBox.Show("Invalid license!")
Return
End
It will be cracked extremely fast, even if it is obfuscated. An
attacker will simply add a breakpoint for MessageBox.Show, and then
trace the code back up to the branch. For an added bonus, they'll
jump into the CheckForLicense() and reverse engineer it and make a key
generator which will most likely work even across-versions of your
software. This can be easy in x86, and extremely easy in IL.
The use of multiple threads or processes can make debugging much
harder. As well, writing code in IL or x86 embedded in IL that's
designed to be hard to read. The CLR is very flexible and we can take
advantage of this to write very confusing code, if don't mind loosing
verifiability.
Finally, a strong obfuscator that encrypts strings and hides calls to
your code and to system code will make all your code even harder to
read. Then, an encrypted loader (where your .exe has a data section
that contains the encrypted program, and the IL inside the .exe is
just to load it up) can raise the bar very high to even get to your
IL.
If you are interested, I can help you design these features and write
code to do this. As well, I have an internal program that creates an
encrypted loader, as well as does some interesting obfuscation
techniques that have been successful in stopping the .NET debuggers
from attaching to a process and prevent ILDASM/ASM round-tripping. My
email address is (e-mail address removed).
Thanks,
-mike
MVP
