DashO Tamper checks detect whether application code is signed with an expected certificate. The protected output must be signed by DashO or by a signing process that runs after DashO. Configure an immediate response, pass the result to application code, or store the result for separate Tamper responses.
Before you begin
- Identify the certificate that signs the application distributed to users.
- If DashO signs the output JARs, configure Output Signing. DashO can reuse that information for Tamper checks.
- If another process signs the output after DashO, provide the corresponding keystore, type, password, and alias in the Tamper check configuration.
- For Android applications distributed through Google Play App Signing, use the app-signing certificate rather than only the upload certificate.
Configure a Tamper check
Configure the check on Checks > Tamper in DashO, or add a TamperCheck annotation:
private static boolean tamperFlag;
@TamperCheck(action="@tamperFlag")
public static void main(final String[] args){
}
@TamperCheck(response=ResponseType.Hang)
private int computeResult(){
}To respond immediately, set a response on TamperCheck instead of, or in addition to, storing the result.
private static boolean tamperFlag;
@TamperCheck(action="@tamperFlag")
public static void main(final String[] args){
}
@TamperResponse(source="@tamperFlag", response=ResponseType.Exit, probability=0.05f)
private int computeResult(){
}
@TamperResponse(source="@tamperFlag", response=ResponseType.Error, probability=0.1f)
private FileInputStream readInput(){
}Provide signing information for an external signing process
Tamper Check verifies at runtime that the code was signed with the expected certificate. If DashO signs the resulting JARs, no additional configuration is required.
If another process signs the JARs after obfuscation, use the additional attributes of the TamperCheck annotation to provide the signing information. This allows DashO to retrieve the key information needed for runtime verification. These settings are similar to those on the Output Signing page.
@TamperCheck(action="@tamperFlag", storepass="${master.psw}",
storetype="JKS", alias="ProdKey")
public static void main(final String[] args){
}Note: DashO stores keystore passwords entered in its user interface in encoded form unless they contain a property reference.
Android signing considerations
Tamper Check requires access to the application's context through a getApplicationContext() method on the class where the check is injected. Classes extending android.context.Context, such as android.app.Activity, android.app.Application, and android.app.Service, inherit this method. For other classes, add a getApplicationContext()method that returns a valid Context.
Tamper Checks work on libraries that remain separate from an application. If a library (AAR) containing Tamper Checks is merged into an application (APK), the application must be signed with the certificate expected by the checks; otherwise, they report tampering.
If you use key rotation and your application requires Android Pie or later, configure DashO to use the last alias in the rotation. Otherwise, use the first alias.
Google Play App Signing
With Google Play App Signing, you sign your app or app bundle with an upload key before submitting it to Google. Google then signs the APKs distributed through Google Play with an app signing key. Configure Tamper Check to verify the app signing certificate.
Download the app signing certificate from the Google Play Console, import it into a keystore as a trusted certificate, and configure Tamper Check to use it.
Note: This configuration reports tampering if you run an app signed with the upload certificate. To accept both certificates, specify their aliases as a comma-separated list, for example, alias="signingAlias,uploadAlias".
Key Upgrade
Google Play allows a one-time upgrade of your signing key. Previously installed applications use the old key, while new installations use the new key. To support both, import both certificates into the keystore and configure their aliases, for example, alias="newAlias,oldAlias".
Code Generation
If your application uses code generation, verify that it works with signed JARs before adding Tamper Detection. You may need to sign the JARs that generate code with the same certificate. For example, a Spring-based application may require signing spring-core-4.0.1.RELEASE.jar or the equivalent JAR for your version.
Custom Class Loading
If your application uses a custom class loader, ensure that it loads the signing certificates.
For example, in an OSGI application using Eclipse Equinox, configure osgi.signedcontent.support to include at least certificate, and do not set osgi.support.class.certificate to false.