Get Demo
  • Windows
  • MacOS
  • Linux

Licensing API functions

The licensing system API is an integral part of VMProtect API and its SDK. API allows you to specify a serial number and retrieve all information about it: whether it suits the program or not, is the serial number expired, the name this product is registered to and so on. Also, the API provides a hardware identifier of the computer the program runs on.

VMProtectSetSerialNumber

This function loads a serial number to the licensing system. Call syntax:

int VMProtectSetSerialNumber(const char *SerialNumber);

The input SerialNumber parameter must contain a pointer to a null-terminated string (‘\0′) containing a base-64 encoded serial number. The function returns a bit mask of serial number status flags, the same as the one VMProtectGetSerialNumberState() returns. You can read more about flags below. The serial number is “good” if the function returned 0.

VMProtectGetSerialNumberState

This function returns status flags for the serial number specified by a call to VMProtectSetSerialNumber().

int VMProtectGetSerialNumberState();

If at least one flag is set, there is a problem with the serial number. The program shouldn’t work if at least one bit is set. The detailed description of flags and their values is listed in the table below:

Flag Value Description
SERIAL_STATE_FLAG_CORRUPTED 0x01 The licensing system is corrupted. Possible reasons are: incorrect setup of the protection project, cracking attempt.
SERIAL_STATE_FLAG_INVALID 0x02 The serial number is incorrect. The flag is set if the licensing system cannot decrypt the serial number.
SERIAL_STATE_FLAG_BLACKLISTED 0x04 The serial number matches the product, but is black listed in VMProtect.
SERIAL_STATE_FLAG_DATE_EXPIRED 0x08 The serial number is expired. You can obtain the detailed information about the expiration date by calling VMProtectGetSerialNumberData()
SERIAL_STATE_FLAG_RUNNING_TIME_OVER 0x10 Operating time of the program is depleted. You can obtain the detailed information about the operating time of the program by calling VMProtectGetSerialNumberData()
SERIAL_STATE_FLAG_BAD_HWID 0x20 Hardware identifier does not match the hardware identifier prescribed in the key.
SERIAL_STATE_FLAG_MAX_BUILD_EXPIRED 0x40 The serial number does not match the current version of the protected program. You can obtain the maximum build date of the program this serial number matches by calling VMProtectGetSerialNumberData().

VMProtectGetSerialNumberData

This function obtains information about contents of the serial number acquired with a call to VMProtectSetSerialNumber(). Call syntax:

bool VMProtectGetSerialNumberData(VMProtectSerialNumberData *Data, int Size);

The first parameter is a pointer to the VMProtectSerialNumberData structure, where all necessary information will be written to. The second parameter is the size of the structure passed in the first parameter. It is required to control the structure’s format. The function returns FALSE if the licensing system is corrupted (see the SERIAL_STATE_FLAG_CORRUPTED flag), if a zero address of the structure is provided or if the passed size of the structure is incorrect. In all other cases, the function returns TRUE and records all information about the serial number to the provided address. Below are the elements of the structure:

Element Type Description
nState int A bit flag mask indicating the status of a key. Similar to the one returned by VMProtectGetSerialNumberState().
wUserName wchar_t[256] The name of a customer in UNICODE, null-terminated.
wEMail wchar_t[256] The e-Mail of a customer in UNICODE, null-terminated.
dtExpire VMProtectDate The key expiration date. The format of the VMProtectDate structure is described below.
dtMaxBuild VMProtectDate The maximum product build date the given key can work with. The format of the VMProtectDate structure is described below.
bRunningTime int The amount of minutes the program will work (maximum duration of a session). The value in minutes counts from the moment the program starts.
nUserDataLength unsigned char The length of user data in the bUserData field.
bUserData unsigned char[255] User data put into the key. The actual number of bytes is specified in nUserDataLength.

VMProtectDate

The structure is a compact representation of date. Its fields are listed in the table below:

Element Type Description
wYear unsigned short Year.
bMonth unsigned char Month, starts from 1.
bDay unsigned char Day, starts from 1.

VMProtectGetCurrentHWID

This function obtains a hardware identifier of the PC the program is working on. Call syntax:

int VMProtectGetCurrentHWID(char * HWID, int Size);

