GoogleCodeExporter
commented
8 years ago What sort of xml would be useful? Currently, the mapping looks like this:
BasicExampleExe, BasicExampleExe.ExampleUI -> BasicExampleExe, A.A
{
BasicExampleExe, BasicExampleExe.ExampleUI::Dispose[1]( System.Boolean ) -> Dispose
BasicExampleExe, BasicExampleExe.ExampleUI::InitializeComponent[0]( ) -> A
System.ComponentModel.IContainer BasicExampleExe, System.ComponentModel.IContainer
BasicExampleExe.ExampleUI::components -> A
System.Windows.Forms.Label BasicExampleExe, System.Windows.Forms.Label
BasicExampleExe.ExampleUI::label1 -> A
System.Windows.Forms.Label BasicExampleExe, System.Windows.Forms.Label
BasicExampleExe.ExampleUI::displayText -> a
}
It wouldn't be difficult to generate an xml document like the following:
<Type assembly="BasicExampleExe" oldName="BasicExampleExe.ExampleUI"
newName="A.A">
<Method oldName="Dispose( System.Boolean )" newName="Dispose( System.Boolean )" />
<Method oldName="InitializeComponent( )" newName="A( )" />
<Field oldType="System.ComponentModel.IContainer" oldName="components"
newType="System.ComponentModel.IContainer" newName="A" />
<Field oldType="System.Windows.Forms.Label" oldName="label1"
newType="System.Windows.Forms.Label" newName="A" />
<Field oldType="System.Windows.Forms.Label" oldName="displayText"
newType="System.Windows.Forms.Label" newName="a" />
</Type>
As for de-obfuscating a stack trace, it's not so simple...trouble is, the
regular
stack trace doesn't contain enough information to disambiguate the obfuscated
methods; you'll have to walk it and format it in a custom manner.
To demonstrate: Add code to throw an exception into BasicExample, in the
BasicExampleLibrary.ClassX.DisplayText property getter. Build it and
obfuscate.
When BasicExampleExe is executed, the thrown Exception's StackTrace property
looks
like the following:
at A.A.A()
at A.A..ctor()
at A.a.A()
It's easy to determine which method threw the exception...if one examines the
Exception's Source or TargetSite properties, it clearly shows that the
exception was
thrown from BasicExampleLibrary, and a quick glance at the map file shows A()
in A.A
of BasicExampleLibrary to be ClassX.get_DisplayText.
The second frame is where it gets more interesting, since the regular stack
trace
formatting doesn't include the assembly where the method lives. In this case,
it
shows that the call was made from the constructor for A.A, but there is a class
A.A
in each assembly, and it does not show _which_ A.A made the call. We can infer
that
the call came from BasicExampleExe, since the constructor for class A.A in
BasicExampleExe accepts no parameters (unlike the A.A in BasicExampleLibrary).
In
this case, we can also infer which assembly is involved with the third frame,
as the
only method A.a.A that accepts no parameters is in BasicExampleExe.
For a larger project, with more assemblies, it's not that simple. Given only a
stack
trace and information about the topmost assembly, it can be very difficult to
determine which other assemblies were involved. One quickly runs into
ambiguous calls.
Of course, if you write something to walk the stack, and dump each frame with a
bit
more information, it becomes a lot easier:
at BasicExampleLibrary, A.A.A()
at BasicExampleExe, A.A..ctor()
at BasicExampleExe, A.a.A()
This provides enough information to de-obfuscate, but getting it dumped is more
of an
issue.Original comment by drcfor...@gmail.com on 8 May 2007 at 8:29
Original issue reported on code.google.com by
obiwanja...@hotmail.comon 8 May 2007 at 6:20