PreEmptive Protection - Dotfuscator
Community Edition

Understanding Checks

Dotfuscator's Checks feature adds pre-built runtime validations to your application, without requiring you to write any additional code. This process is known as code injection. The application that undergoes this process is known as an injected application. At runtime, the code injected into the application will check for an invalid application state; if such a state is found, the injected code can then call application code, send a message to a PreEmptive Analytics endpoint, and take action to impede the attacker.

In contrast to obfuscation, which is concerned with protecting the application "at rest" (i.e., as assembly files), Checks are concerned with protecting the application while it runs.

Check Kinds

There are several kinds of Checks that Dotfuscator can inject into an application. For details, including what application types are supported, see each kind's page:

The rest of this page covers aspects that apply to multiple Check kinds.


To add Checks to your code:

  1. Enable the Process PreEmptive analytics attributes injection option.
  2. Using either in-code attributes or extended attributes, add the appropriate Check attributes to your methods.
  3. Configure the properties of these attributes appropriately.
  4. Build your Dotfuscator project.

The output assemblies will now contain Checks that will run whenever the annotated methods are called.

Application Notification

All Checks provide a way for the application code to be informed of the Check's result. This happens before Dotfuscator's pre-built responses to invalid application states (see the Telemetry and Actions subsections). In this way, the application can react to an invalid state in a customized way, such as by disabling application features or by sending third-party analytics.

The result of a Check is communicated via a sink defined with the relevant Check attribute called ApplicationNotificationSink. The sink is given a bool value which is true if the Check detected an invalid state and false otherwise.

For instance, consider the following attribute and its properties:

At runtime, when HelloWorld.Hello.VerifyDebugging is called, the injected code will check whether a managed debugger is attached. The result of this check will be passed to the static method HelloWorld.Hello.OnDebuggingVerified(bool) with an argument of true if a debugger was detected and false otherwise. The OnDebuggingVerified method can then perform application-specific behavior based on the result.

Note: Application Notification for Shelf Life Checks is exclusive to Dotfuscator Professional Edition.


Checks can be configured to send messages to a specified PreEmptive Analytics Endpoint when they detect invalid application states. For more information, see the Check Telemetry page.


Checks can also be configured to react to invalid application states. These injected responses are known as Check Actions, and they occur after any Application Notification and Check Telemetry behaviors.

Check Actions are configured by a Check attribute's Action property. Only two values for this property are supported in Dotfuscator Community Edition:

  • "None": The injected code will return control to the application after the Check, even if the Check detected an invalid application state.
  • "Exit": When a Check detects an invalid application state, the injected code will cause the application to exit immediately with exit code 0.

Additional Actions, such as hanging the executing thread or throwing a random exception, are available in Dotfuscator Professional Edition. Professional Edition also supports Action Probability, which causes the injected Actions to occur only some of the time, further confusing attackers.

Note: Shelf Life Checks do not support Actions. However, you can still configure them to exit the application if the application is expired.

Dotfuscator Version Copyright © 2017 PreEmptive Solutions, LLC