The first parameter is a pointer to a memory area where the identifier is written to. The second parameter is the size of this area. The function returns the number of bytes written inclusive of the trailing zero byte (‘\0′). If NULL is provided in the first parameter, the function returns the number of bytes required to store the hardware identifier. Here is the correct way to use the function:

int nSize = VMProtectGetCurrentHWID(NULL, 0); // get the required buffer size
char *pBuf = new char[nSize]; // allocate memory for the buffer
VMProtectGetCurrentHWID(pBuf, nSize); // obtain the identifier
// use the identifier
delete [] pBuf; // release memory

Step 2.5: Locking the code to a serial number

One of the most common ways to crack programs is to locate the place where the serial number is checked and the nearby conditional jump that follows it. If the serial number is correct, the execution of the program goes one way, if not – the other way. A hacker locates this jump and replaces it with a jump to the “correct” way. Let’s “crack” our test program using this technique. Directly in the source code, of course. Let’s “switch off” our conditional jump:

char *serial = read_serial("serial.txt");
int res = VMProtectSetSerialNumber(serial);
delete [] serial;
if (false && res)
{

Now, our program accepts any serial number and works normally. Of course, if the file is protected with VMProtect, even an experienced hacker would spend months to locate and modify the conditional jump as we did it. And taking into account the program check the serial number multiple times and under different conditions, even such a simple check is quite secure. But let’s go further.

Locking the code to a serial number

The licensing system of VMProtect allows you to lock the code of one or more functions to a serial number so, that they will not work without the correct serial number provided. the body of the function is virtualized, then encrypted and can only be decrypted with the correct serial number. This means, even if a hacker finds and fixes the conditional jump in the serial number check, functions locked to the serial number still will not work. Let’s try this. In the “Functions” section choose the foo() function and at the right panel change the “Lock to Serial Number” option to “Yes”.

Then, protect the application. Since, we already “hacked” it, put an arbitrary text into the serial.txt file and run the application. The following text appears in the console:

C:\test>dummy_app.vmp.exe
serial number is correct, calling foo()

This means, the hacker “fixed” the conditional jump, and the program runs on the “correct” way. But when the foo() is invoked, the program displays a message:

Since we locked the foo() function to the serial number, and the hacker does not have it, an attempt to decrypt the code of the function resulted in malfunction and inability to continue execution of the program. When “OK” is pressed, the program shuts down and the “done” message is never displayed in the console.

What should be locked to a serial number?

It makes sense to lock to a serial number a function that should only run in the registered version of the program. Since locking requires virtualization, you should take into account some loss of performance. For instance, if a text editor does not allow saving result in a demo-version, you can lock the save document function to a serial number. If during its operation this function calls other functions, it is not necessary to lock them too, as they won’t be of any use without the main function.

You should also remember that invoking the locked function without the serial number leads to program shut down, without a chance to save result of the work. that is why you should thoroughly test the application to make sure it doesn’t calls such functions in the trial mode. In the above example, the text editor must disable the “Save” command in the demo mode and do not react on Ctrl+S shortcut as well. Of course, it also shouldn’t ask to save the document on exit too. If you don’t pay attention to this, a user may be disappointed with your “buggy” demo-version.

Locking to a serial number and invalid serial numbers

When the VMProtectSetSerialNumber() function is invoked, the licensing module checks the serial number passed to this function. Encrypted fragments of the code are only executed if the serial number was absolutely correct at the moment of check – not blacklisted, with the correct hardware identifier, not expired and so on. In this case all encrypted procedures are executed until the application is closed, or VMProtectSetSerialNumber() is invoked again.

Some limitations can “trigger” during execution of the program: for example, the operating time of the program may expire or the serial number expiration date comes. In this case the licensing module still encrypts and executes functions locked to the serial number. This is so, because it is hard for the protected application to detect the moment those limitations trigger and change the behaviour accordingly (block corresponding menu items and so on). If the licensing module suddenly stops execution of the code fragments that are locked to the serial number, this will very likely lead to malfunction of the application. That is why the decision is made when a serial number is set, and the corresponding execution mode is selected.

Step 2.4: Testing the results

Serial number expiration date

Let’s create another serial number with a certain expiration date. For example, 2005. This date has already passed and therefore our serial number must be incorrect. Switch to the “Licenses” section and click the “Add license” button on the toolbar. In the “Add license” dialog window enable the “Expiration date” option and specify September 30, 2005. Create the serial number, copy it and paste to serial.txt, then run the program:

C:\test>dummy_app.vmp.exe
serial number is bad
state = SERIAL_STATE_FLAG_DATE_EXPIRED

the licensing module returned the “serial number is expired” flag. Now, put the working serial number back to the serial.txt file and make sure the licensing module accepts it perfectly.

C:\test>dummy_app.vmp.exe
serial number is correct, calling foo()
I'm foo
done

Adding a serial number to the black list

Let’s imagine our “good” serial number has leaked to the Internet and is compromised now. We need to block it so that it will not work in future versions of the program. To do this, select the serial number in the list and set the “Blocked” property in the main panel to “Yes”. For now, the serial number is not yet blocked, but when you protect the file again, the application will not accept this number any more. Let’s make sure this is really so. If we run our program now, it should accept the blocked serial number without any problems, because this is the old version that knows nothing about the blocked number:

C:\test>dummy_app.vmp.exe
serial number is correct, calling foo()
I'm foo
done

Now we make a copy of our program and name it as “dummy_app1.vmp.exe”, then open VMProtect and protect the application again. Then run this new version:

C:\test>dummy_app.vmp.exe
serial number is bad
state = SERIAL_STATE_FLAG_BLACKLISTED

And the old version again, for comparison:

C:\test>dummy_app1.vmp.exe
serial number is correct, calling foo()
I'm foo
done

The older version doesn’t know about the blocked serial number and works as before.

On the next step we will try to lock the code to a serial number. But before we proceed, unblock the serial number and reapply protection in VMProtect to the application to make it accept this serial number again. Or simply create a new license.

Step 2.3: First start of the protected product

The licensing system is initialized, so let’s try to compile the VMProtect project and run the protected file. After running it from the command line we will receive the following message:

C:\test>dummy_app.vmp.exe
serial number is bad
state = SERIAL_STATE_FLAG_INVALID

If you run depends.exe and can see that our protected executable file doesn’t use the VMProtectSDK.dll any more. This means the licensing module is already built into the program. You can also review the list of used DLL from VMProtect, in the “Details | Imports” section.

Our protected program reads a serial number from the serial.txt file. Since there is no such file yet, the licensing module receives an empty serial number that is interpreted as incorrect. Now we switch to the “Licenses” section and generate a serial number. This procedure is described here in all details, and now we merely create a simple serial number without any limitations.

Then, we copy the serial number (select the “Serial number” field in the license properties and precc Ctrl+C), create a file named serial.txt in the same folder as the protected application, and paste the copied number there. Now, if we run our application we will see this:

C:\test>dummy_app.vmp.exe
serial number is correct, calling foo()
I'm foo
done

The licensing system checked the serial number and found it correct.

Step 2.2: Creating a VMProtect protection project

Now, as our test app is ready, compiled and has an assigned MAP-file in the same folder, we can run VMProtect Ultimate and open the executable file. We need to add two functions to the project: _main (this is how Visual Studio renamed our main()) and foo(). Both functions can be seen in the list of functions in the “Functions” section in VMProtect.

Then, we need to initialize the licensing system. Open the "Licenses" section and create a pair of keys with the length of 2048 bit.

Step 2.1: Creating a new protected application

At the first stage we made several simple apps to test the API of the licensing system. Now, on the second stage we’ll create just one application. It will also be a console app with the foo() function working only in the registered version. Here is the code of our test application:

#include <windows.h>
#include <stdio.h>
#include "VMProtectSDK.h"
#define PRINT_HELPER(state, flag) if (state & flag) printf("%s ", #flag)
void print_state(INT state)
{
        if (state == 0)
        {
                printf("state = 0\n");
                return;
        }
        printf("state = ");
        PRINT_HELPER(state, SERIAL_STATE_FLAG_CORRUPTED);
        PRINT_HELPER(state, SERIAL_STATE_FLAG_INVALID);
        PRINT_HELPER(state, SERIAL_STATE_FLAG_BLACKLISTED);
        PRINT_HELPER(state, SERIAL_STATE_FLAG_DATE_EXPIRED);
        PRINT_HELPER(state, SERIAL_STATE_FLAG_RUNNING_TIME_OVER);
        PRINT_HELPER(state, SERIAL_STATE_FLAG_BAD_HWID);
        PRINT_HELPER(state, SERIAL_STATE_FLAG_MAX_BUILD_EXPIRED);
        printf("\n");
}
char *read_serial(const char *fname)
{
        FILE *f;
        if (0 != fopen_s(&f, fname, "rb")) return NULL;
        fseek(f, 0, SEEK_END);
        int s = ftell(f);
        fseek(f, 0, SEEK_SET);
        char *buf = new char[s + 1];
        fread(buf, s, 1, f);
        buf[s] = 0;
        fclose(f);
        return buf;
}
// The foo() method is very short, but we need it to be an individual function
// so we asked the compiler to not compile it inline
__declspec(noinline) void foo()
{
        printf("I'm foo!\n");
}
int main(int argc, char **argv)
{
        char *serial = read_serial("serial.txt");
        int res = VMProtectSetSerialNumber(serial);
        delete [] serial;
        if (res)
        {
                printf("serial number is bad\n");
                print_state(res);
                return 0;
        }
        printf("serial number is correct, calling foo()\n");
        foo();
        printf("done\n");
        return 0;
}

Compile the program without the debug information, but in the linker settings we enable creating of the MAP-file – we will need it to work with VMProtect. After we run the program, we should see the following text:

serial number is bad
state = SERIAL_STATE_FLAG_INVALID

Currently, the licensing system still works in the test mode, because the file wasn’t processed by VMProtect and doesn’t contain a licensing module in it.

Step 1.10: User data

A serial number can hold up to 255 bytes of arbitrary data that the licensing system passes to the program as they are. The data can hold any additional information about the sale, data required for operation of the full version or something else. Let’s modify our main() function so that it would read data from a serial number and display them on the screen:

int main(int argc, char **argv)
{
        char *serial = "Xserialnumber";
        int res = VMProtectSetSerialNumber(serial);
        print_state(res);
        if (res) return 0;
        VMProtectSerialNumberData sd = {0};
        VMProtectGetSerialNumberData(&sd, sizeof(sd));
        printf("Serial number has %d byte(s) of data\n", sd.nUserDataLength);
        for (int i = 0; i < sd.nUserDataLength; i++)
                printf("%02X ", sd.bUserData[i]);
        printf("\n");
        return 0;
}

We also reduce the Ini-file to this:

[TestLicense]
AcceptedSerialNumber=Xserialnumber 

Now, we run the program and make sure our serial number works well, but doesn’t contain any dаta:

state = 0
Serial number has 0 byte(s) of data

To add new user data into the serial number, we need to create the UserData variable in the ini-file and assign data to it in the HEX format. Symbols must go in pairs, that is the length of a line must be a multiple of 2. Like this:

UserData=010203A0B0C0D0E0

In this case, if we runthe program we will receive the following result:

state = 0
Serial number has 8 byte(s) of data
01 02 03 A0 B0 C0 D0 E0

Step 1.9: Hardware lock

Receiving a hardware identifier

Before we lock to hardware, we must receive a hardware identifier. The identifier is put into a serial number, and when the number is passed to the licensing system, it checks if identifiers match. So, first we need to receive the identifier of our hardware. Let’s reduce the main() function to the bare minimum:

int main(int argc, char **argv)
{
        int nSize = VMProtectGetCurrentHWID(NULL, 0);
        char *buf = new char[nSize];
        VMProtectGetCurrentHWID(buf, nSize);
        printf("HWID: %s\n", buf);
        delete [] buf;
        return 0;
}

By running the program, we receive a default test hardware identifier:

HWID: myhwid

To change the identifier, add the following line to the ini-file:

MyHWID=test

If we run the program afterwards, we can see the system thinks “test” is a hardware identifier of our PC:

HWID: test

!Important

The program will display the real hardware identifier only after it is processed with VMProtect.

Hardware-locked serial number

To lock our test serial number to hardware, we should add one more line to the ini-file. This time we define the identifier that is “put into” the serial number:

KeyHWID=test

Then we complicate main() back a bit. Now it will pass a serial number and analyze the result it gets:

int main(int argc, char **argv)
{
        int nSize = VMProtectGetCurrentHWID(NULL, 0);
        char *buf = new char[nSize];
        VMProtectGetCurrentHWID(buf, nSize);
        printf("HWID: %s\n", buf);
        delete [] buf;
        char *serial = "Xserialnumber";
        int res = VMProtectSetSerialNumber(serial);
        print_state(res);
        return 0;
}

After running the code we will see the following result:

HWID: test
state = SERIAL_STATE_SUCCESS

The licensing system has compared the current hardware identifier with the one written in the serial number. Identifiers are equal, so the VMProtectSetSerialNumber() function returned SERIAL_STATE_SUCCESS – the serial number matches.

Now let’s try to “run” our program on another hardware. We simply change the value of the MyHWID parameter in the ini-file from “test” to “new test”. Run the program again:

HWID: new test
state = SERIAL_STATE_FLAG_BAD_HWID

This time the licensing system returned the SERIAL_STATE_FLAG_BAD_HWID flag, which means the real hardware identifier and the one stored in the serial number are not matching. The current identifier we see on the screen is “new test”, while the serial number holds “test”. If we change the KeyHWID parameter in the ini-file to “new test” we can make our serial number work on this “hardware” too.

Step 1.8: Serial numbers in the black list

A serial number marked in VMProtect as “blocked” should not be accepted by the licensing system. When you will rebuild your application next time, VMProtect will add the hash of blacklisted serial numbers to the protected application. As a result, the licensing system of the application will decline these serial numbers in the future.

Firstly, lets minimize the contents of the main() function:

int main(int argc, char **argv)
{
        char *serial = "Xserialnumber"; // we set the serial number directly in the code, for simplicity
        int res = VMProtectSetSerialNumber(serial);
        print_state(res);
        return 0;
}

Now, run the program and make sure the licensing system do accept our serial number:

state = 0

Now, add this serial number to the black list of the licensing system. Add the following line to the ini-file:

BlackListedSerialNumber=Xserialnumber

And run the program again:

state = SERIAL_STATE_FLAG_BLACKLISTED

Should we inform a user that the serial number he or she enters is blacklisted? It is up to you. You can simply tell the serial number is incorrect or inform the user that the key is compromised. The licensing system simply informs the program about the fact of using the blacklisted serial number.

Step 1.7: Limiting the free upgrades period

How it works

When VMProtect protects an application it records the date. The licensing system treats this date as a build date of the application. And you can put into a serial number the maximum build date this serial number can work with. Therefore, if you put the current date plus one year to the serial number, it will work with all versions of your programs you will be releasing in a year. A version you release one year and a day after will not work with this serial number, and a user will have a choice: use older version of your program or purchase a new key to work with the latest version of the program for one more year.

Let’s try it

Put the line formatted as MaxBuildDate=YYYYMMDD into the ini-file:

MaxBuildDate=20000101

In the test mode, the licensing system treats today as the build date, so it is important that the date specified in this line already passed. That is, the maximum date is yesterday. Modify the code of the main() function so that it looked like this:

int main(int argc, char **argv)
{
        char *serial = "Xserialnumber"; // we set the serial number directly in the code, for simplicity
        int res = VMProtectSetSerialNumber(serial);
        print_state(res);
        if (res)
        {
                VMProtectSerialNumberData sd = {0};
                VMProtectGetSerialNumberData(&sd, sizeof(sd));
                printf("max. build date: y = %d, m = %d, d = %d\n", sd.dtMaxBuild.wYear, sd.dtMaxBuild.bMonth, sd.dtMaxBuild.bDay);
                printf("please register!\n");
                return 0;
        }
        printf("I'm registered\n");
        return 0;
}

Then, upon program run you should see the following:

state = SERIAL_STATE_FLAG_MAX_BUILD_EXPIRED
max. build date: y = 2000, m = 1, d = 1
please register!

By replacing the date in the ini-file to today or tomorrow, we end up with the “working” program:

state = 0
I'm registered

Remove the MaxBuildDate=… line from the ini-file so that it would not influence our further steps.