Copyprotection / Software key mechanisms
These are some random thoughts I had to make crackers life a bit more challenging.
I used some of those ideas in my own software :-)
Update:Check out my Blog post with some new insights.
- If you are writing your program in some kind of interpreted language
like Java or VisualBasic, be sure to know about the latest decompilers.
- If you don't want anybody to be able to write a keygenerator for your
program, look in the latest cryptography literature. Digital signatures
can make your keys unforgeable. Look for eliptic curves cryptography.
There are also several free implementation on the net, which you can use
in your program.
- If you read system-data like the clock (maybe you have a 30-day trial
version) or the username, be sure to doublecheck the information you get.
Is the last time, the program run, before or equal to the current time?
Is the username, which GetUserName returns, equals the USERNAME-environment variable?
Is the creation-time of the system-registry backup equal to todays date?
- Have the key checked several times in your program and not only at the
- Have several different parts of the key, which are checked by different
routines at a different time.
- Don't take direct action, if you find a faulty key. Just wait a week
or two and generate some obscure crash of the software (of course only,
if the initial check at the program start passed). Hackers hate that...
Probably the hacker has not enough knowledge to understand, what your
software is doing at all (think of an accounting-software). What, if a faulty
key results in buggy calculations?
- Calculate a checksum of your program. Have some calculations depend
- DO NOT USE A LIBRARY, which you link to all your programms or DLL's.
If the code is the same all the time, it's easy to find. Write several, different
routines, which check the key in many, different ways. Spread them through
your code. Use define-macros. Use inline-functions. Have a quick-check
in several important routines.
- Use time-dependant (or random, or system-dependant) checks. Check only
some part of the key.
- If you have functionality that is only available in a registered
or specially licensed version, then move that functionality into a DLL
and load the DLL only when needed. In that case you could also encrypt the DLL file
with a symmetric cypher and decrypt it with the proper authorisation key before
loading it. Of course the decryption-key is part of the registration key.
This means that a cracker will not have access to the functionality without one
valid key. If the cypher is secure (use AES in CBC or CFB mode) and the
key long enough (at least 64 bits), then the cracker has a problem without
one real, valid key. If you are selling several additional packages, it will
be pretty hard to deliver a " general key " that unlocks all the features
- If you are using keys to unlock functionality of your program
and are worried about people sharing those keys, try the following: make the
key only valid for a month or so (once unlocked, the program stays unlocked, though).
Should the key be shared, it won't work after a month. You can give your
customers a special web-page from which they can obtain another key should
they ever have to reinstall the program. The web-page could check some
credentials such as the customers email-address that was used to register.