.NET offers through its
System.Reflection namespace the possibility to inspect an assembly. You can get all of the types defined inside, the fields, the properties and basically all you need. Still, something is missing: the body of a method. When doing a thorough inspection, you would expect to find the variables used, as well as the cycles and the decisions made inside a method body. Microsoft neglected this need, but still they provided us with something: the IL code. This is not enough, however, as it is actually an array of bytes with no meaning whatsoever to the untrained eyes of a normal programmer.
What is needed is a series of objects that represent the actual instructions from that IL code. That is what I want to provide.
Any programmer who has worked with reflection has heard of the awesome reflector written by Lutz Roeder. The reflector can decompile any .NET assembly and provide the user with the equivalent code for each programming element within the given assembly.
You observed that I said "equivalent." This is mainly because the reflection mechanism cannot provide you with the original code. The compilation process removes any comments and unused variables first. Only the valid and necessary code is added to the compiled code. Thus, we cannot obtain the exact code.
The reflector is a wonderful tool, but we might want to obtain similar results with our own code. How can we do that? Let us look first at the classic "hello world" example to see what we want to achieve and what is actually provided to us by the framework. This is the classic C# code:
public void SayHello()
When we get the body of the
SayHello method using reflection and ask for the IL code, we get an array of bytes such as:
Well, that's not very readable. What we know is that this is IL code and we want to transform it so that we can process it. The easiest way is to transform it to MSIL (Microsoft Intermediate Language). This is what the MSIL code of the
SayHello method looks like and what my library is supposed to return:
0000 : nop
0001 : call System.IO.TextWriter System.Console::get_Out()
0006 : ldstr "Hello world"
0011 : callvirt instance System.Void System.IO.TextWriter::WriteLine()
0016 : nop
0017 : ret
Using the Code
SDILReader is a library containing only three classes. In order to obtain the MSIL of the body of a method, one must simply create a
MethodBodyReader object and pass to its constructor a
MethodInfo object of the object you want to decompose.
MethodInfo mi = null;
SDILReader.MethodBodyReader mr = new MethodBodyReader(mi);
string msil = mr.GetBodyCode();
for (int i=0; i<mr.instructions.Count;i++)
How's It Working
Well, this is the right question. In order to get started, we first need to know the structure of the IL array that is given by the .NET reflection mechanism.
IL Code Structure
The IL is in fact an enumeration of operations that must be executed. An operation is a pair: <operation code, operand>. The operation code is the byte value of
System.Reflection.Emit.OpCode, while the operand is the address of the metadata information for the entity the operator is working with, i.e., a method, type, value. This address is referred to as the metadata token by the .NET framework. So, in order to interpret the array, we must do something like this:
- Get the next byte and see what operator we are dealing with.
- Depending on the operator, the metadata token is defined in the next 1, 2, 3 or 4 bytes. Get the metadata token of the operand.
- Use the
MethodInfo.Module object to retrieve the object whom the metadata token is addressing.
- Store the pair <operator, operand>.
- Repeat if we are not at the end of the IL array.
ILInstruction class is used for storing the <operator, operand> pair. Also, we have there a simple method that transforms the inner information into a readable
MethodBodyReader class is doing all the hard work. Inside the constructor a
ConstructInstructions, is called that parses the IL array:
int position = 0;
instructions = new List<ILInstruction>();
while (position < il.Length)
ILInstruction instruction = new ILInstruction();
OpCode code = OpCodes.Nop;
ushort value = il[position++];
if (value != 0xfe)
code = Globals.singleByteOpCodes[(int)value];
value = il[position++];
code = Globals.multiByteOpCodes[(int)value];
value = (ushort)(value | 0xfe00);
instruction.Code = code;
instruction.Offset = position - 1;
int metadataToken = 0;
metadataToken = ReadInt32(il, ref position);
metadataToken += position;
instruction.Operand = metadataToken;
metadataToken = ReadInt32(il, ref position);
instruction.Operand = module.ResolveField(metadataToken);
We see here the simple loop for parsing the IL. Well, it's not quite simple. It actually has 18 cases and I did not take into account all of the operators, only the most common ones. There are 240+ operators. The operators are loaded into two
static lists at the start of the application:
public static OpCode multiByteOpCodes;
public static OpCode singleByteOpCodes;
public static void LoadOpCodes()
singleByteOpCodes = new OpCode[0x100];
multiByteOpCodes = new OpCode[0x100];
FieldInfo infoArray1 = typeof(OpCodes).GetFields();
for (int num1 = 0; num1 < infoArray1.Length; num1++)
FieldInfo info1 = infoArray1[num1];
if (info1.FieldType == typeof(OpCode))
OpCode code1 = (OpCode)info1.GetValue(null);
ushort num2 = (ushort)code1.Value;
if (num2 < 0x100)
singleByteOpCodes[(int)num2] = code1;
if ((num2 & 0xff00) != 0xfe00)
throw new Exception("Invalid OpCode.");
multiByteOpCodes[num2 & 0xff] = code1;
Upon constructing the object, we can use the object to either parse the list of instructions or get the
string representation of them. That's it; have fun decompiling.
Well, what's left is to transform the MSIL into C# code.
9 May, 2006
28 June, 2007
After a very long time, I managed to have a look at the issues signaled by the readers of my article. Here are the results:
- I added support for generics.
OperandType.InlineTok is also correctly processed.
- Various other small issues have been fixed.
Be sure to download the sources again from the links at the start of the project.