1

I'm gathering that it's nearly a waste of time to try to reverse .NET applications in a native debugger. But why? Of course the computer is executing machine code in the end, not CIL. So what clutters the x86-64 code so much when running a .NET application? Is the general rule to use native debuggers on native code and tools like ILSpy on .NET?

5
  • By this logic, it must be easy to debug Visual Basic code in a native debugger, because "the computer is executing machine code in the end" Jan 22, 2017 at 2:48
  • @VitalyOsipov I don't understand your comment. It seems to have no substance?
    – the_endian
    Jan 22, 2017 at 4:44
  • It's your question that has no substance, I was simply pointing out your faulty logic. Jan 28, 2017 at 6:18
  • @VitalyOsipov the definition of a question is to gather information in the form of an answer. The question "what is the relationship between .NET and x64 assembly?" Cannot be uninformed.
    – the_endian
    Jan 28, 2017 at 6:20
  • After all, I didn't post my reply as a full-blown answer. Jan 28, 2017 at 6:22

2 Answers 2

1

Microsoft .Net uses CIL (Common Intermediate Language). It is a - bytecode - assembly language for a virtual machine which is an abstract stack-based CPU - by abstract I mean not implemented in hardware.
Therefore, x86 gdb cannot make sense of the .Net bytecode given that all it knows is x86 assembly. But, in general you can easily reverse a bytecode into source code (because the VM states are more deterministic than those of a hardware CPU) or debug it using and .Net virtual machine with debug capabilities (i.e. ILSpy). If you want more info on debuggers/decompilers/... for .Net check out this link. Also, if you debug with gdb, you're most likely to be debugging the VM assembly code rather than the .Net bytecode of the application. In other words, what you are seeing is the VM running bytecode, not the bytecode running.

2
  • 1
    regarding "most likely VM code ": it is either VM or JITted (compiled with just-in-time-compilation)code.
    – w s
    Jan 19, 2017 at 14:43
  • Indeed, I avoided getting into such details. Good point, thanks.
    – yaspr
    Jan 19, 2017 at 15:46
2

I think it's more that you're debugging the code that launches the runtime assembly (and produces an error if it's not found) then after that is just pure MSIL which is effectively in another language (rather than machine code), which gets interpreted by the runtime (think of it like Java bytecode).. which will be meaningless without translating that to what the virtual machine would do... which a good .NET decompiler would actually convert to code for you anyway.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.