.netclrjitryujit

Where in the Virtual Memory can I find x86 code compiled by .Net JIT


I understand that when a function is called for the first time, the JIT is invoked and it compiles the .Net IL code into x86 instruction and keeps it in the memory somewhere. I need to know the location where this x86 code is kept so that I can analyse the x86 assembly instructions(the purpose is not really important in the context of this question.) Can anyone tell me how one would determine the memory location at which the translated code is stored, or probably which function in JIT code does that. I have the JIT code with me(as .net source code is published in GitHub but I am overwhelmed by the size of the code so far). I would appreciate any sort of help. Thanks in advance...

It would help if someone could suggest a dissassembler which could give x86 assembly instruction dump of a running .net exe, much like visual studio dissassembler does but I need to run it automatically. I know that this can be done statically by ngen. ngen could convert to x86 instructions and then any dissassembler can get the dump, but its important for me that this has to be done after the exe is run.

This is because the reason why I need the x86 instruction dump is to find similarity between multiple .net exes. The challenge with directly looking at statically dissassembled assembly is that it could be packed or obfuscated in which case they might look dissimilar even though they are internally similar. But at runtime they will be unpacked/deobfuscated by the packer program and the JIT compiled x86 instructions would look similar.


Solution

  • You could use the debugger api to read the jitted instructions from the process. (Specifically, a combination of ICorDebugFunction::GetNativeCode, ICorDebugCode2::GetCodeChunks and ICorDebugProcess::ReadMemory).

    Doing things this way would probably require that the method has already been jitted ... but you could probably arrange for that using ICorDebugEval (perhaps with a breakpoint at the start of the method and then aborting the eval when it's hit).