Question regarding product activation scheme

Question

The typical product activation scheme is as follows

1. A unique serial no. is assigned to user
2. A unique hardware id is generated for the user's machine.

On giving this info to the vendor, the vendor issues an activation code.

I would like to know how the activation code is generated and what are its contents. Also what is the general scheme once the activation code is entered in the application on users pc, like how it is decoded, stored, checked next time?

Thanks

Answer 1

A really simple way of doing this is compiling a list of the PC's relevant hardware into a string and then running an MD5 hash over it. So your string would for e.g. contain

"Pentium 4 Dual Core 3.8 GHz, HDD1: 320GB"

etc There are many free implementations of MD5 hashing in almost every language, you can do a Google search for it.

You don't say what platform you are targeting, but if you are using Windows, you can obtain the PC's hardware config by querying WMI or using Windows API calls. For example the physical memory class to look at in WMI is Win32_PhysicalMemory.

When the software is first installed, this hash is compiled, and then sent to the activation server, which sends back some corresponding code that will only match to that hash. A really simple / useless example - let's say the hardware hash is 123, and the check algorithm is that all the digits should be 9 after the hardware hash and activation code are added, the activation server would return 876. The program would add the 2 codes together and get 999, then unlock it for use.

Periodically the program will re-create the hardware hash, add it to the activation code (in my super simple example only), and make sure they still add up. If they don't the product might lock itself and insist on re-activation.

However: I highly recommend you don't use this method of copy protection. Why not?

• Any time the user upgrades their hardware, re-installs their PC, etc, you will probably incur support costs assisting them to re-activate the software, and inconveniences the user.
• If you ever discontinue your activation servers, the product, or close your company, you effectively shut down access for the people who paid to use the product.
• This is pretty much turning the user's PC into a hardware dongle - which sounds like a good idea on the surface, but discourages users from buying the software

Rather I would suggest you use a hash of the registering party's name or company name, and embed that in the program in such a way that it is obvious that the program is registered to them. Yes, this technically allows them to copy the software more easily.

Bottom line is - if your software is really valuable to many people, someone will bypass your copy protection scheme, no matter how convoluted it is. Using product activation based on the hardware configuration will only aggravate the one group of people you really want to do business with - those who are basically honest and want to use your product legally. The folks who don't give a stuff about legal software will use the version where your activation scheme has been cracked.

I personally despise buying any product where there is no guarantee that I will be able to use it if I change my PC or the company shuts down. It's kind of like the recent case where people bought George Orwell's 1984 for their Kindles, and then when there was a copyright dispute, Amazon remotely deleted all the copies of this book that people had bought.

Just my 2c.

Answer 2

Like Michael (Todd) commented, the methods or schemes vary with different vendors. If it's really standard, it's probably easier to 'hack', yea?

I assume your ultimate aim is to protect your software from unauthorized use?

Here are a couple of related SO posts:
How do you protect your software from illegal distribution?
Methods to stop Software Piracy ?

UPDATE:
To answer more directly to the OP's question:

I would like to know how the activation code is generated and what are its contents?
@: Can be a proprietary hashing/encryption of serial no. mashed up with user/product/date information or virtually anything else.

Also what is the general scheme once the activation code is entered in the application on users pc, like how it is decoded, stored, checked next time?
@: The software probably has the some algorithm inside that can make sense of this code to at least check for validity. Can be stored as a file, in the registry or even embedded within existing file etc etc.

Answer 3

I'm assuming you asked the question, because you want to implement something similar yourself.

Here I will outline a scheme that can be used to help protect the legitimacy of purchased software. This helps to protect the company from piracy and helps to keep the clients' valuable purchases legitimate and relatively easy to register.

This scheme works by tracking three separate data elements: one auto-generated, one entered by the user, and one calculated from those two. When the product is not activated it could either run with a reduced set of features or simply not run at all.

The procedure involves communication with a website, but when the website is unavailable, there are alternative mechanisms so that the user can still use the software without getting frustrated over licensing issues. Methodology

The software utilizes three basic data elements:

• [IC] Installation code: An auto-generated code; this could be anything that is generated by the particular installation and is unique to the installation. It will change when the software is reinstalled and does not depend on who is installing it. In the past some vendors have used a hardware hash, but it could just as well be a randomly generated code that is stored for retrieval at each instantiation. Deleting the code from storage is essentially the same as uninstalling the software.
• [UI] User ID: A uniqe identifier for the registered; you could refer to this as an unlock code or a client or company code, or a serial number. It will uniquely identify who has purchased this particular installation.
• [HASH] The hash: A calculated value; this final piece of the authentication is what tells the software that it is legitimately registered and good to go. It should be derivable from the other two parts and stored somewhere, either in the file system or in the Windows registry or elsewhere.

Logic flow

In pseudo code, the software runs through the following procedure:

begin:
  load IC
  if not IC: IC = generateIC
  load UI
  if not UI: UI = promptUser
testHash:
  load HASH
  if HASH=hash(IC,UI): goto valid
  HASH = activateLicense()
  if not HASH=hash(IC,UI): goto invalid    
valid:
  REV = revokeLicense()
  if REV: goto invalid
  done : run software
invalid:
  done : do not run software

generateIC:
  IC = some unique identifier
  store IC
  return IC
promptUser:
  UI = get id from user input
  store UI
  return UI
activateLicense:
  HASH = wwwResponse('activationRequest')
  store HASH
  return HASH
revokeLicense:
  REV = wwwResponse('checkIfRevoked')
  if REV: erase HASH
  return REV

The pseudo code also involves an optional fourth element:

• [REV] An indication of a revoked license: the company software company could track the number of software activations and revoke access to abusive users. This does not need to be stored and will only be retrievable if there is an available connection to the www.

Failure to connect to the website would only mean that the state of the license will not change. If the software cannot directly connect to the website, then an alterantive procedure could be available from a web enable point where the user enters their IC and UI into a browser and the browser emails them a HASH which they can manually enter into the software. This is only slightly more involved, but still lets the user do this by themselves with an important factor being that they must enter a valid email if they wish to receive the hash code that will be emailed to them.

It's not hack-proof or undefeatable, but it does serve to protect both parties, in a reasonable way that does not lead to frustration. The actual mechanisms involved should be closely guarded company secrets.

Note:

It doesn't really matter in this scheme whether IC is a hash on the computer's hardware or if it is just some randomly generated key. All that will happen when it changes is that the software will re-register itself, which might not be a problem if the machine it is on is connected to the internet, or might be a slight inconvenience if user interaction is once again required, but as stated above, this part can still be implemented as a self-service feature on the site. It's up to the software company if they want to count number of activations or track other info.