Registration Keys

Items

Registration Keys

Meaning of each field into the registration key

Local registration data

The Key Data

Remote registration data OLM

What we do with the data?

The methods WriteAppData and WriteKeyData

The methods ReadAppData and GetKeyData

What is a Generic Key?

REGISTRATION KEYS

Registration keys are codes with the following format: XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX with a total length of 31 characters. A registration key has internally fields of data used to control your application. Please see represented below these fields and its sizes:

Fields of a Registration Key:

Field        length type

------------- ----  -----

Days            4   word

Users           2   byte

Instances       2   byte

Startdate       4   word

Index           2   byte

iCode           4   word 

AppID           4   word

Values          3   hex string

KeyType         1   nibble

Checksum        2   byte

             ----

Total length   28

These fields are concatenated into a single string, then strongly encrypted with the Rijndael algorithm then formated with hyphens to make it more readable, e.g. 98RAWTV-9GP5KLK-T7RMRW9-AD305UQ

Meaning of each filed into the registration key

Days

Authorized days for the trial or temporal period. For permanent keys this field is 65535.

Users

Number of users who will share the same registration key through the OLM. A different record will be created by each user.

Instances

Number of instances running at once into the computer.

StartDate

Date where start the authorized period for trial and temporal keys. For permanent keys this field is 65535.

Index

The key number. Number to identify the key into the registration data. Byte value between 0 and 254.

iCode

Is the checksum of all data fields into the InstallCode property coming from the hardware and other sources. This is included to be compared later with the one coming from the computer where the application is installed in order to verify it.

AppID

Number to identify the application.

Values

It consists of three Nibbles (1.5 bytes). This multipurpose field was added in version 3.0 and allows you with one key control many options in its application, thus eliminating the need to use multiple keys to control your application. In the examples you will see how this can be used in various ways. See decodevalues() function that takes the three nibbles and converts an array of booleans. See also in the ShowRegData() procedure how this converts the values field into a integer value of 3 Nibbles (0 .. 4095) or three integer values of 1 nibble (0 .. 15) or 12 boolean values.

KeyType

This field categorize the key with the following possible values:

0=trial,  1=temporal,  2=permanent,  3=unregister,  4=unregisterall

Add 5 for generic keys as follow: 5=generic-trial, 6=generic-temporal, and so on.

CheckSum

Checksum of all above fields. Used later to verify the Key.

In some examples you will see the registration data of a key in a form as follows:

Here you see the data fields extracted from the registration key for a given Index using the GetKeyData() method, where you pass as input parameter the Index number and as output parameter a record variable of type TKeyData which receive the fields that you see in the image.

Besides the previously mentioned fields there are obtained also other related fields, namely:

Status: The registration status of the key. This may be:

1) Unregistered: Meaning the lack of registration. There are no key registered for this Index. (not functional)

2) Moved: The key was marked to be moved to another computer (not functional).

3) Expired: The authorized period finished for a trial or temporal key. (not functional)

4) Registered: The key is registered and functional.

EndDate: Date ending the authorized period by a trial or temporary key.

Primary: Is true when dealing with a primary registration. The first recording made for a key in the OLM is the primary registration, the following being made to complete the number of authorized users are secondary.

DateBacked: Takes the same value as the property of the same name; True if the system date was turned back. If so, you would take some action, like terminate the program or call the OnlineCheckDate() method which compares the system date with the obtained from internet. See in the the method GetKeyData().

TooManyInstances: True when the number of instances running on the computer exceed the number of authorized instances. If so, you would take some action, like terminate the program.

Key: The registration key registered for the given Index.

Primary ICode:  Checksum from the Primary InstallCode. Only usable for secondary registrations.

Primary Installcode:  InstallCode from the primary registration. Only usable for secondary registrations. This code and the previously mentioned ICode are saved together with the registration key in order to compare it later with the ICode (checksum) included into the key. See in the image below how is configured the key data into a secondary registration.

When the module is registered, the key is concatenated with the InstallCode coming from the primary registration and with the Installcode coming from the local computer. Then this string is strong encrypted and saved with the registration data into the local disk.

