Dotfuscator User's Guide
Debugging Check

With the Debugging Check, Dotfuscator injects code that detects if a managed debugger is attached to the application at runtime.

To indicate where in your application's code you would like to place a Debugging Check, annotate the method with the DebuggingCheck attribute, either by using a Dotfuscator GUI, or by placing the attribute in your code:

DebuggingCheck Attribute
Copy Code
[PreEmptive.Attributes.DebuggingCheck()]
public void DoStuff() { ... }

DebuggingCheck attributes are not required at runtime; therefore, Dotfuscator strips them from the output application by default.

At runtime, if the injected Check detects a debugger, it can notify the application and take defensive action, such as by shutting down the application.

Application Notification

After the Check occurs, the result can be given to application code via a Application Notification Sink. For an overview of Sinks, see the Application Notification section.

The DebuggingCheckAttribute's base class RuntimeCheckAttribute defines three properties for specifying an Application Notification Sink:

These properties are described in more detail in the RuntimeCheckAttribute section of the custom attribute reference.

The Application Notification Sink settings are optional. If they are omitted, the application is not notified when the debugging check is executed.

Note that configuring the ApplicationNotificationSinkElement to DefaultAction is not permitted for this Check. A build error will be raised if this value is used.

Telemetry

Debug Checks support sending telemetry to a PreEmptive Analytics endpoint. Specifically, if a Check detects a debugger, an exception message can be sent to a specified endpoint, enabling tracking of people trying to reverse engineer your application.

Debug Check telemetry may be enabled or disabled for an entire Dotfuscator project using the "Send Debug Check Messages"  Global Setting.

This Global Setting is disabled by default, and must be enabled for telemetry to function.

Additionally, in order for the Debug Check to know where to send the message, the PreEmptive Analytics API must be configured:

  1. The assembly must have a BusinessAttribute and an ApplicationAttribute to state the CompanyKey and Application Guid for transmission.
  2. Some method in your application must have a SetupAttribute. Debug Check messages will transmit to the endpoint specified here. If you want to use a SetupAttribute that has the EndpointSourceElement property set to something other than None, DefaultAction, or ApplicationSetting, you must ensure that the method with the SetupAttribute will be called prior to any calls to the method with the DebuggingChecks attribute configured.

Even if the user opts-out of PreEmptive Analytics, Debug Check exception messages will still be transmitted.

Telemetry supports extended keys (i.e. user-defined custom data). The DebuggingCheck attribute defines four properties for specifying extended keys:

An application can contain any number of DebuggingCheck attributes. In the event that an application has an attached debugger and multiple Checks trigger, multiple messages from the same application session will be sent with the same group ID.

Actions

Finally, the Check itself may take action to respond to a debugger's presence, such as by exiting the application. For an overview of Actions, see the Actions section.

The DebuggingCheckAttribute's base class RuntimeCheckAttribute defines two properties for specifying an Action:

These properties are described in more detail in the RuntimeCheckAttribute section of the custom attribute reference.

The Action settings are optional. If they are omitted, the application continues on after the Check, even if an attached debugger was detected.

Supported .NET Application Types

Dotfuscator can inject Debug Detection code for all .NET assemblies except for the following:

See Also

Attribute Reference

 

 


© 2016 PreEmptive Solutions, LLC. All Rights Reserved.

www.preemptive.com