Does the exe you get out of obfuscation programs vary in speed?

Question

There are a number of obfuscation programs out there for .Net and I've tried one, my exe seems much slower when obfuscated. Do all obfuscation programs have the same effect or have I chosen a bad one? I'm hoping some are better than others, if you know of a fast one let me know.

Cheers

Answer 1

Obfuscation shouldn't change the runtime performance of your code. If it is then you've got a bad obfuscator that's doing much more than just obfuscating. All obfuscation should do is make your IL hard to read.

Answer 2

There are different obfuscation methods that tools can use. There are the simple rename methods that should not affect performance in any way. Other methods might change the flow of the code. That could have a negative impact on performance. You might want to check out other obfuscators and try out different settings.

Answer 3

Disclaimer: my employer is PreEmptive Solutions, the creator of the Dotfuscator .NET obfuscator.

It can depend on the obfuscator you use and the options you enable in it. I am going to speak from experience with Dotfuscator.

There can be load time and memory footprint improvements of obfuscated assemblies if you use renaming and removal, partly because all/most of your methods, fields, etc are renamed to much smaller names (for example "ThisVeryLongMethodName(SomeVeryLongParameterName)" becomes "a(a)" so you gain some benefit in assembly size and usually with load time. In addition with removal you remove methods, etc. that are never call and again decrease the size of your binaries.

String encryption can adversely affect runtime performance to a slight degree as the strings must be converted back to human readable text at runtime.

If you use any other systems/techniques like Microsoft SLP's secure vm technology to render methods unreadable that will also incur a runtime performance penalty due to the secure vm.

Other obfuscation tools that do not produce managed code assemblies as an output but instead rely on a native code loader to "preprocess" their output can also incur an runtime performance hit (especially at load time).