Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.
Sign up to join this community
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?
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.
