Checks Overview

A Check is a piece of code that is injected into existing methods to "check" whether a particular condition is true and, if so, trigger various responses.

PreEmptive Protection™ DashO™ can inject the following Checks into applications:

• Debug - Is the application being debugged or is enabled to allow debugging?
• Emulator - Is the application running on an emulator?
• Hook - Is hooking detected?
• Root - Is the application running on a rooted device?
• Shelf Life - Has this application expired (or will it expire soon)?
• Tamper - Has the application been tampered with?

With the exception of Shelf Life, all the different Checks and Responses work in a similar fashion. The Check can respond in different ways either immediately or later via a separate Response. These Checks and Responses can be configured via the Checks UI or by adding code annotations. Shelf Life does not have a separate Response.

There are several samples which demonstrate the use of the different Checks and Responses.

General Check Behavior

If the Check is triggered you can respond to it in different ways. You can choose one or both of the following:

• Call a method or set a field - You can have the Check's state passed back to your application by invoking a method that takes a single boolean or by setting a boolean field. When a Check is triggered the boolean value is true. If the Check is not triggered then false is used. Your application can act on this information immediately or store it for later interaction with a Response. See Specifying Sources and Actions for more information.

Note: Shelf Life Check expects a method that takes a Token instead of a boolean.

• Perform a response - There are several immediate responses that can be taken:
  • exit - Exit the application with a random, non-zero return code.
  • hang - Cause the current thread to hang.
  • error - Throw a randomly selected subclass of java.lang.Error.
  • exception - Throw a randomly selected unchecked subclass of java.lang.Exception.
  • none - Take no action (default).
    

    Notes: The randomization of return codes and the selection of a Throwable is performed at time the Check is injected.

     

    Errors and exceptions are thrown with an empty stack trace to conceal their origin.

     

    On Android, exit will only close the top Activity on the activity stack.

     

    The application will close if there is only one Activity on that stack.

When you select both a response and a custom action, the custom action will be called before the response action is taken. If you do not request either of these, then the Check will be skipped and DashO will produce a warning message.

An application can contain multiple uses of the Check with various configurations. Using more than one Check or mixing the Responses will hamper attackers.

General Response Behavior

Separating the Check and Response makes it more difficult for attackers. Having multiple and different Responses scattered throughout the application increases the difficulty of attack. Making those Responses only happen sometimes can make the attack process maddening. DashO lets you configure your Responses to be as simple or as complex as you desire.

The Response adds code that interacts with a Check to separate the Check and Response code. You can add many Responses for the same Check.

• The Response coordinates with the Check via a boolean value. A value set using the action of the Check is retrieved with the source of the Response. If the retrieved value is true then the Response is executed. See Specifying Sources and Actions for more information.

Like the Check, the Response can perform a canned response. In addition, that response can be made conditional based on a probability factor ranging from 0.0 (never) to 1.0 (always) - the default is 1.0.