A lot of code I encounter today has a considerable amount of code generated at runtime, making analysis extremely laborious and time consuming.

Is there any way I can create symbolic names for the various functions introduced by the JIT compiler that keep cropping up, or for the various artifacts (such as type information) introduced into the executable through the JIT compiler in GDB or WinDBG?

  • 2
    I think if you say what specific compiler/VM you're dealing with, it will be easier to answer.
    – Igor Skochinsky
    Commented Mar 23, 2013 at 20:29

2 Answers 2


For .net there's SOS.dll and WinDbg. You can find versions, for each version of installed .NET frameworks, in sub-folders in %SYSTEMROOT%\Microsoft.NET\Framework\. You can load it into WinDbg by typing .load and the full path to the SOS dll.

Use !name2ee to get the method table of class, !dumpmt to dump the method table, !dumpmd to dump the method descriptor for the method you want to look at, CodeAddr is the address of the JITed code, and finally !U to disassemble the code address.

Here's a link to a blog describing the process.

I'm actually not sure what you'd gain from attacking the JIT-compiled code though since it's almost always the case that the source VM is simpler and heavily type annotated. It's almost always easier to attack the intermediate language. The only reason I can think of is if you want to use the optimizations of the JIT to eliminate obfuscation. Even then it's probably easier to apply the optimization passes to the intermediate language. I suppose there's also the case when you want to massage the JIT code such that it can be reused in some sort of exploit.

Am I misunderstanding the question?


Yep, the answer depends on what exactly you are trying to achieve.

In terms of analyzing the .NET app itself, you can get a complete source code by using, e.g. DotPeek written by JetBrains. You can even export it into a fully-functional Visual Studio Project, build it and debug. However, some apps may be obfuscated.

Another scenario is when a .NET app is a part of another application written in another language (e.g. C++). In this case, most likely .NET code is compiled into DLL which is also can be disassembled using apps like DotPeek.

Probably, there are may exist much more complex scenarios like a custom JIT-compiler, embedded into a malware. In such cases, the most reasonable way may be to write a custom plugin (e.g. using IDAPython for IDA Pro). This plugin should be aware of data structures or behavior and can assist you in each step of a reverse engineering process. But writing a custom plugin may require a lot of knowledge of the underlying language and may be a challenge on its own.

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.