FREQUENTLY ASKED QUESTIONS

Is Dotfuscator a profiling tool?
Does Dotfuscator change the source code of my application?
Does Dotfuscator require me to distribute any additional libraries or programs with my final application?
How does Dotfuscator obfuscate assemblies?
How does Dotfuscator work on API libraries?
Can Dotfuscator process applications that use reflection?
My application uses managed resources. Can I still use Dotfuscator?
How do I figure out an obfuscated stack trace that I get back from the field?
How do I distribute a patch to my obfuscated program?


Is Dotfuscator a profiling tool?

No. Dotfuscator is a .NET application optimization and obfuscation system. A common misconception is that Dotfuscator is comparable with profiling systems. Dotfuscator is not a profiler. A profiler tells you where your code bottlenecks are (often due to poor performing algorithms, etc).

Does Dotfuscator change the source code of my application?

No. Dotfuscator .NET obfuscator works solely on compiled .NET assemblies. Your source code is not needed (or affected).

Does Dotfuscator require me to distribute any additional libraries or programs with my final application?

No. The output files produced by Dotfuscator are standard .NET assemblies. They will run under the .NET Common Language Runtime with no additional dependencies.

How does Dotfuscator obfuscate assemblies?

Dotfuscator uses all of the traditional obfuscation techniques. It renames all possible method and field names. It is highly configurable so you can choose a given method (e.g. all publics) to be renamed or not. It is not limited to private methods.

Dotfuscator also includes our patented Overload Induction renaming system. There is simply no better renaming algorithm for code protection and size reduction! No obfuscator can prevent decompilation in all cases; however, Dotfuscator makes the decompiled output extremely difficult to read. It makes decompilers work more like disassemblers!

How does Dotfuscator work on API libraries?

You can still take advantage of renaming your non-public types, methods and fields. Dotfuscator obfuscation is very configurable in this respect. Dotfuscator has a convenient "Library" option that automatically prevents all public methods from being renamed. If this doesn't quite fit your application, you can customize the exclusion rules at various levels of granularity. Not to mention control flow obfuscation and string encryption go a long way to protect code without renaming.

Can Dotfuscator process applications that use reflection?

Yes. Transforms such as Control Flow, String Encryption are not affected by reflection. But, depending on how you implemented the reflection there may be some configuration work in order to use renaming on your public methods. So how can I use reflection and use renaming without any configuration on my part? There are a number of ways to get a reference to a Type, and not all require the use of a lookup by name.

My application uses managed resources. Can I still use Dotfuscator?

Yes. If the resource is embedded in the assembly, the process is automatic. If it is embedded inside an external file, then the file must be in the same directory as the referencing module. If the resource is embedded inside another assembly, then that assembly must be one of the input assemblies.

How do I figure out an obfuscated stack trace that I get back from the field?

Dotfuscator and DashO include the ability to perform stack trace translations.

How do I distribute a patch to my obfuscated program?

Given that obfuscation operates on an entire program, changing program elements (for example, deleting a class) can change the renaming scheme across the board.

Dotfuscator and DashO include incremental-obfuscation that forces Dotfuscator and DashO to use the same renaming scheme as it did on a previous run. Using this feature, you can create patches for obfuscated applications.