Using the GUI
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.
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:
The output assemblies will now contain Checks that will run whenever the annotated methods are called.
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
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
OnDebuggingVerified method can then perform application-specific behavior based on the result.
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:
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.