Decoding Stack Traces
One potential drawback of obfuscation is that troubleshooting obfuscated applications is difficult due to name-mangling. PreEmptive Protection - DashO addresses this issue by providing an integrated tool that allows you to use your output mapping files to recover the original symbols from obfuscated stack traces.
For example, if you have an obfuscated application that you have shipped and you receive a stack trace from one of your customers, that stack trace might look something like this:
Exception in thread "main" a: cannot calculate at c.a(Unknown Source) at b.a(Unknown Source) at d.a(Unknown Source) at com.preemptive.Example.main(Unknown Source)
Keep in mind it is possible to keep some Debug Information. Not removing line numbers allows you to see them in the stack traces. This tool and that option can greatly improve your ability to debug obfuscated programs.
You can use your mapping report file to manually recover the original names, but this is a tedious and time consuming process.
The stack trace translation tool automates this by letting you provide a map output file, paste the stack trace into a window, and press the Decode button. The decoded stack trace is shown on the Translation Report tab.
Some method names in the obfuscated stack trace might be ambiguous. When using Overload Induction there may be more than one method in the same class whose obfuscated name matches the method named in the stack trace. In these cases all possible matches are listed.
If you just want to look up a specific class or method by name, select the Decode Specific Element tab. You will see a screen that will allow you to type in the obfuscated names of the specific items you want to translate.
DashO also provides a stand-alone tool for decoding stack traces, named Lucidator. Lucidator provides the same GUI for decoding stack traces, but can also be run as a command-line utility for integrating the decoding process into existing support systems.
java -jar Lucidator.jar --help to learn how to use it.