3

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?

Ivan Danilov
  • 14,287
  • 6
  • 48
  • 66
  • Just as an observation or another thing to consider, you may be using reflection (via a string literal) to access the type or the member and thus the code may not 'know' of the renaming. – MaLio Jan 11 '16 at 11:01
  • Reflection of non-existent members usually returns null or throws other exception types at least. This particular exception comes from an invalid assembly. Something went wrong during obfuscation, some link within the assembly is broken. – ygoe Feb 02 '16 at 19:51

3 Answers3

1

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.

Lex Li
  • 60,503
  • 9
  • 116
  • 147
  • I guess I have to learn WinDbg a bit then... for now I have huge stack trace from the thread in question ending deeeep in the clr.dll (output of `!EEStack`, because `!CLRStack` shows nothing new comparatively to VS debugger) and I have no idea what to do with it next... – Ivan Danilov Dec 29 '15 at 16:36
  • @IvanDanilov `!pe -nested`? – Lex Li Dec 30 '15 at 01:02
  • https://www.dropbox.com/s/dq4bqh3z8gl0vv7/windbg.log?dl=0 (I've renamed some typenames, otherwise it is untouched) – Ivan Danilov Dec 30 '15 at 04:23
1

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.

Ivan Danilov
  • 14,287
  • 6
  • 48
  • 66
0

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.

ygoe
  • 18,655
  • 23
  • 113
  • 210
  • Yeah, that's definitely a problem with ConfuserEx. I was trying to find and fix the problem there. But message from PEVerify does not state where it has found reference to the method - just what method wasn't found. It could be that reference is wrong (not renamed correctly), not that method itself is missing. And the question was how to find out missing details. That PEVerify reports inconsistencies in target assembly and there's something wrong with it... is kind of obvious. – Ivan Danilov Feb 03 '16 at 12:08