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 sending incident telemetry, 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 code injection.
Then, configure the Checks in the Config Editor, or by annotating your source code with
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
- .NET Core assemblies
- Silverlight assemblies
- Unity assemblies
- UWP assemblies
- Windows Phone assemblies
- WinRT assemblies
- Xamarin iOS assemblies
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:
Open a command prompt.
If not already there, change to the directory of the protected assembly. For instance:
TamperTester.exe AssemblyName.exe, where
AssemblyName.exeis the name of the assembly for which you want to create a tampered version.
Note: Dotfuscator's installer automatically adds Dotfuscator to the PATH.
- 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
The utility creates a tampered version of the assembly.
Copy other output assemblies to the directory of the tampered version. For instance:
xcopy *.* tampered /d
Run the tampered assembly and exercise the locations of your Tamper Checks to observe how the application reacts to being tampered.
To test how the Tamper Checks injected into your application will react to tampering:
If you sign your application after generating the archive:
Uncheck "Sign the .APK file using the following keystore details" in your project's Properties.
Create a new application archive in Visual Studio.
Select the newly created archive, and select "Distribute..."
Select your preferred distribution channel.
Sign the new package with a key containing a different SHA-1 fingerprint than the one specified by
Deploy the application normally.
When signing the new archive you may use the
debug.keystorefile, 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:
Open your project's Properties in Visual Studio.
Navigate to the "Android Project Properties" tab.
Uncheck the box next to "Sign the .APK file using the following keystore details."
Build and deploy the application normally.
This will cause the deployed application to be signed with the
debug.keystorefile, essentially simulating an application that has been tampered with and repackaged.