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
booleanor by setting a
booleanfield. When a Check is triggered the
true. If the Check is not triggered then
falseis 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.
- 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
exception- Throw a randomly selected unchecked subclass of
none- Take no action (default).
Notes: The randomization of return codes and the selection of a
Throwableis performed at time the Check is injected.
Errors and exceptions are thrown with an empty stack trace to conceal their origin.
exitwill only close the top
Activityon the activity stack.
The application will close if there is only one
Activityon 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.
Response adds code that interacts with a
Check to separate the Check and Response code.
You can add many
Responses for the same
Responsecoordinates with the Check via a
booleanvalue. A value set using the
Checkis retrieved with the
Response. If the retrieved value is
truethen the Response is executed. See Specifying Sources and Actions for more information.
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