See in the image the comparisons that take place there, both are needed. So, if the Local InstallCode is not included anyone could copy these registration data from one computer to another in order to use illegally the program. The second comparison avoid this risk.

For a primary registration both installcode must be the same and identical to the local Installcode.

Besides the data shown above, also are saved two fields of 1 character each, which can take the values 'Y' or 'N', denoting boolean values. The first one for the Moved Status and the second for the Primary field.

THE LOCAL REGISTRATION DATA

AVLock SIMPLE holds information into the computer where the application is installed, this information is called REGISTRATION DATA and are classified into two sections: APPLICATION DATA and MODULE DATA.

This information is saved strongly encrypted into a file (the RegFile) saved into a folder based in the RegFilePath property. By example the file 'FG5U2LVM.avr' located into the 'C:\Document and Settings\All Users\Application Data\avlocks3' folder. This is the location where is saved the RegFile for the Demo1 sample.

See below a sample of the content for this file.

[FG5U2LVM]

ad=FC740586F92FEDE5C5ADC86F417747AE3ABAC6F080EF58F97DFE1145F5498303CFEB5738E1F54524B45FF89DBD82B23EA3FEE52840D5F3592255ACFBA653C12B

0=9F8C6F3A53E4D73DF1DC826A99208161D0C123AFCBF016CDC6CF6C72538C9126EBCD01845D8712B6A6056DBE6DA050E8B6F408AA2CFE6AA5F1109C5B9F038AD44C1F16F73F60051137A214FBDDE4E618BD60E8FE13F20B95A98687EBA1AFE436

a) THE APPLICATION DATA

In this section is saved some component properties in order to be restored later and also specially required into the RegMonitor utility.

Below is a sample for the Application Data into the file:

ad=FC740586F92FEDE5C5ADC86F417747AE3ABAC6F080EF58F97DFE1145F5498303CFEB5738E1F54524B45FF89DBD82B23EA3FEE52840D5F3592255ACFBA653C12B

The entry start with 'ad' (application data).

The data saved into this section are as follow:

RandomCode: (match with the RandomCode property)

Only applicable when Random_Number is enabled into the InstallCodeSources. This is a random number calculated when the application runs the first time and take part in the InstallCode property calculation.

OtherCode: (match with the OtherCode property)

Only applicable when Other_Source is enabled into the InstallCodeSources. This is a number that should be settled at runtime when the application starts and take part in the InstallCode property calculation. See more details in the Properties topic.

ICSrc : (match with the ICSources property)

This is a string representation of the InstallCodeSources property and take 5 digits. e.g. '10100'. Each digit correspond to a source into the InstallCodeSources property. '1' = source active, '0' = source inactive. See more details in the Properties topic.

UserName : Name of the user (match with the UserName property).

Company : Company of the user (match with the Company property).

Email : Email from the user (match with the Email property).

AppName : Application name (match with the AppName property).

AppVersion : Application versión (match with the AppVersion property).

b) THE KEY DATA

For each key in the application there is an entry within this section. Each key is identified by its number of key (Index 0 .. 254). For example, the following is an entry for the key 0.

0=9F8C6F3A53E4D73DF1DC826A99208161D0C123AFCBF016CDC6CF6C72538C9126EBCD01845D8712B6A6056DBE6DA050E8B6F408AA2CFE6AA5F1109C5B9F038AD44C1F16F73F60051137A214FBDDE4E618BD60E8FE13F20B95A98687EBA1AFE436

The data saved for each module is as follow:

RegKey : Registration Key. e.g. 4F5D5H9-RK7CEVW-1G49YFJ-NK10FNT

Moved  : 'Y' when the key is marked to be moved to another computer and 'N' for a normal registration.

Primary : 'Y' for a primary registration and 'N' for a Secondary Registration.

Installcode : Correspond to the local Installcode property. e.g. DF8ACE-DC468A-4561A5-FD2D61

Primary InstallCode : For a primary registration is the local Installcode. For Secondary registration this value is the Installcode coming from the Primary Registration from where this depends.

THE REMOTE REGISTRATION DATA (OLM)

