Implementing Runtime Guards

The objective of the Runtime Guards is to trigger a Validation process during the runtime of the Application, after the initial License validation at start-up.

In the traditional case of consumer applications on laptops and desktops, where the User will most likely close the Application after use and/or close their computer regularly, the initial DNA_Validate() will be sufficient to protect the App.

For mobile applications (ex: Android), the Application may be open for extended periods of time, toggling between active and background state, so adding a DNA_Validate() type call when the App is brought to the foreground is recommended.

You will want to implement one or multiple Runtime Guards for one of the following reasons :

• You want to add an extra level of security and difficulty for hackers that may try to circumvent your initial license validation.

• Your application may be left running on a given computer for an extended period of time (days, weeks) without being closed, or the computer restarted / shutdown.

• Your mobile application may be left running on the mobile device, toggling from active to background

• Your application may be run on a "Virtual Machine" and left running for an extended period of time, or the VM state saved and resumed later, without being closed, or the VM stopped.

• Your application will be running in "Service Mode"
  See Running in Service Mode     for details.

Runtime Guards can take the form of additional DNA_Validate and DNA_ValidateCDM API Calls beyond the main DNA_Validate API Call routine or by using the separate API Calls DNA_Validate2, DNA_Validate3, DNA_Validate4 or DNA_Validate5 (or the DNA_ValidateCDM equivalents) which create distinct function signatures in the assembly level code of the Software.

For the Runtime Guard to be effective against hacking, they should not re-use any of the code from the main DNA_Validate() call (i.e. not use a common function for the API call). The Runtime Guard does not necessarily need to implement the full Error Code interpretation code as it only needs a "Success or Failure" answer from the DNA API call.

How to implement Runtime Guards

Runtime Guards can be inserted anywhere in your code. Some typical implemtations include:

• Setting up a timer in your App that triggers the execution of a function containing a DNA_Validate() call. The timer can be set, for example, to trigger the function every day or every other day to catch an instance of the Application running for an extended period of time.

  NOTE: it is important that the Library is loaded and the API Calls executed from the same thread, typically the main thread.

• During an important function of your Application, for example, before or after "SAVE", or "OPEN" menu selections.

• On Mobile devices, include the Runtime Guard when the App becomes active (ex: onResume() event on Android)

• Any other location that would be executed on a regular basis.

An effective way to further frustrate hackers is to delay any reaction to a "Failure" from one of the DNA_Validate calls to make it harder to determine cause and effect of the code. Flags can be set and eventually the application functionality degrades, stops working, pop-up screens appear encouraging users to purchase the software, etc.

How often will Runtime Guards trigger a DNA Server Validation

The DNA_Validate() API call or the variants DNA_ValidateX(), will perform:

• a local validation of the CDM License file every time
• maximum once per day, will perform a DNA Server Validation

The DNA_Validate() API can be called many times per day knowing it will issue only one DNA Server Validation per day.