Parsing the IL of a Method Body

• Download demo project - 9 KB
• Download source - 22.9 KB

Introduction

.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.

Background

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()
{
    Console.Out.WriteLine("Hello world");
}

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:

0,40,52,0,0,10,114,85,1,0,112,111,53,0,0,10,0,42

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;
// obtain somehow the method info of the method we want to dissasemble
// ussually you open the assembly, get the module, get the type and then the 
// method from that type 
// 
...
// instantiate a method body reader
SDILReader.MethodBodyReader mr = new MethodBodyReader(mi);
// get the text representation of the msil
string msil = mr.GetBodyCode();  
// or parse the list of instructions of the MSIL
for (int i=0; i<mr.instructions.Count;i++)
{
    // do something with mr.instructions[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

The 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 string.

MethodBodyReader

The MethodBodyReader class is doing all the hard work. Inside the constructor a private method, ConstructInstructions, is called that parses the IL array:

int position = 0;
instructions = new List<ILInstruction>();
while (position < il.Length)
{
    ILInstruction instruction = new ILInstruction();

    // get the operation code of the current instruction
    OpCode code = OpCodes.Nop;
    ushort value = il[position++];
    if (value != 0xfe)
    {
        code = Globals.singleByteOpCodes[(int)value];
    }
    else
    {
        value = il[position++];
        code = Globals.multiByteOpCodes[(int)value];
        value = (ushort)(value | 0xfe00);
    }
    instruction.Code = code;
    instruction.Offset = position - 1;
    int metadataToken = 0;
    // get the operand of the current operation
    switch (code.OperandType)
    {
        case OperandType.InlineBrTarget:
            metadataToken = ReadInt32(il, ref position);
            metadataToken += position;
            instruction.Operand = metadataToken;
            break;
        case OperandType.InlineField:
            metadataToken = ReadInt32(il, ref position);
            instruction.Operand = module.ResolveField(metadataToken);
            break;
        ....
    }
    instructions.Add(instruction);
}

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;
            }
            else
            {
                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.

Future Work

Well, what's left is to transform the MSIL into C# code.

History

9 May, 2006

• Original version posted

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.
• Now 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.

References

• MSDN