How to Analyze a Clone Report

Under certain circumstances, the Sentinel License Manager may report that cloning was detected even if intentional cloning did not occur. If an end user complains to you that they were blocked from using a Product due to cloning, use the procedure described below to analyze information from the user’s machine. This helps you determine whether the Product was blocked due to a false-positive clone report or whether an actual clone attempt occurred.

To generate a clone report:

1.Instruct the end user to generate a C2V file for the relevant protection key using RUS (described in Sentinel Remote Update System (RUS)) or Admin Control Center and to send the file to you. Alternatively, you can include a function in your application to generate a C2V file by calling the GetInfo function in the Sentinel Licensing API.

2.In Sentinel LDK ToolBox or Sentinel License Generation API:

a.Call sntl_lg_initialize to initialize a session.

b.Call sntl_lg_decode_current_state to read the C2V file and decode the current state of the protection keys on the end user’s machine.

3.Examine the decoded XML output of the C2V file as described below.

The decoded XML output of the C2V file contains information regarding all the protection keys on the machine. For each protection key, the XML output contains:

>The fingerprint of the machine from the time the protection key was activated (“reference fingerprint")

>The fingerprint of the machine from the time cloning was detected (“system fingerprint")

>Information regarding the Product licenses in the key

If the Sentinel License Manager detects that a protection key was cloned, the XML output for the key contains code similar to this:

<clone_detected machine_type=”Physical”>Yes</clone_detected>

For each Product that is regarded as cloned, the section in the XML output for that Product contains this code:

<fingerprint_change>Cloned</fingerprint_change>

Each Product can use a different predefined or custom clone protection scheme for physical and for virtual machines. A Product can contain both a predefined and a custom clone protection scheme. (For example, a predefined scheme for physical machines and a custom scheme for virtual machines.)

The clone protection scheme indicates which factors are considered by the License Manager when it checks to determine whether a machine (together with its protection keys) was cloned. For each Product license in the XML output, determine which clone protection scheme is used, and then compare the relevant factors in the reference fingerprint and the system fingerprint. The results of the comparisons should enable you to determine whether an intentional attempt was made to clone a machine and its protection keys. Clone protection schemes are described earlier in this appendix.

You can determine whether a given machine in a fingerprint is a physical machine or a virtual machine. The following tag in a fingerprint indicates that the corresponding machine is a physical machine:

<criteria>
   <name>vm_info</name>
   <value>1294737779</value>
</criteria>

If the value indicated in the tag above is anything other than 1294737779, the fingerprint is from a virtual machine.

For more information on the decoded XML output file, see the Sentinel License Generation API Reference.

Example 1 (Predefined Clone Protection Schemes)

Suppose you receive a C2V file from a customer who complains that protected applications will not run.

You decode the C2V file using ToolBox and then examine the generated XML code in a text editor. The XML code in the file indicates that the license is cloned.

The clone protection schemes are PMType1 and VMType2 as seen below.

<clone_protection_ex>
        <physical_machine>PMType1</physical_machine>
        <virtual_machine>VMType2</virtual_machine>
</clone_protection_ex>

The system fingerprint and the reference fingerprint from the XML code are shown below side-by-side.

As seen in the code:

>The motherboard IDs (mainboard_uid) in the system and reference fingerprints are not identical.

>The hard drive serial numbers (hdd_uid) in the system and reference fingerprints are not identical.

>The value of vm_info indicates that both fingerprints are from physical machines.

Therefore, these fingerprints satisfy the criteria for the PMType1 scheme to indicate that the license is from a cloned machine.

Example 2 (Custom Clone Protection Schemes)

Given that you receive a C2V file from a customer who complains that protected applications will not run.

You decode the C2V file using the ToolBox and then examine the generated XML code in a text editor. The XML code in the file indicates that the license is cloned.

The clone protection schemes are both custom as seen below.

<clone_protection_ex>
    <physical_machine_custom>
      <name>PM Custom</name>
      <criteria minimum="2">
        <name>ethernet_address</name>
        <name>sid</name>
      </criteria>
    </physical_machine_custom>
    <virtual_machine_custom>
      <name>VM Custom</name>
      <criteria minimum="2">
        <name>ethernet_address</name>
        <name>sid</name>
      </criteria>
    </virtual_machine_custom>
 </clone_protection_ex>

For both physical and virtual machines, the criteria are ethernet address and security identifier (SID). Since the minimum attribute is set to 2, both criteria must match in order to validate the license.

The system fingerprint and the reference fingerprint from the XML code are shown below side-by-side.

As seen in the code:

>The ethernet addresses (ethernet_uid) in the system and reference fingerprints are identical.

>The security identifiers (sid) in the system and reference fingerprints are not identical.

>The value of vm_info indicates that both fingerprints are from physical machines.

Since the required number of matching criteria is 2, and only one 1 set of criteria match, these fingerprints satisfy the criteria for the custom scheme to indicate that the license is from a cloned machine.