Overview
Dotfuscator works by altering the code patterns that decompilers use to recreate source code. Dotfuscator 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.
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.
The goal of this feature is to prevent automatic decompilation of MSIL back to high-level source. End users can still view the MSIL itself, but it is harder to fully comprehend and make large changes in functionality.
Example:
| Before | After (with Renaming) |
|---|---|
 |
 |
Limitations
It is important to test application performance after Control Flow obfuscation, particularly of any code that is executed many times (such as a game loop or a computationally/algorithmically intensive method).
Control Flow obfuscation is only able to effectively defeat decompilers when the method contains sufficiently many basic blocks, among other requirements.
It is also not fully deterministic based on input IL, so two input methods with the same IL contents may result in different (but functionally equivalent) IL listings after obfuscation.
Exclusions
Control Flow Exclusions work in the same way as Renaming Exclusions, with both specific exclusions and custom rules. However, Control Flow Exclusions are only applicable to methods. If users see performance degradation during testing, then exclusions should be applied to any methods or classes where computationally intensive work is done (basically any situation in which the CPU is the limiting factor on performance).
Options
High is the only level designed to defeat automatic decompilers. Medium or Low may be used if High causes performance degradation that cannot be resolved using exclusions,or for debugging purposes if Control Flow is believed to be the cause of a runtime error.