Our firm sells an offline desktop (.exe) software, we are thinking of using OTP (from hardware token like in internet banking) to stop people from copying the software without permission. Basically, each legitimate copy will have its own serial number and hardware token.

We are thinking that when the application starts up, it will show a login screen where the user is supposed to enter the OTP from the token. The token will generate OTP based on serial number, the current time, and a secure algorithm. THe application will authenticate the entered OTP. We are hoping that with this mechanism, one copy of the software will only be usable by one person (who owns the OTP).

The purpose is to stop casual users from copying the software (e.g. to friends, family). We know this isn't 100% secure, and I can think of many ways serious pirates can still copy the software illegitimately. But in this case, we are interested in stopping casual users to copy the software (e.g. to friends, family, etc.) which are normal behaviour here. Is there anything to worry about using this method. The most worrying flaw that I can think so far is that the user can manipulate the local time of the computer (this is very easy to do in Windows). Is there any reliable time-keeping in a computer that is hard to tamper with?


You cannot use a hardware token to stop piracy. You can use it to attempt to reduce piracy. If implemented correctly, the hardware token will be required to run your unmodified program.

This is of limited use because people can modify your program to remove the check for the token — basically, look for the place in the executable where it checks if (token_is_valid()) … and change that to if (!token_is_valid()). Unless you take special precautions, it will be easy to find that place with a debugger. Of course, most of your users probably lack the technical competence to do this, but all it takes is one who will then make the modified program available for download.

If you want to protect your program seriously, you need to obfuscate the test for the token. The more effort you put in obfuscation, the more effort a cracker will need to spend to make the program usable without the token. The rise in development costs to make worthwhile obfuscation is huge. You can't just apply an off-the-shelf obfuscator to your compiled code: for every off-the-shelf obfuscator, there is a corresponding deobfuscator.

A direct side effect of adding copy protection measures to a program is that it creates an incentive for people to break it. Not just people who want to copy your program, but also legitimate users whose system is incompatible with your copy protection measures, or because they find your copy protection measures inconvenient — for example because they want to use your software on their laptop on the go and they don't want to carry yet another piece of junk, or simply because they find it tedious to have to enter a code every time they start the program. This will result in loss of business as some potential customers go for the cracked version because it's easier to use others just give up on your software.

If you really want to use a copy protection token, relying on the time is not necessary. You can make it a challenge-response system instead: your application displays a challenge code, and the device responds with corresponding reply. For a better user experience, use a USB-connected token instead of one where the user must relay the information between the token and the computer (but note that this replaces the UX nightmare by administration nightmares, as a connected token may not always be easy to reach from program running on unprivileged accounts, inside virtual machines, …).


It is almost impossible to prevent a software program from being pirated, but to answer your question, if the user has no advanced computer skills you may be able to achieve some level of protection.

To prevent manipulating of the local time, each time your software starts and at a certain period of time, you should check system time and store it in a encrypted file. If the time you have read is before the last save time, then the date has been changed. Moreover, if the file is missing then someone tried to tamper with your application.

This is just a minor protection mechanism. More advanced protection mechanisms include:

  • Attempting to detect a debugger attached to the program

  • Encrypting parts of the code and decrypting them on runtime, use per-function signatures

  • Have other threads check this signatures

  • Analyze statistical information such as execution time, to detect attached debuggers

You can also have a look at SafeNet HASP products. Their purpose is to protect software from unauthorized use. Your software is wrapped in multiple layers of HASP software and a hardware token is needed for the application to run.

More details here: http://www.safenet-inc.com/products/software-rights-management/sentinel-hasp-hardware-keys/

  • 2
    "If the time you have read is before the last save time, then the date has been changed." Two things. Daylight saving time. Or people travelling (especially westwards) and setting their computer's clock to the local time of their destination. – a CVn Jan 6 '13 at 13:51
  • You are right. This kind of protection has many flaws and it is not the best solution. Of course you may implement certain exceptions, for Daylight saving or small date changes, but the this would still have problems. – Dinu S Jan 6 '13 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.