Tracing obfuscated assemblies  
Jeff Key
11/16/2002 1:07:48 AM
So I've run into another obfuscation issue.

Just a note:  Some of the issues I'm running into are because I'm using
a very basic, free obfuscator[1] that doesn't have many advanced
features.  Some of the more expensive ones (several thousand dollars)
solve some of these issues, but I think it's good to know what's going
on behind the scenes just in case you run into problems later.  All
obfuscators work differently, but they essentially wind up doing the
same stuff.

I just put in tracing for most of my "important" methods to follow
entry/exit of methods, etc.[2]  The problem is that the string literals
are viewable in the obfuscated code, so even if your method signatures
are meaningless, the person viewing the code can still see "Entering
MyReallyImportantMethod()" or whatever and possibly figure out an
algorithm you'd rather not have them see.

Unfortunately, the workaround is a bit tedious, but it works.

You create an internal class (so it's obfuscated) and make public,
read-only string fields that contain the strings you'd like to output
via trace.  You must use static readonly instead of const[3] because
const is dereferenced at compile time and the string literals are placed
inline, which is exactly what we're trying to avoid.  You then call the
trace methods with using the class:

Trace.WriteLine(MyStaticStringClass.MyStaticString);

When viewed in Anakrino or ILDASM, you get the desired result:

Trace.WriteLine($.$);

And that is a good thing.

-jk


[1] Dan Appleman's http://www.abderaware.com/download/obfuscator.zip
(hosted @ abderaware, Zane Thomas's new company)
[2] I'm going to post that tracing class I wrote to my website; it
provides asp.net-like nested tracing w/performance numbers, if so
desired.
[3] I wrote a thing a while back about readonly vs static.  If you're
interested, it's in the archives.  If you can't find it, let me know.
It's very important you know the implications of using consts
		
Back to dotnet