Obfuscate and Harden your .NET Applications against Attacks

App Hardening includes obfuscation and application self-protection functionality. Only a layered approach can provide the protection you need. Review each section below to learn more.

RenamingControl FlowString EncryptionWatermarkingPruningLinking
Tamper Detection & DefenseDebug Detection & DefenseShelf Life


Renaming obfuscation alters the names of methods, variables, etc., making source code more difficult to understand. Dotfuscator uses a deeper form of obfuscation, developed for Dotfuscator and patented by PreEmptive Solutions, called Overload Induction™. Instead of substituting one new name for each old name, Overload Induction renames as many methods as possible to the same name. After this deep obfuscation, the logic, while not destroyed, is beyond comprehension. The following simple example illustrates the power of the Overload Induction technique:

Original Source Code Before ObfuscationReverse-Engineered Source Code After Overload Induction Obfuscation

private void CalcPayroll (SpecialList employeeGroup) {

   while(employeeGroup.HasMore()) {

      employee = employeeGroup.GetNext(true);





private void a(a b) {

   while (b.a()) {

      a = b.a(true);






Traditional control flow obfuscation introduces false conditional statements and other misleading constructs in order to confuse and break decompilers. This process synthesizes branching, conditional, and iterative constructs that produce valid forward (executable) logic, but yield non-deterministic semantic results when decompilation is attempted. Control Flow obfuscation produces spaghetti logic that can be very difficult for a cracker to analyze.

Dotfuscator employs advanced control flow obfuscation. In addition to adding code constructs, Dotfuscator works by destroying the code patterns that decompilers use to recreate source code. The end result is code that is semantically equivalent to the original but contains no clues as to how the code was originally written. Even if highly advanced decompilers are developed, their output will be guesswork.

Original Source Code Before ObfuscationReverse-Engineered Source Code After Control Flow Obfuscation

public int CompareTo(Object o) {

   int n = occurrences –


   if (n == 0) {

      n = String.Compare(word,((WordOccurrence)o).word);




public virtual int _a(Object A_0) {

   int local0;

   int local1;

   local 10 = this.a – (c) A_0.a;

   if (local0 != 0) goto i0;

   while (true) {

      return local1;


   i1: local10 = System.String.Compare(this.b, (c) A_0.b);

   goto i0;



Dotfuscator allows you to hide user strings that are present in your assembly. A common attacker technique is to locate critical code sections by looking for string references inside the binary. For example, if your application is time locked, it may display a message when the timeout expires. Attackers search for this message inside the disassembled or decompiled output and chances are when they find it, they will be very close to your sensitive time lock algorithm.

Dotfuscator addresses this problem by allowing you to encrypt strings in these sensitive parts of your application, providing an effective barrier against this type of attack.

Since string encryption incurs a slight runtime penalty no string encryption is performed except on the parts of the application that you specify.


Watermarking helps track unauthorized copies of your software back to the source by embedding data such as copyright information or unique identification numbers into a .NET application without impacting its runtime behavior. Dotfuscator’s watermarking algorithm does not increase the size of your application, nor does it introduce extra metadata that could break your application.


Small applications download faster, install faster, load faster and run faster. Dotfuscator's pruning feature statically analyzes your code to find the unused types, methods, and fields, and removes them. Dotfuscator also removes debug information and non-essential metadata from a MSIL file as it processes it, making the application smaller and reducing the data available to an attacker.


Dotfuscator can combine multiple input assemblies into one or more output assemblies. Assembly linking can be used to make your application even smaller, especially when used with renaming and pruning, and can simplify deployment scenarios.

For example, if you have input assemblies A, B, C, D, and E, you can link assemblies A, B, and C and name the result F. At the same time, you can also link D and E and name the result G. The only rule is that you can't link the same input assembly into multiple output assemblies.


Dotfuscator injects code that verifies your application’s integrity at runtime. If it detects tampering, it can shut down the application, invoke random crashes (to disguise that the crash was the result of a tamper check), or perform any other custom action. For customers using PreEmptive Analytics, it can also send a message to the service to indicate that tampering was detected.

For more information on Tamper Defense, see our Tamper Defense Fact Sheet.


PreEmptive Solutions offers a powerful anti-debugging solution that protects both the application and its data while delivering near real-time alerts and analytics directly into your preferred analytics services – including Application Insights, HockeyApp, Microsoft TFS, Google Analytics, Twitter, New Relic, and PreEmptive Analytics Workbench – to name just a few.


Shelf Life Warn

Shelf Life is an application inventory management function that allows you to embed expiration, or de-activation, and notification logic into an application. Dotfuscator injects code that reacts to application expiration by exiting the application and/or sending a PreEmptive Analytics Service message. This feature is particularly helpful with beta or evaluation applications. Users can schedule an application’s expiration/de-activation for a specific date and optionally issue warnings to users that the application will expire/de-activate in a specific number of days.