Activation System
The Activation System is a major part of the Web License Manager and VMProtect itself. It allows vendor to perform a two-steps registration process that makes lots of good things possible. Time trials, better licenses control, piracy prevention – to name a few. Activation System is a VMProtect API and a Web License Manager module working together. Integration is relatively easy, especially if you already use VMProtect licensing system.
Trial Mode
The first run
When the user installs and runs the application the first time, the application should start the trial counter. Compared with the other protectors, VMProtect doesn’t store the trial marks or counters in the system, where they can be found easily. Instead, VMProtect requests a temporary serial number from the activation server. So you need to call the VMProtectActivateLicense() API to start the trial and you need the activation code for that API.
The activation code should be generated once, manually and stored in the application. You need to set unlimited number of activations for that code and also set it to expire after 30 days or whatever you’d like. You may also set other fields, like user data to provide some specific information to the application, while it is in the trial mode.
To create the activation code, go to the Web License Manager and create a product first (it if hasn’t been created yet):
Then add a “mode” to the product that will represent the trial serial numbers. Do not forget to set the “HWID” and “Expire” options, or the trial period will never end:
Then, go to the activation codes page and create a code for that mode.
After clicking the “Save” button you’ll see the trial activation code at the right column:
At the first run, the protected application checks the registry or settings file for the stored serial number. If it is not found, the application needs to start the trial period, so it shows an information window to the user and then connects the activation server for the serial number using the built-in activation code. The server returns the serial number and the application stores it to the registry to prevent the same amount of work at the next run.
The next runs
At the next run (or after the above steps at the first run) the application can finally read a stored serial number from the registry. It then can pass it to the standard VMProtectSetSerialNumber() API to initialize the licensing module. The important step is to analyze the return code and check that the serial number has not expired yet.
The application can also read the expiration date from the serial number and inform the user about the number of days last. When the trial period is over, VMProtectSetSerialNumber() API will reject the serial number and the user will not be able to get the new one from the activation server, as his hardware identifier is already stored there. So we come to the next essential step – the ordering.
Ordering
The user buys a new activation code, not the serial number. There are several ways to implement this with VMProtect and Web License Manager. The first one is a little bit more complex to setup, but it is worth the time spent. The second one is easier to setup, but has some cons.
Completely Automatic Solution
You need to setup the Web License Manager to work with your payment processing service, so it calls WebLM at every order. This can be done quite easily as most of the e-commerce providers allows vendors to setup keygens on their sites. So you need to setup Web License Manager as a key generator for your e-commerce provider.
The first thing you need is to create a special “full version” mode for the product that doesn’t expire:
Then click “Save”, locate the mode under the product in the list and click the “Keygen URL” link. You’ll see the keygen url form that allows to generate generator links for various e-commerce providers:
When the user pays the money, your payment processing service calls Web License Manager with all the order data and it generates a very special activation code just for that user. This code is sent to e-commerce provider and then forwarded to the customer. As the activation code is quite short, compared to the serial number, the user can easily write it down, remember or just enter without errors.
When the application gets a new activation code from the user, it does the same thing as at the first run with trial activation. But this time the Web License Manager generates a fully-functional serial number without any limitations (or as the vendor configured this). The serial number then is passed to the VMProtectSetSerialNumber() API and the application becomes registered.
Another Way
Alternatively, you may generate a set of activation codes in the Web License Manager and then import them as a list to the e-commerce provider. They usually allow vendors to provide a list of their own serial numbers. In that case you don’t need to link your payment processing service with Web License Manager, as the service will send the customer one of the pre-generated activation codes.
The rest is absolutely the same as above. The application calls the activation API, activation server knows the code and send a fully-functional serial number back.
Although being easier to setup, this method doesn’t “link” the activation code (and the serial number) to the order, so you can’t tell which code and serial number belongs to the customer.
However, the methods can be used together, for example to provide a set of activation codes to the resellers, while the main store uses the first approach.
Deactivation
If the user decides to install the software on another computer, he or she needs to activate it again. The previous serial number will not work on the new computer (with the default settings), as it has a different hardware identifier. It is up to vendor – to allow users to install the software on several computers and the vendor enters the number of activations as a parameter of the activation code generator.
If the user reaches the activation limit, he may deactivate the software on the previous computer to decrease the activation counter on the server, so the software can be activated on another computer.
Deactivation automatically bans the deactivated serial number. If the user decide to activate the software on that computer again, he will get the new serial number. It is essential to sync the local VMProtect project with the remote one to keep the list of banned serial numbers up to date. In that case the new version of the software will not accept the old deactivated serial number.
Offline mode
All the above assume that the computer is online and can call the activation server directly. However, it is not necessary as sometimes the user may now want to let the computer go online for some reasons. For that case the activation module provides a special “offline” API that generates activation/deactivation data and then pass them to the user to do the manual activation.
So, if the computer is offline, the VMProtectActivateLicense() API returns the ACTIVATION_NO_CONNECTION code. In that case the application needs to call the VMProtectGetOfflineActivationString() API and then show the user the activation data for offline activation. The user then needs to go online at another computer and enter the data to the activation form on the server (usually located at http://server/offline.php). After entering the data to the form, the user will get a serial number that he needs to enter back to the application.
The same works for deactivation. The offline form accepts both activation and deactivation data.