If you use the Online License Manager (OLM) to register applications and users, also you will have there a MySQL database with information about your registered applications, users and registered keys.

For each registered key we will have at least one record into the OLM for its primary registration and additional secondary records for users associated to the primary registration until complete the number of authorized users. Below is a list of the data fields held for each record:

APPID : AppID property.

STARTDATE : Date from where started the authorized period. 

DAYS : Days for the authorized period.

USERS : Number of authorized users.

INSTANCES : Authorized number of instances to run concurrently into the computer. 

KIND : Type of key (0=Trial, 1=Temporal, 2=Permanent)

APPNAME : Application Name (AppName property).

ICSUM  : Shecksum from the Installcode (ICode property).

ICODE  : InstallCode property.

ICODEP : InstallCode from the primary computer. ICODE and ICODEP are identical for primary records.

MODULE : Key number (Index) (0..254).

USERNAME : User name (UserName property).

COMPANY : User company (Company property).

EMAIL : User Email (Email property).

EXTEN : Take 'Y' or 'N' values. 'Y' to authorize to extend the trial period.

PAID : Take 'Y' or 'N' values. 'Y' to authorize to register a new key after the payment.

MOVED : The record has been marked to be moved to another computer.

PRIMAR : The current record is for a primary registration.

LASTKEY : Latest Registered Key.

KEYDATE : Date of the LASTKEY.

VALS : Match with the Values field saved into the Registration Key and retrieved later as part of the TKeyData record using the GetKeyData() method.

AND NOW, WHAT WE DO WITH THE DATA?

We saw briefly the data managed for the component where these are saved into the computer where the program is installed (LOCAL DATA) and into the OLM (REMOTE DATA). Next we will consider how this data is managed and which methods are involved to accomplish it. These are some of the more relevant ones:

THE WRITEAPPDATA() AND WRITEKEYDATA() METHODS (only for the local registration data).

The WriteAppData() method takes the registration data from the properties of the AVLock SIMPLE component into the application and then saves it into the  *.avr registration file into the local hard disk. 

The WriteKeyData() method takes as parameter the Registration Key to be saved and writes it into the *.avr registration file into the local hard disk.

For more information see above these sections: 1. THE APPLICATION AND THE COMPONENT and 2. THE REGISTRATION DATA.

THE READAPPDATA() AND GETKEYDATA() METHODS (only for the local registration data).

The ReadAppData() method reads the registration data for the application from the *.avr registration file into the local hard disk and then uses it to fill the AVLock SIMPLE properties into the application. 

The GetKeyData() method reads the registration data for a given Index from the *.avr registration file into the local hard disk and then uses it to fill a record of type TKeyData into the AVLock SIMPLE component.

Now let's see these fields with more details. From a practical view point we can consider the AVLock SIMPLE component as a black box inside the application to which you can send questions and obtain responses. For example, you can use the GetKeyData() method to query about the status of a given Index. In the sample  below we ask for the Index 0.

With AVLock SIMPLE it is able to manage until 254 keys for each application, although never you will need all them.  However with only one we can take control of the application starting a trial period the first time that the application runs, then checking the key status using the GetKeyData() method each time that the application starts, in order to show the adequate message and allow to the user to continue running the application or blocking it if the time of use has expired or the system date have been backed on or the max number of instances allowed has been reached.

In version 3 Added Values field, this can be very useful to simplify the use of AVLock SIMPLE, allow with a single key control the main application and enable / disable various options and features in your application. Now with this new feature only rarely will need to use more than one key in your application.

WHAT IS A GENERIC KEY?

Normally a key is generated to be applied only for one computer where the InstallCode match with the one used to generates the key. But, if you check the "Generic key" checkbox, then will be generated a generic key which will serve to register any computer, but in this case limited to the same version, so if you change the version property in your application this key will not serve for this new version. This kind of key can be useful for massive registrations but for another use it is not recommended.

I tried to make this help file clear, readable and complete, this is my goal, but it is possible that I leave behind some important things that you were expecting. So, if you miss something or have found bugs or have some idea to improve this help, please let me know.