Reputation: 14777
I'm trying to obfuscate a library with ConfuserEx, but afterwards my app crashes with MissingMethodException
with stack trace pointing to first usage of obfuscated class and method in question is the one that was renamed. I have no idea where its call or other usage was found, so it is not clear what should I check. My guess is that exception is happening during JIT process.
Only rename obfuscation was applied and I have map to reverse it.
I looked at obfuscated module and renamed version of the method definitely exists.
Also running PEVerify.exe on obfuscated module gives some errors (only small excerpt is provided below):
[IL]: Error: [d:\1\Confused\my.dll : _YGbNngBKpRxvvy7NkSKSrcvDmJG_::_17w1GiROq6y1aWRw9wWSUGOde1C_][mdToken=0x60003cd] Method does not exist.
Method does not exist.
Method does not exist.
[IL]: Error: [d:\1\Confused\my.dll : _cdMM5QrQwL2ksRGa1UJRmJUkVTd_::.ctor][mdToken=0x60006c8][offset 0x00000002] Unable to resolve token.
[IL]: Error: [d:\1\Confused\my.dll : ClassXyz::_tGtv2dtaIMIA6LoHXu7DwMxfvlS_][mdToken=0x6000732] Method does not exist.
[IL]: Error: [d:\1\Confused\my.dll : ClassXyz::_tk0zK3VXciZeRsH2nVWBZ6jNVdE_][mdToken=0x6000733] Method does not exist.
[IL]: Error: [d:\1\Confused\my.dll : ClassXyz::_tGtv2dtaIMIA6LoHXu7DwMxfvlS_][mdToken=0x6000732] Method does not exist.
[IL]: Error: [d:\1\Confused\my.dll : ClassXyz::_tk0zK3VXciZeRsH2nVWBZ6jNVdE_][mdToken=0x6000733] Method does not exist.
[IL]: Error: [d:\1\Confused\my.dll : ClassXyz::_PkJlSB6sykBdsQ8OXX3CBVEXudk_][mdToken=0x6000735] Method does not exist.
[IL]: Error: [d:\1\Confused\my.dll : ClassXyz::_AYy29oWv1vnvKJP5Q1lcxUcQZRd_][mdToken=0x6000757] Method does not exist.
I'm ready to debug obfuscation process to search what went wrong... but I have no idea what to look for. How can I find out, what part of code is trying to use old method name? How to work with PEVerify's output, e.g. how mdTokens are going to help me?
Upvotes: 3
Views: 3003
Reputation: 14777
These tokens can be seen in ildasm results if run with /tokens
switch. Like ildasm.exe asm.dll /out=asm.il /tokens
. In this case ildasm produces MD token near each definition and reference. Thus it is possible to do simple text search of the token reported by PEVerify.
Here is the example of ildasm-produced IL when ran with /tokens
:
.method /*060035D5*/ private hidebysig newslot virtual final
instance void b() cil managed
{
.override [mscorlib/*23000001*/]System.IDisposable/*01000051*/::Dispose /*01000051::0A000069*/
Note that ildasm does not prepend tokens with 0x
(for brevity perhaps), so you should do case-insensitive search for 060006c8
instead of 0x060006c8
.
Upvotes: 1
Reputation: 20384
From my experience in the development of SeeUnsharp .NET Obfuscator, a MissingMethodException
during runtime indicates that you want to execute an assembly that has invalid or missing references to members in the IL code. IL code, which is what the .NET CLI compiler generates, may contain references to methods that don't need to exist. If you do this in C#, the C# compiler will tell you.
PEVerify catches this error when the compiler (in this case the obfuscator) didn't and tells you which method is missing, or at least at which IL offset in which method the defective method call is located. You can use ILSpy, enable metadata token display and switch to IL mode, to find the relevant instruction. Remaining errors from PEVerify will probably cause trouble during runtime, which is why SeeUnsharp always runs the obfuscated assembly through PEVerify to be sure the output is valid.
I'd say it's a problem from ConfuserEx. I had these exceptions as well when I had wired things in the wrong way during IL processing. When you have located the original of the missing method, you could check whether it is special in some way. Is it virtual? Is it an interface method? Are there dynamic types involved? Eventually, excluding that method from renaming might be a solution.
There's also a bit more information about this error in MSDN blogs.
Upvotes: 0
Reputation: 63183
It just needs patience. First, use WinDbg to launch that application and let the application crash. Then you can see the detailed exception info such as call stack and registers. With some help from tools such as ILSpy you can see exactly which method is missing. Finally analyze the obfuscation log file to find the original method.
Typical workaround is to try to exclude that method from obfuscation to see if the issue is solved. But there might be other workarounds or simply no solution but to fix the obfuscator.
I am the current maintainer of Obfuscar, so above is my personal experience when debugging issues with Obfuscar. Hope it helps you out.
Upvotes: 1