|Delphi Clinic||C++Builder Gate||Training & Consultancy||Delphi Notes Weblog||Dr.Bob's Webshop|
I'm the proud owner of many of the TurboPower libraries, and every now and then I collect my findings and write a little review about of one of these libraries or collection of components. The one I'm going to review today is a new one, called TurboPower ProActivate.
ProActivate is a tool to protect your executables. This may sound a bit like OnGuard, and I'm convinced a lot of the OnGuard technology has been incorporated in the ProActivate product (as well as Abbrevia and perhaps even LockBox technology).
The major difference between OnGuard and ProActivate is that fact that OnGuard is a library (set of units, with source code) that compiles with your application to protect it (available for Delphi or C++Builder). On the other hand, ProActivate is a toolset itself, that can protect (almost?) any 32-bit PE executable - written in any development environment.
One License Per Machine
Another significant differences becomes visible after installation, when we have to unlock (or activate) our copy of ProActivate. Each ProActivate license gives you the ability to run it on just one machine (actually, ProActivate consists of two parts, and each of these part can be executed on a different machine if that's more convenient).
With OnGuard, the license.txt file clearly states that "The supplied software may be used by one person on as many computer systems as that person uses." (which I like, since I have multiple development machines). In order to use ProActivate on a second machine, I need to purchase an additional license. Bummer!
But enough about that; let's first examine what it can do (and complain about the licensing later).
ProActivate consists of three different parts, that need to operate together. First (or rather, in the middle), we have the Product Database. This is the place where we can maintain our protected applications (executables - but not DLLs).
Next to the Product Database, ProActivate consists of two different tools (the Application Manager and the License Manager) that are both using the Product Database (and in fact cannot run if they cannot connect to the Product Database).
In order to place an application in the Product Database, we have to "protect" it using the Application Manager. The Application Manager can turn a regular executable into a secure (or protected) application. The protected application is compressed as well as encrypted, and won't be executed until a valid license file has been found.
Using the Application Manager, we can add new applications (executable files created by Delphi, C++Builder or any other 32-bit development environment), and turn them into smaller protected executables. During this process, we can add some information such as the product title (for our own identification), version number (a new version of your application must be protected again), and a description that will show in case of a missing or invalid license file. We can present all this information in the New Secure Application dialog:
The Advanced Options offer the ability to update the PE date/time stamp or checksum, encrypt the resources (new in update 1.06), or enable the so-called license link (we'll get back to that in a moment).
The end result is a list of protected applications. Note that for each version of the executable, you need to generate a new protected version (you only want to distribute the protected executables, that will only run when combined with a valid license file).
The example so far shows my TableBob application, maintained in directory D:\usr\Bob\Tools\TableBob\TableBob.exe (the source code and compiled executable).
The compressed, encrypted and protected version of TableBob.exe will be placed in the Deploy directory (or any location that you wish to specify).
It's this version of TableBob.exe that can be deployed - for free, since people need a license file to actually use it.
License files - for specific protected applications - can be generated using the License Manager. Both the Application Manager and the License Manager use the information stored in the Product Database (and you cannot generate a license when an application hasn't been entered in the Product Database first).
There are a number of standard new licenses that we can generate with a right mouse-click or the License | New menu.
A 30, 60 of 90 Day license enables the use of the protected application for 30, 60 or 90 days since a specified starting date.
It's even easier to specify a limit on the number of uses (runs) or days.
Note that these days don't need to be consecutive, so with a license file for 52 days, you can use the application each Sunday for an entire year!
And the somewhat more advanced options allow you to generate a license file for an owner, organisation or even specific machine (a bit like Windows XP or ProActivate itself, which has to be activated using the internet or by telephone).
However, just like all real developers, I want to investigate the Custom License option (don't you agree?), which also gives us the option to combine two or more of the license options.
The New Custom License dialog consists of five tabs, each for a specific kind of protection, that can be combined for a more restrictive license (for example a license that is valid until October 26th, but can still only be executed only 42 times).
The first tab is called Description and can be used to specify a description and a specific error message (in case the license is expired or invalid).
On the Second tab of the New Custom License dialog (called Registration), we can enter specific user, company and machine information. The first two are checked against the corresponding values found in the registry of your Windows installation, the Machine ID is calculated/generated by the protected application itself upon startup. If you want to set the Machine ID option, then you need to ask your client to send you his/her machine ID first (so you can enter it here in the Registration tab):
The third tab of the New Custom License dialog is called Dates and can be used to specify the starting date (i.e. you can't use the protected application before this date) and the end date (you can't use it after this date):
The fourth tab of the New Custom License dialog is called Counts and can be used to specify the maximum number of days (not necessarily consecutive days) or maximum number of executions (runs) of the protected application. Note that in the example below, I've specified 42 days and 42 runs, but I could have left the 42 days empty, since 42 runs can be done on at most 42 days (it's the start-up that counts, not the fact that the application may potentially be running for 42 days).
As you may have noticed by now, all tabs where we actually specified some required license information are checked with a red marker (I removed the license information from the Registration page of the dialog, hence the fact that you don't see a marker on that tab).
The fifth and last tab can be used to specify the so-called license link information. For that to be used, we needed to enable the license link in the Application Manager as well (and since we didn't do that, the following action will be useless).
We see that the application data consists of only zeros at this time. In order to use the License Link, we can specify up to 32 hexadecimal digits here, that will be passed to the application itself. Like I said, in order to "receive" this information, the License Link option has to be enabled in the Application Manager. But that's not enough, because we must still respond to it, which can be done by using the TLicenseLinkHelper class (provided in unit uLinkHlp.pas). Obviously, this means that the application that you want to protect has to be build with Delphi (or C++Builder) itself, in order to be able to respond to the License Link information!
After we've set all options we can click on the OK-button in the New Custom License dialog to create the license file as well as license record in the database. The ProActivate License Manager now shows both the Product Info and the License Info. Of course, for each potential customer you may want to generate a new license, so the treeview on the left will consist of multiple products, multiple versions per product, and multiple licenses per version (per product).
Once a license file is ready to be distributed to a customer, you can send it to this customer. To help you do that (from within the License Manager), you can use the License | Send to Mail Recipient option (you need to configure the mail options first):
The e-mail dialog can be used to send the license file as well as a little explanation (that it should be placed in the same directory as the protected application):
If the client runs the protected application without a license file (in the same directory), then the following dialog will appear (note that this dialog always presents the Machine ID, which can be used to produce a machine-specific license as seen in the Registration tab of the New Custom License dialog):
With the correct license file, the license check will be executed (start date, end date, number of runs, etc.) and only if this is test successful, then the protected application will be unpacked (in memory) and executed. If the license has expired, then the following dialog will be shown:
Of course once a license has expired, you can generate a new license file for this customer (for example with a later end date, or more execute runs).
The new license file can be copied over the old one, and the game starts again.
As you can see, ProActivate is a quick-and-easy way to protect applications, versions and generate licenses for your customers. It takes only a few minutes to get used to it, and before you know it you have all your applications and versions in the Product Database and are ready to produce (read: sell and distribute) custom licenses.
The biggest "problem" that I encountered when using (and reviewing) ProActivate was the fact that I could only unlock/activate it on one of my machines. I'm a one-man company, but with multiple machines. And although I have a main development machine, I also have a laptop that I use for presentations. And this laptop is the one that I needed to give a demonstration of ProActivate to one of my clients. As a result, I was "forced" to install and unlock ProActivate on my laptop, which means that every time that I want to protect one of my applications, I need to fire up the laptop (note that while it's possible to transfer the license from one machine to another, I wouldn't do that often). I can understand the sentiment behind this, but I'd much rather have a personal license that I could install on all my machines (as long as I would be the only user).
ProActivate on the Web
Another happy user of ProActivate, Marc Hoffman, has written a detailed article in which he explains how to integrate ProActivate licensing into your website, using an Active Server Pages based website.
ProActivate is a useful tool to protect your applications. The ease-of-use (convert executables into protected executables, generate license files) and integrated e-mail facilities offers good integration in your current workflow. However, ProActivate own licensing will force you to consider carefully on which machine(s) you want to install the individual tools.