Introduction:
This article describes an easy approach to keeping track of each installation of an application. The intent of the example is to demonstrate the use of a simple web service to collect and store information about each user and machine running the application.
I was originally driven to coming up with something like this in response to working for an employer that operated strictly on the honor system. By that I mean that the company would sell its software by the seat to individual clients but with no licensing or other restrictions imposed or enforced by the software that might prevent the installation of additional copies of that software; for example, if a client purchased five seats of the product, it was assumed by the company that the client would only install it five times.
In one particular sale of the product, I felt that it was likely that the client would install additional copies beyond what they had purchased (given the magnitude of work they had to perform, five seats seemed woefully inadequate) and I had asked for approval to implement a licensing scheme in the code; the company declined to do this for whatever reason. They did agree for me to devise a method for tracking installations without requiring a license. The code in this project is a derivation of what I did there mainly because in the original approach, I was not permitted to terminate the application if it were not registered; I was only able to collect information on the installations. What we discovered was that the five purchased seats were installed over 100 times by the client (at about a $380,000 loss in revenue to the company in this one instance).
When I wrote this example version, I did it a little differently in that I create a bogus registry entry that is used to determine whether or not the application was installed and registered through the web service. If the product is not registered, I prevent the application from being used. When I terminate the application, I inform the user that the registration process is incomplete and that the process requires an active connection to the internet. This works much like what is seen when you are required to, for example, activate a copy of Microsoft Word through an internet connection. The registry key is checked each time the application is executed, if the registry key exists and its value indicates that the product is registered, then nothing else happens, if that is not the case, the application will not run until the registration occurs. If a person were to X-copy the application onto another machine, the application will still check for the key the first time it is executed and therefore it will not run until it is also registered.
I did not use it in this example, but you could use the original installation date and allow the user to use the product for some set period of days prior to locking them out which could be useful if you are authoring shareware with a time limited trial period. Here in this example, I just lock them out from the beginning. This approach does not prevent the client from over installing the product; it merely forces each installation to be registered through the web service. You could easily modify the web service to check and see if an individual license has been registered and prevent additional installations of that license but for the purposes of this example, I am only demonstrating the capture of each installation through the service.
As it stands, the example is not the be-all, end-all solution to securing your application against theft. It does however offer an approach for determining the extent of abuse you may be encountering with a release of custom software to a client company. That information may be useful in making an argument for building a more robust approach to licensing your distributions.
Getting Started.
To get started, unzip the source code included with this project. In the code example, you will find a web service, and a Win Form application. Open the Web Service up and make any changes necessary to get it to operate on your machine. The project containing the web service has an MS Access database included and the database contains a single table used to collect the installation information. In reality you'd probably configure a database and table in SQL Server or Oracle to contain the data but for the purposes of this demonstration it was easier to pack it up in Access. Aside from the MS Access database, you will note that the web service project only contains a single service entitled, "RegisterInstallation".
Once you've configured the web service, run it and check it with the proxy to validate that it is updating the database correctly:
Figure 1: Run the Web Service
With the web service running, select the link to "RegisterInstallation":
Figure 2: Testing the "RegisterInstallation" Web Service
Once you've keyed in some sample values as indicated in Figure 2, click on the "Invoke" button and view the response, if successful, you should see something like what is shown in Figure 3:
Figure 3: The web service returns "true" if the installation information is saved to the Database
Given the web service has returned a true, take a look at the database to confirm that the values entered have been stored in the table:
Figure 4: The AppInstallers Table Updated By The Web Service
Having confirmed that the web service is up and running, open the application solution into Visual Studio 2005. Examine the content of the project in the solution explorer, you should see the following:
Figure 5: RegTest Application Solution Content
Within the solution, note that the registration service has been added as a web reference, you will likely need to update this reference. The app.config file is the default version and can be ignored here. The classes worthy of note are the frmMain.cs class and the RegistrationCheck.cs class. The main form class (frmMain.cs) represents your application, and the registration check class is used to capture information about the machine containing the application and package up for submittal to the registration web service.
Assuming that the web service and the project references check out, we can now take a look at the code.
Code: Web Service Project - Registration Service
Locate the RegistrationService.asmx file contained in "RegistrationSvc" web service solution and open it up in the IDE. You will note that this is a very simple service and in general, all that it does is expose a function entitled, "RegisterInstallation". This function receives a collection of arguments containing the information about the installer and formats and executes an insert query against the MS Access database used to contain the installer information.
The import section of the code in this class has been amended to include the portions of the System.Data library that pertain to use of an OleDb data source:
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Data;
using System.Data.OleDb;
[WebService(Namespace="http://localhost/RegistrationService/")]
[WebServiceBinding(ConformsTo=WsiProfiles.BasicProfile1_1)]
[Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()]
public class Service : System.Web.Services.WebService
The class declaration is cleverly called "Service" and the attributes applied to the class are also in the default configuration with the exception of the updated namespace. The only function in the service exposed as a web method is the RegisterInstallation function; its code is as follows:
[WebMethod()]
public bool RegisterInstallation(string strDomainAndUser, string strComputerName, string strApplication,
string strVersion, string strAppID, string strInstallDate)
{
OleDbConnection conn = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;" + "Data
Source=c:\\inetpub\\wwwroot\\RegistrationSvc\\Registration.mdb;" + "User ID=;Password=;");
try
{
System.Text.StringBuilder strBuilder = new System.Text.StringBuilder();
strBuilder.Append("INSERT INTO AppInstallers ");
strBuilder.Append("(DomainAndUser, ComputerName, Application, Version, AppID, InstallDate) VALUES(");
strBuilder.Append("'" + strDomainAndUser + "', ");
strBuilder.Append("'" + strComputerName + "', ");
strBuilder.Append("'" + strApplication + "', ");
strBuilder.Append("'" + strVersion + "', ");
strBuilder.Append("'" + strAppID + "', ");
strBuilder.Append("'" + strInstallDate + "')");
string sSQL = strBuilder.ToString();
OleDbCommand cmd = new OleDbCommand(sSQL, conn);
try
{
conn.Open();
cmd.ExecuteNonQuery();
conn.Close();
}
catch (Exception ex)
{
conn.Close();
return false;
}
}
catch (Exception ex)
{
conn.Close();
return false;
}
conn.Close();
return true;
}
This function is pretty straight forward; the arguments detailing the installer's information are passed as arguments to the function, the function then takes the arguments directly and passes them to an insert query against the MS Access database. Once the execution of the insert statement has completed, the function returns a Boolean set to true if the data is passed to the database or false if the operation fails to update the database.
That is all there is to the web service; the calling application will gather the user's information and, if appropriate, connect to the web service and post the data to the database used to house the installer information.
One point to make here is with regards to the setting of the installation date; in this example, the value is passed into the web method from the client. If you are interested in creating a grace period for using the application (e.g., allow the user to use the application for 30 days without registering it) you may wish to set this value on server side instead of the client. This will prevent the user from changing the date on their machine to gain additional, free use of the application.
Next, open the "RegTest" solution into the IDE and we can take a look at that.
Code: RegistrationCheck Class.
First off, open the "RegistrationCheck.cs" class into the code window. You will note that the class contains two subroutines and one function. The imports statements and class declaration are as follows:
using System.Collections.Generic;
using System.Windows.Forms.SystemInformation;
public class RegistrationCheck
By importing the "SystemInformation" library, we are able to capture the information used to identify the machine and user running the application. This will provide us with the source for the arguments passed to the web service.
Now take a look at the function, "CheckProductRegistration". This function is public and is the means by which the application checks for prior registrations and then gathers and submits data to the web service during the initialization of an unregistered version of the application. The code for this function is as follows:
public bool CheckProductRegistration()
{
// Check registry for key,
// create the key if it does not exist
CheckForOrMakeRegKey();
// Check the key to see if application has been registered
// the key DA\SOMLA\1.0 is nonsense; it is just there to confuse anyone that tries to
// defeat the registration process. (actually, SOMLA is some software I used in the
// mid 1980's to test aircraft crash effects upon a seated aircraft occupant, but you
// can put whatever you want in there, use Bullwinkle or cDc if you don't like SOMLA)
// Set this boolean upon determining whether or not
// the product has been registered
bool blnIsRegistered = false;
Microsoft.Win32.RegistryKey key;
try
{
key = Microsoft.Win32.Registry.CurrentUser.OpenSubKey("SOFTWARE\\\\DA\\\\SOMLA\\\\1.0");
if (key != null)
{
int intVal = System.Convert.ToInt32(key.GetValue("dval"));
if (intVal == 0)
{
blnIsRegistered = false;
}
else if (intVal == 1)
{
blnIsRegistered = true;
return true;
// it is already registered so just return true
// and exit out of function
}
}
else
{
// The key does not exist, the application has not been registered
blnIsRegistered = false;
}
key.Close();
}
catch
{
// do nothing here, we want this to be pretty quiet...
}
// Registration has not occurred, so try to register it
if (blnIsRegistered == false)
{
// Obtain the user name currently logged on to this computer
string strUser;
strUser = System.Windows.Forms.SystemInformation.UserName.ToString();
// Obtain the user's domain name for the current session
string strDomain;
strDomain = System.Windows.Forms.SystemInformation.UserDomainName.ToString();
// Combine the user and domain names into a single entry
string strDomainAndUser = strDomain + "\\" + strUser;
// Get the name of the computer the application
// is installed on
string strComputerName;
strComputerName = System.Windows.Forms.SystemInformation.ComputerName.ToString();
// Create a local instance of the web service
RegistrationService.Service ws = new RegistrationService.Service();
// The web service returns a boolean to indicate
// success or failure in execution
bool blnTest = false;
// Run the web service and load the installer's
// information into the database
try
{
blnTest = ws.RegisterInstallation(strDomainAndUser, strComputerName, "RegTest", "1.0", "{376FEDC1-
BC65-4c6a-B3C2-49CD57BFD127}", DateTime.Now.ToLongDateString());
}
catch
{
// Create registry entry and set it to false
CreateKeyAndSetValue(0);
}
//NOTE: the GUID is canned as is meant to mark the install
// as a specific copy of the application
// create new guids and registry keys for other customers
// and applications - this will allow you to track who bought
// the software versus where it ends up getting installed.
if (blnTest == true)
{
// Create registry entry and set it to 1 - registered
CreateKeyAndSetValue(1); // IS registered
return true;
}
else
{
// Create registry entry and set it to 0 - not registered
CreateKeyAndSetValue(0); // NOT registered
return false;
}
}
return false;
}
The first thing this function does is call a private subroutine used to check for the existence of the registry key used to check for prior registrations of the application. If the key does not exist (first use), the key will be created in the subroutine. The key used "SOFTWARE\\DA\\SOMLA\\1.0" is just some nonsense used to through someone off if they were to try to find and manually edit the key value used to determine whether or not the application has been registered. As I mention in the comments, SOMLA is an application dating back to the 1980's; it was used to run analysis of the effects of a crash upon the human spine. "DA" was for district attorney. You can change these values to whatever you want but you should make some effort to conceal the purpose of the key and its value.
Next the function gets the value of the key used to mark the application as having successfully been submitted to the registration web service; if the value indicates that the application has not been registered or activated through the service, it sets a Boolean to false, the Boolean is then tested and if it is false, the function will attempt to gather the user's information and submit it to the web service for registration. If the product is then registered, the calling method is notified of the success and the registry value is updated to indicate that the product has been activated through the service. If the Boolean returns false, the user is booted out of the application, else the user is granted access to the application.
The two subroutines in this class are merely used to support the function by creating or confirming the existence of a registry key, and by allowing the function to set the key value associated with the registration of the application. The code for these two subroutines is as follows:
private void CheckForOrMakeRegKey()
{
try
{
Microsoft.Win32.RegistryKey regVersion;
regVersion = Microsoft.Win32.Registry.CurrentUser.OpenSubKey("SOFTWARE\\\\DA\\\\SOMLA\\\\1.0",
true);
if (regVersion == null)
{
regVersion = Microsoft.Win32.Registry.CurrentUser.CreateSubKey
("SOFTWARE\\\\DA\\\\SOMLA\\\\1.0");
}
regVersion.Close();
}
catch
{
//do nothing
}
}
private void CreateKeyAndSetValue(int intVal)
{
try
{
// Declare a registry key variable and set it to
// be the fake SOMLA key
Microsoft.Win32.RegistryKey regVersionKey;
regVersionKey = Microsoft.Win32.Registry.CurrentUser.OpenSubKey("SOFTWARE\\\\DA\\\\SOMLA\\\\1.0",
true);
// If the key exists, then set its dval key value
// to the integer passed into this subroutine
if (regVersionKey != null)
{
regVersionKey.SetValue("dval", intVal);
regVersionKey.Close();
}
}
catch
{
//do nothing
}
}
That concludes the discussion of the contents of this class. Next, open up the main form (frmMain.cs) class into the code window. The only item worthy of note in the main form's code is the handler for the load event:
private void frmMain_Load(System.Object sender, System.EventArgs e)
{
// Each time the application is loaded, we check for the existence of the
// registry entry:
RegistrationCheck rc = new RegistrationCheck();
bool bln;
bln = rc.CheckProductRegistration();
// If the bln indicates that the application is not registered (and therefore
// could not be registered, then tell them Goodbye and exit the application.
if (bln == false)
{
MessageBox.Show("You have not registered this product. Registration requires internet access.",
"Registration Failed", MessageBoxButtons.OK);
Application.Exit();
}
}
This code is pretty simple, it merely creates an instance of the "RegistrationCheck" class, sets a Boolean variable to capture the results of the attempt to register the product, and then processes the evaluation of the returned Boolean. If the Boolean is false, the user is notified that product activation requires an internet connection and then the application is terminated if activation has not occurred. The user will continue to be met with this response until they permit the application to connect to the internet and subsequently activate the product.
Naturally, you can modify what occurs in response to a failed activation. For example, if you want to let the user use the product for thirty days after the original installation, you could amend the web service to return the initial installation date and compare that date to today's date and then decide whether or not to allow them to use the application.
Summary.
The sample application and web service are meant to convey an approach to activating a product. This is not a particularly robust way of doing it and it certainly is not foolproof. The approach could easily be compromised if the user were able to locate and manually edit the registry value. The approach does show you a general approach to product activation and is a good way of collecting specific information about who is using the software and determining which uniquely marked copy of the software the installer/user is running on a specific machine.
NOTE: THIS ARTICLE IS CONVERTED FROM VB.NET TO C# USING A CONVERSION TOOL. ORIGINAL ARTICLE CAN BE FOUND ON VB.NET Heaven (http://www.vbdotnetheaven.com/).