Skip to main content

Checks

Checks — Options

The Checks — Options page is where you control the settings for injecting Checks into your application. You enable or disable check injection, define annotation processing, and select the runtime Java environment for the application.

Enable Check Injection

Enables or disables Check Injection.

Honor Annotations

Should DashO™ Check annotation references in the code be honored or ignored? Annotations in the code are merged with check settings to determine the full list of checks.

Strip Annotations

Should DashO Check annotation references be removed from the input classes?

Java Environment

This selects the runtime environment of your application and determines which Check implementations and Shelf Life implementation jar will be used.

Standard Check UI

Many of the user interface elements used to configure checks are common between the different available checks (i.e., Debugging Checks, Debug Enabled Checks, Emulator Checks, Hook Checks, Root Checks, Shelf Life Checks, and Tamper Checks).

Check Table

The page for each type of check in the DashO GUI contains a Check Table which describes the currently configured Checks and Responses of a given type.

The Check Tables contain the following columns:

  • Type column shows the type of Check or Response.
  • Description column describes the locations in the code, the methods and classes, where the Check or Response will be injected.
  • Properties column shows the settings for that particular Check or Response.

The tooltips expand to show more details about the locations or properties.

You can add a new check or response by clicking the Add button to the right of the Check Table and selecting the desired type of Check or Response. This will open a dialog to edit the check. You can also click Edit… to edit an existing Check or Response, or click *Delete to remove an existing Check or Response.

Editing Checks

The following options can be configured on each check:

  • Action - An optional custom action. See Specifying Sources and Actions for more information. This action will generally be passed true when triggered and false when not.
  • Response - The response to take when the Check is triggered.
    • None – Do nothing (default).
    • Exit – Exit the application with a random, non-zero return code.
    • Hang – Cause the current thread, which is running the injected Check, to hang indefinitely.
    • Error – Throw a randomly selected subclass of java.lang.Error.
    • Exception – Throw a randomly selected unchecked subclass of java.lang.Exception.
  • Where - Where in the method should the code be injected?
    • Beginning – The beginning of the method (default).
    • End – The end of the method.
    • Beginning and End – Both the beginning and end of the method.
  • Locations - In which methods should the Check be inserted? You can select the methods manually or create a Selection Rule.

Note: 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.

Editing Responses

The following options can be configured on each response:

  • Source - The source to determine if the Check has been triggered. See Specifying Sources and Actions for more information.
  • Response - The response to take when the source indicates the Check was triggered (i.e. true).
    • None – Do nothing (default).
    • Exit – Exit the application with a random, non-zero return code.
    • Hang – Cause the current thread, which is running the injected Response, to hang indefinitely.
    • Error – Throw a randomly selected subclass of java.lang.Error.
    • Exception – Throw a randomly selected unchecked subclass of java.lang.Exception.
  • Probability - The probability the Response (i.e. Exit, Hang, Error or Exception) should happen. Expects a decimal from 0.0 to 1.0 (default: 1.0).
  • Where - Where in the method should the code be injected?
    • Beginning – The beginning of the method (default).
    • End – The end of the method.
    • Beginning and End – Both the beginning and end of the method.
  • Locations - In which methods should the Response be inserted? You can select the methods manually or create a Selection Rule.

Note: 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.

Selection Rule

Configures a Pattern or Regular Expression to determine which method or methods to select.

  • Type - Regular Expression or Pattern.
  • Class Modifiers - The optional class modifiers.
  • Full Class Name - The fully-qualified name of the class.
  • Method Modifiers - The optional method modifiers.
  • Method Name - The name of the method.
  • Method Signature - The method signature.

Notes:
The name and signature fields must contain valid entries.

 

See the description of the Modifiers attribute for values to use for the optional modifiers.

 

See Patterns and Regular Expressions for values to use for the names and the signature.

Checks — Shelf Life

The Checks — Shelf Life page is where you configure Shelf Life Checks in your application.

Checks — Shelf Life uses a standard check table, but also contains some additional settings.

Defaults

The information defined here is used for all individual Shelf Life Checks, unless the checks override these defaults. It is also used to define properties to be added to the generated tokens.

Key File

Enter the location of the Shelf Life key file you received from PreEmptive. This file authorizes you to add Shelf Life Checks to your application.

Expiration Date

Your application can be configured to expire on an explicit date or a certain number of days after a dynamically determined start date. Dates are always in MM/DD/YYYY format regardless of the local convention.

Warning Date

Your application can be configured to issue expiration warnings starting on either an explicit date or a certain number of days before it is due to expire. Dates are always in MM/DD/YYYY format regardless of the local convention.

Properties

You can add arbitrary properties to the expiration token that can be retrieved by your application. To use this feature you need to supply a user defined action to the ShelfLifeCheck – this action method is passed the expiration token where you will be able to retrieve these properties. Note that both the property name and values can contain DashO property references.

Note: The information supplied on this page can be overridden or supplemented by a ShelfLifeCheck or a @ShelfLifeCheck code annotation.

Editing Shelf Life Checks

The UI for configuring a Shelf Life Check has all the standard fields except Response and adds six additional fields:

  • Expiration Date - Absolute date that the application expires in MM/DD/YYYY format.
  • Warning Date - Absolute date that warnings about expiration will start to be emitted in MM/DD/YYYY format.
  • Start Date Source - Source for the start date provided at runtime as a java.util.Date. See Specifying Sources and Actions for more information.
  • Expiration Period - Relative expiration date in number of days since the start date.
  • Warning Period - Relative warning date in number of days until the expiration date.
  • Token Source - Source of the Shelf Life token as a java.io.Reader if managing it externally. See Specifying Sources and Actions for more information.

Checks — Tamper

The Checks — Tamper page is where you configure Tamper Checks in your application. Checks — Tamper uses a standard check table, but individual Tamper Checks have additional properties that you can configure.

Editing Tamper Checks

The UI for configuring a Tamper Check has all the standard fields and adds four additional fields:

  • Keystore - The URL to the keystore; defaults to .keystore in the user's home directory. May reference DashO properties.
  • Keystore Type - The type of the keystore; defaults to the type specified by the JVM running DashO (e.g. JKS or PKCS12). May reference DashO properties.
  • Keystore Password - The password for the keystore. The user interface stores this in an encoded form but the value can be in plain text. May reference DashO properties.
  • Alias - The alias used to store the private key in the keystore. In Android projects, a comma is used to separate multiple aliases. May reference DashO properties.

Notes:
In Standard Mode, if these four fields are left blank, the keystore and alias information from the Output-Signing page will be used.

 

In Android Mode, the DashO Gradle Plugin for Android will pass the keystore and alias information used to sign the application to DashO as default values for Tamper Checks.

 

See Interaction with Signing for more information.

Related to

Was this article helpful?
日本語