Skip to main content

Tamper Check

A Tamper Check is a type of Check that detects whether an application has changed since Dotfuscator processed it.

For example, an attacker might modify application binaries to bypass restrictions or remove licensing information. A Tamper Check can detect this type of modification and react by notifying the application or hindering the attacker.

In other words, Tamper Checks help detect and react to unauthorized tampering of your application.

 Note: Tamper Tester purposefully modifies signed or hashed metadata to verify whether tampering can be detected correctly. It is best to use Tamper Check before re-signing assemblies with Dotfuscator. Otherwise, running Tamper Tester after signing assemblies for production may trigger a strong name exception on re-signed assemblies.

Configure Tamper Checks

You can configure Tamper Checks in two ways:

  • In the source code, add and configure the Check attributes directly in your application.
  • In the Config Editor, add the Check and configure its properties and locations.

Both methods allow you to specify the properties that determine how the Check operates.

To configure a Tamper Check in the Config Editor:

  1. Go to the Checks tab in Dotfuscator’s Config Editor.
  2. Select Add Tamper Check….
  3. Configure the Check properties.
  4. Configure the Check locations.

For the full list of available properties, see the TamperCheckAttribute section in the Check Attributes article.

If you are adding a Tamper Check to a Xamarin Android application, see the Tamper Check for Xamarin Android section in Enhance Protection After Your First Build.

Unsupported Application Types

Dotfuscator can inject Tamper Checks into all .NET assemblies except the following:

  • Assemblies that target .NET 1.0
  • Managed C++ assemblies that contain native and managed code
  • Multi-module assemblies
  • .NET Compact Framework assemblies
  • UWP assemblies
  • Xamarin iOS assemblies

Test Tamper Checks

Testing helps you confirm how your protected application reacts when tampering is detected.

Test .NET Framework applications

For .NET Framework applications, Dotfuscator includes TamperTester.exe, a command-line utility that simulates tampering by modifying assembly metadata.

To test how your protected application reacts to tampering:

  1. Open a command prompt.  If needed, change to the directory of the protected assembly. For example:

    cd C:\YourApp\Dotfuscated

  2. Run TamperTester.exe and specify the assembly for which you want to create a tampered version. Replace AssemblyName.exe with the name of your assembly:

    TamperTester.exe AssemblyName.exe

    Note: Dotfuscator’s installer automatically adds Dotfuscator to the PATH.

  3. Optional: Specify a second argument to define the directory where the tampered assembly is placed.
    If you do not specify a directory, the tampered assembly is placed in a subdirectory named tampered.
    Copy the other output assemblies to the directory of the tampered version. For example:

    xcopy /d *.* tampered
  4. Run the tampered assembly.
  5. Exercise the locations of your Tamper Checks to observe how the application reacts to tampering.
Test Xamarin.Android applications

To test how Tamper Checks react to tampering in Xamarin.Android applications follow the testing path that matches how your application is signed.

If you sign the application after generating the archive

  1. In the project properties, clear Sign the .APK file using the following keystore details.
  2. Create a new application archive in Visual Studio.
  3. Select the newly created archive, then select Distribute....
  4. Select your preferred distribution channel.
  5. Sign the new package with a key that has a different SHA-1 fingerprint than the one specified by DotfuscatorAndroidSigningCertFingerprint.
  6. Deploy the application normally.

When signing the new archive, you can use the debug.keystore file or create a new signing key with custom properties.

If you sign the application in the project properties

  1. Open the project properties in Visual Studio.
  2. Go to the Android Project Properties tab.
  3. Clear Sign the .APK file using the following keystore details.
  4. Build and deploy the application normally.

This causes the deployed application to be signed with the debug.keystore file. This simulates an application that has been tampered with and repackaged.

Note: If you use the default keystore certificate, the SHA-1 fingerprint varies by host. If DotfuscatorAndroidSigningCertFingerprint is configured with the fingerprint from one host and the application is built on a different host, the application always appears tampered.

Related Articles

Related to

Was this article helpful?
日本語