Moving Up To Pro

Dotfuscator Professional includes these additional features:

• Runs independently of VS.NET
• Employs various renaming schemes
• Portable debug-file support
• Prefix renaming
• Support for managed code
• Stack trace translation
• Report files in XML and HTML
• Code compacting and removal of unused code (sometimes called pruning)
• Support for Compact .NET
• Flow logic obfuscation
• Overloading induction
• Incremental obfuscation
• Seamless satellite assembly obfuscation
• String encryption
• Breaks ILDASM and tools like Reflector

It is the last few features—obfuscation of flow logic, overloading induction, string encryption, and the capability of breaking decompilers—that make Dotfuscator Professional the serious obfuscator's tool.

What are these? Flow logic obfuscation changes if, for, and while constructs, yielding non-deterministic results when code is decompiled. The result is that the code still executes as before, but decompilers cannot reproduce the original code.

Overloaded induction results in up to 15% more redundancy in replacing your real names with gibberish names. Combining this option with the unprintable naming scheme makes it very difficult to differentiate names in the IL.

String encryption scrambles the text in your application. For example, imagine that a cracker was decompiling your code, looking for authentication text. This feature makes it difficult to find text related to authentication (with the intention of bypassing the associated logic). End result? It's a lot harder for a cracker to avoid your application's registration and authentication.

Dotfuscator uses known ways to break ILDASM. If someone tries to view the code you obfuscated with Dotfuscator Pro, ILDASM will crash. That may be the first time you're glad a progam blew up!

Collectively, employing maximal obfuscation has a dramatic effect on ILDASM and Reflector's ability to disassemble and decompile .NET assemblies. Figure 5 shows the ILDASM view of our Hello, World sample obfuscated with Dotfuscator Professional. If you click on the section prefixed with _Deleted, ILDASM crashes.

Figure 5: ildasm.exe's view after obfuscation.

Figure 6 shows the same code in Reflector. Notice the ominous message received when attempting to decompile the main method. (We only know it is the main method because the sample program only has one method that takes an array of strings, the Main method.)

Figure 6: Hello, World in Reflector after maximal obfuscation.

A new assembly was used to demonstrate maximal obfuscation. The reason is that Reflector caches assemblies; instead of opening the obfuscated assembly and showing the actual IL, Reflector was showing cached, unobfuscated IL. Using a new assembly forced Reflector to use a non-cached version of the code. Clearly, third parties should never have an unobfuscated version of the code, so this won't present an actual problem in practice.