Obfuscation Question

[Ayron]

Greetings. I have an application that I'd like to obfuscate. It has
many .net assemblies. Upon obfuscating all of the assemblies and
running the app, I get odd data output in some lists and fatal
exceptions thrown when pressing buttons, opening certain forms, etc.
The same code runs without exceptions in the un-obfuscated format. It
seems to me that obfuscation wouldn't have made it this far if this is
the result, so can someone let me know what I may be doing wrong?
Thanks.

-ak

 

[Guest]

I've used code obfuscation myself in a few projects and have not noticed any
problems. Obfuscation in .NET generally just renames your class and member
names so that anyone who trys to "decompile" your assemblies using a
System.Reflection-based utility will see your code basically exactly as you
have programmed it except it will be difficult to read becuase methods and
objects will have un-informative names like a.aa(a, b, c). This alone should
not effect how .NET's realtime IL compiler interprets your code into machine
language. In other words, obfuscation generally only modifies your assemblies
"meta-data" and not the actuall code data.

There is at least one exception that i can think of where obfuscation would
break your code. If your code actually uses System.Reflection to discover the
real names of classes and members, this would be a problem becuase at runtime
these names are different than what you coded them to be becuase of the
obfuscation renaming scheme.

A couple things you might want to try:

1) If you are using RemteSoft DotFuscator Community Edition that comes with
some versions of VS.NET, either try to get your hands on the retail version
of DotFuscator, or try another Obfuscator. I often use "Salamander" from
Remotesoft.

2) If you are cryptographically signing your assemblies using VS.NET's tools
(or linking to any assemblies that are signed), you should delay-sign the
assembly, compile, obfuscate, and finally sign the assembly with the .NET
command line tools.

3) If your obfuscator has an option for encrypting strings, turn that option
off.

4) Compile your assemblies in "Release" mode not in debug mode. As far as i
can imagine, .NET's realtime debugger uses Reflection of the assemblies
metadata to give you infomative messages about the types and members throwing
errors. If this is true, obfuscation could potentially "break" the debugger.

-Nate

 

[Cowboy \(Gregory A. Beamer\)]

You have to watch the settings of the obfuscator. Anything that is touched
outside of the class should not be obfuscated. What this means, if you want
a truly obfuscated class, is your public methods contain little code and
direct work to private, internal functions, which can be obfuscated.

--
Gregory A. Beamer

*************************************************
Think outside the box!
*************************************************

 

[Ayron]

Thanks, Nate. Your point where code using reflection can be affected by
obfuscation hits the nail on the head. I'm using a custom DataListView
control (originally authored by Rocky Lohtka) that uses reflection to
"bind" a ListView to a collection. This control is rather ubiquitous in
the application, so this would certainly explain the anomalies. Sounds
like we've encountered the limits of obfuscation technology.

 

[Ayron]

Thanks for the post, Gregory. Nice to have responses for delimmas.

 

[jpierce]

Hi Greg,

The obfuscation feature in our Decompiler.NET product automatically
factors the bodies of public members into private ones and obfuscates
their calls in the same assembly while still exposing the public
members as stubs that call their private obfuscated implementation
members. You can download a free trial version from our web site and
see this behavior for yourself at http://www.junglecreatures.com/

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/