Tamper Check

A Tamper Check is a type of Check that detects if the application has changed since it was processed by Dotfuscator.

For example, if an attacker modifies the application binaries to circumvent restrictions or remove licensing information, a Tamper Check can detect the modification and react by notifying the application and hindering the attacker. In other words, a Tamper Check detects and reacts to unauthorized tampering of your application.

Configuring Tamper Checks

To have Dotfuscator inject Tamper Checks into your application, first enable Checks. Then, configure the Checks in the Config Editor or by annotating your source code with TamperCheckAttribute. Both of these methods allow you to specify various properties that determine how the Check operates; for a full listing, see the TamperCheckAttribute section of the Check Attributes page.

If you are adding a Tamper Check to a Xamarin Android app, see the Tamper Check for Xamarin Android section on the Enhance Protection page for more information.

Unsupported Application Types

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

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

Testing

.NET Framework

To test how the Tamper Checks injected into your application react to assembly tampering, Dotfuscator includes TamperTester.exe, a command line utility to simulate tampering by modifying the assembly's metadata.

To test how your protected application reacts to tampering:

1. Open a command prompt.

2. If not already there, change to the directory of the protected assembly. For instance:

   cd C:\YourApp\Dotfuscated

3. Type TamperTester.exe AssemblyName.exe, where AssemblyName.exe is the name of the assembly for which you want to create a tampered version.

• You may also specify, as a second argument to the utility, the directory where the tampered assembly will be placed. If not specified, the tampered assembly is placed in a subdirectory of the assembly's directory named tampered.

4. The utility creates a tampered version of the assembly.

5. Copy other output assemblies to the directory of the tampered version. For instance:

   xcopy /d *.* tampered

6. Run the tampered assembly and exercise the locations of your Tamper Checks to observe how the application reacts to being tampered.

Xamarin.Android

To test how the Tamper Checks injected into your application will react to tampering:

• If you sign your application after generating the archive:

  1. Uncheck "Sign the .APK file using the following keystore details" in your project's Properties.

  2. Create a new application archive in Visual Studio.

  3. Select the newly created archive, and select "Distribute..."

  4. Select your preferred distribution channel.

  5. Sign the new package with a key containing a different SHA-1 fingerprint than the one specified by DotfuscatorAndroidSigningCertFingerprint.

  6. Deploy the application normally.

  When signing the new archive you may use the debug.keystore file, although you will also have the ability to create a new signing key with custom properties.

• If you sign your application in your project's Properties:

  1. Open your project's Properties in Visual Studio.

  2. Navigate to the "Android Project Properties" tab.

  3. Uncheck the box next to "Sign the .APK file using the following keystore details."

  4. Build and deploy the application normally.

  This will cause the deployed application to be signed with the debug.keystore file, essentially simulating an application that has been tampered with and repackaged.