Gabriel Torok - Protecting .NET applications through obfuscation

This is interesting, but how does one go about debugging an application which is dotfuscated? I am used to internal apps where we can look at a call stack, list of 30 recent functions and runtime comments for our apps. 

What is needed to provide a level of error information when the function names and strings are unreadable?

MS, please include Dotfuscator Pro in MSDN subscription.
At least, please include a string encryption and an ILDASM breaker in Dotfuscator community version of Visual Studio 2005!
Please!!!!!

kidzi wrote:

This is interesting, but how does one go about debugging an application which is dotfuscated? I am used to internal apps where we can look at a call stack, list of 30 recent functions and runtime comments for our apps. 

What is needed to provide a level of error information when the function names and strings are unreadable?

When you debug, it uses the original IL, not the obfuscated one, so internal debugging will remain  the same.

I can't wait to see all the new features coming out!

XenoCode's obfuscator provides a mapping file feature enabling you to convert back to readable information.

For more details on the file mapping feature:

http://www.xenocode.com/en/Man/advanced_topics/debugging_xenocode_processed_assemblies.htm

Lionel Lindemann
XenoCode Europe
http://www.xenocode.com

OK. I re-read my post and I was a bit unclear. I meant debugging an issue from a user. The situationwould be f an end-user is running the app and it blows up - they would be running the obfuscated one.  How would you translate an error at end-user runtime into something you can work with back in the development area?

There are a couple things you can do to facilitate debugging Dotfuscated applications.  The first best addresses your question:

1) Use the stack trace decoding tool:


When you Dotfuscate your code, one of the outputs is a map file-- it is an XML file that contains a mapping between the new names and the original names.  You should keep this file in a safe place (like version control) after you ship your application.


Dotfuscator Pro includes a stack trace decoding tool.  If you get an obfuscated stack trace from a user in the field, you can paste it into the tool, point it to your map file, and press the decode button.  The tool reconstructs the original stack trace.

2) For interactive debugging, round trip the PDB files.

Dotfuscator Pro allows you to create a PDB file associated with the output assembly.  It will take source file, line number, and local variable information from the input assembly's PDB and include it in the output PDB.  You can use this to interactively debug Dotfuscated applications.  You can even step through the original source code.  The drawback is that the debugger will still show the obfuscated symbol names when you are trying to examine variables, etc.

Regards,
Bill Leach
PreEmptive Solutions, Inc.

This is an old topic, but I find usefull to report that there is a new standalone tool to decode dotfuscator symbols and stack traces, so we do not need to buy the expensive dotfuscator pro version to do this tasks   It is called dfstack