PreEmptive Protection - Dotfuscator 4.31
User Guide


Dotfuscator is capable of renaming all classes, methods, and fields to short names. This makes decompiled output much more difficult to understand and makes the resulting executable smaller in size.

Most commercial obfuscators employ a renaming technique that applies trivial identifiers that can be as short as a single character. As the obfuscator processes the code, it selects the next available trivial identifier for substitution. This seemingly simple renaming scheme has a key attribute: it cannot be reversed. While the program logic is preserved, the names become nonsense, hampering all attempts to understanding the code.

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 Obfuscation:

private void CalcPayroll(SpecialList employeeGroup) {
   while (employeeGroup.HasMore()) {
        employee = employeeGroup.GetNext(true);

Reverse-Engineered Source Code After Overload Induction Obfuscation:

private void a(a b) {
    while (b.a()) {
        a = b.a(true);

The example shows that the code is obfuscated and compacted, a positive side effect of renaming. For example, if a name is 20 characters long, renaming it to a() reduces its size by 95%. Renaming also saves space by conserving string heap entries. Renaming everything to "a" means that a is stored only once, and each method or field renamed to a can point to it. Overload Induction enhances this effect because the shortest identifiers are continually reused.

Many customers report a full third of all methods being renamed to "a()".

There are several distinct advantages to this methodology:

  • Renaming makes decompiled output difficult to understand. Renaming to unprintable characters or illegal names in the target source language is futile since decompilers are equipped to re-rename such identifiers. Considering that Overload-Induction could make one of three method names "a()", understanding decompiled output is difficult.
  • Overload-Induction has no limitations except those that exist in all renaming systems.
  • Since overload-induction tends to use the same letter more often, it reaches into longer-length names more slowly (e.g. aa, aaa, etc.). This also saves space.

Overload-Induction’s patented algorithm determines all possible renaming collisions and only induces method overloading when it is safe to do so. The procedure is provably irreversible. In other words, it is impossible (even via running Overload-Induction again) to reconstruct the original method name relationships.

Dotfuscator also provides Advanced Overload-Induction™ by allowing a method’s return type or a field's type to be used as a criterion in determining method or field uniqueness. This feature can allow up to 15% more redundancy in method and field renames. In addition, since overloading on method return type or field type is typically not allowed in source languages (including C# and Visual Basic), this further hinders decompilers.

Dotfuscator Version Copyright © 2017 PreEmptive Solutions, LLC