License Recovery

License recovery refers to a multi-part mechanism the ClientProtector provides your application that allows your software, using various means, to "recover" the license from an inconsistent state to a consistent one. An inconsistent state can be brought about by a user accidentally tampering with your license files, the registry or - it may indicate that a cracker is trying to defeat your license.

An inconsistent license state arises for a variety of reasons. The following inconsistent states can be recovered from:

None of the Alias Files are found, but the license was found to have been installed on the machine before because the Virgin Registry Data was found.
Some, but not all, of the Alias Files are missing.
Although all the Alias Files were found, one or more of them was out of sync with the Main License File.
Although all the Alias Files were found, one or more of them had been tampered with (or internally altered).

When any of these conditions arises during the scope of the StartUp call, the ClientProtector will take one of several possible actions depending on how you configured your license and the state of the license itself. To best understand this process, please see SoftwareShield ClientProtector Control Flow Charts.

When an inconsistent state arises, the ClientProtector has detected that your software may be under attack from a cracker. While this is not always the case, it is important to understand that when it happens, it is not a failure of the system or your implementation, but rather a mechanism of protecting your software. This is why the ClientProtector doesn't (by default) automatically recover from inconsistent states. Instead, it gives you a chance to interpret the state and make your own decision to take whatever action you feel necessary. It further supports you in controlling how easy (or hard) it is for a user to recover their license if an inconsistent state arises - from the user not even knowing anything happened at all, to requiring then to enter a special Activation Code issued by you to recover the license (the default).

Making the decisions about how to configure your license to recover from an inconsistent state is an important balancing act. The more secure you make your recovery implementation, the more code you will have to write and support costs you may incur from dealing with legitimate users who accidentally mess with the licensing system. On the other hand, the more you make recovery transparent for the legitimate user, the easier your make it for a cracker to attack your software protection. We recommend a balanced compromise below.

There are five main possibilities of how your software can recover the license. In some cases, these can be combined for a more effective or flexible recovery system. Each of these is covered in more detail in the following subsections.

Auto-Replace Main License File. No user intervention. This setting can recover from the most possible inconsistent states with the best likelihood of total state recovery. This is the least secure method of recovery. Requires that the license is also set to "Auto-Recover" (see below).
Auto-Recover. No user intervention required. This setting can recover from many states. Somewhat in-secure method of recovery.
Prompt for Recovery. User will be prompted by your OnAttemptRecover event handler. This is the secure standard method we recommend. This method implicitly includes the next method "Recover By Activation Code" because an Activation Code will be required to recover the license.
Recover by Activation Code. User will be prompted by your program to recover, outside the scope of the StartUp call. Can be made very secure by your implementation (see subsection for details).
Force Recovery. No user intervention required. Depending on your implementation, can be both secure and in-secure.

We recommend that you implement at least one method for license recovery in every license you create. We recommend that you use "Prompt For Recovery" unless you have very specific reasons to do otherwise.

Regardless of the method of recovery, when successful, The actual act of recovering does the following (at least):

Deletes any and all Alias Files. (In the case of Steganographic Alias Files, the file is not deleted, but the licensing data is removed from the bitmap.)
Deletes the Virgin Registry Data (if used).
Sets the Last Used Date/Time to the current date and time.
Rewrites the Main License File.
Rewrites any and all Alias Files to be synchronized with the Main License File.
Rewrites the Virgin Registry Data (if any).

More Information

For help understanding when and how the various recovery mechanisms will be invoked by the ClientProtector, see the SoftwareShield ClientProtector Control Flow Charts in the ClientProtector Reference.

For help on using the various methods of recovery mentioned, see the subsections: Auto-Replace Main License File, Auto-Recover, Prompt for Recovery, Recover by Activation Code and Force Recovery in this Feature Guide.

For help on actually setting the recovery options in your license project, see License Behaviour Tab in the SoftwareShield License Manager Reference.