views:

108

answers:

4

We are thinking about obfuscating some code before releasing it to customers. We are wondering about the impact it will that have on tech support. Can customers provide us with meaningful stack traces or will they be obfuscated too?

I look forward to hearing about your experience. Thanks in advance.

A: 

If the methods on the stack are obfuscated in your release, you will get the obfuscated method names in any stack trace.

If you put anything into your code to help you figure out what methods were involved, potential hackers can use that information to gain a better understanding of your code.

One common strategy is to obfuscate only some of the code, including (but not limited to) the parts that do license checking. If you obfuscate JUST the license checks, it's pretty easy to zero in on the part that needs a hacker's attention.

Eric J.
I'm wondering if the company can withhold an obfuscating log for the obfuscation on the source code which they can use internally to get at the real place the error occurred.
Chris Dennett
See Nissan Fan's comment. Your tool should be able to deobfuscate the stack trace... IF you get it as a properly encoded file. Many obfuscators use Unicode characters for class and method names to make it particularly hard to read on screen. Given only a screenshot, or a non-unicode text file, it will be hard to go back. I sometimes create a web service for logging errors to make sure the program submits everything I need to diagnose an error. That would be a safe method to get the properly (unicode) encoded stack trace.
Eric J.
+7  A: 

you will get obfuscated stack traces. but obfuscators can generate mapping files that map obfuscated names to real names.. you have to keep these mapping files in a safe place and you can use them to "deobfuscate" the stack traces again when required.

in the case of tech support - you could create a simple web interface where tech support people can paste stack traces. that way only the web server needs access to the mapping files so it can restore the original stack traces.

here are two links explaining the process with the dotfuscator obfuscator:

http://www.preemptive.com/images/stories/dotfuscator_documentation/Dotfuscator/The_Map_File.html

http://www.preemptive.com/images/stories/dotfuscator_documentation/Dotfuscator/Decoding_Obfuscated_Stack_Traces.html

stmax
As noted, de-obsfucate stack traces is available in most tools (e.g. http://www.ssware.com/cryptoobfuscator/obfuscator-net.htm)
Nissan Fan
I sometimes create a web service to receive crash reports. The user can submit a "submit error report" button and the stack trace and other useful information about program state can be transmitted with no risk of the stack trace being encoded in the wrong text format (since many obfuscators use Unicode characters for class/method names).
Eric J.
A: 

This is not usually an issue since most obfuscators provide ability to de-obfuscate stack traces back to their original trace.

logicnp
A: 

We use BitHelmet. Problem is, when using strongest obfuscation technique, stack trace can not be deobfuscated. BitHelmet uses Full Signature renaming (some kind of overload induction, only better). What happens is, lots of methods end up with the same name but with different return type (this cannot be done in C#, but it is ok for the CLR). Return types are not shown in stack traces! so it is actually not possible to deobfuscate stack trace using strongest obfuscation.

We asked the same question than you did, we discussed it and we reached to the conclusion that actually we prefer the better obfuscation. Stack traces are actually not so useful when providing tech support as some other data that only the final user can provide. "please tell me exactly what you were you doing???" :)

Daniel Dolz