Copyprotection / Software key mechanisms

• 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 beginning.


• 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 on that.


• 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 at once.


• 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.