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?
Asked
Active
Viewed 123 times
1
-
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" – Vitaly Osipov Jan 22 '17 at 02:48
-
@VitalyOsipov I don't understand your comment. It seems to have no substance? – the_endian Jan 22 '17 at 04:44
-
It's your question that has no substance, I was simply pointing out your faulty logic. – Vitaly Osipov Jan 28 '17 at 06: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 '17 at 06:20
-
After all, I didn't post my reply as a full-blown answer. – Vitaly Osipov Jan 28 '17 at 06:22
2 Answers
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.
Matthew1471
- 121
- 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.
yaspr
- 2,663
- 14
- 20
-
1regarding "most likely VM code ": it is either VM or JITted (compiled with just-in-time-compilation)code. – w s Jan 19 '17 at 14:43
-