Tamper and Debug Detection both support pre-defined Actions that the Check can take when its condition is met.
Note that if an Action is defined for a Check, it will be the last thing the Check does. Thus, you can specify an Application Notification Sink along with an Action. The Action will be executed after the Application Notification Sink is called.
The Action property of the relevant Check's attribute specifies what kind of action should be taken when the Check's condition is met (e.g., when a Tamper Check detects tampering).
The possible Actions are given in-code by the CheckAction enumeration.
The Check will return control to the application code even if the condition was met. No additional action will be taken.
This is the default value.
If the condition was met, the application exits immediately with exit code 0.
If the condition was met, the Check throws an exception. The exception is created and injected during the Dotfuscator build, emulating a real .NET System exception.
When the Exception action is used, Dotfuscator makes an effort to hide the thrown exception's stack trace, to prevent further reverse-engineering. However, the stack trace will be visible in some places, such as in the default .NET unhandled exception handler. You may want to catch and handle exceptions thrown by the instrumented code; the exceptions created by this action will appear to have no stack trace when handled by user code.
If the condition was met, the thread the Check was made on hangs indefinitely.
The ActionProbability property of the relevant Check's attribute specifies how likely the Action is to happen. By using a value less than 1.00, the Check is made less predictable to an attacker.
This value is a double between 0.00 (never) and 1.00 (always). For example a value of 0.50 indicates a 50% chance of the Action executing, while a value of 0.83 would indicate a 83% chance of it executing, etc.
ActionProbability is 1.00.