Roundtripping refers to disassembling an application, modifying the resulting code, and then reassembling the application. This provides a mechanism for maintaining or otherwise updating an application without the original source code.

The following C# application simply totals two numbers. The program is called "Add," and the results are displayed in the console window:

using System;

namespace Donis.CSharpBook {
    public class Starter {
        public static void Main(string[] args) {
            if (args.Length < 2) {
                Console.WriteLine("Not enough parameters.");
                Console.WriteLine("Program exiting...");
                return;
            }
            try {
                byte value1 = byte.Parse(args[0]);
                byte value2 = byte.Parse(args[1]);
                byte total = (byte) (value1 + value2);
                Console.WriteLine("{0} + {1} = {2}",
                    value1, value2, total);
            }
            catch(Exception e) {
                Console.WriteLine(e.Message);
            }
        }
    }
}

Let’s assume that the above program was purchased from a third-party vendor for a quintillion dollars. Of course, the source code was not included with the application—even for a quintillion dollars. Almost immediately, the purchaser discovers a bug in the application, such that when the program is executed, the total is sometimes incorrect. Look at the following example:

C: >add 200 150

200 + 150 = 94

The result of this equation should equal 350, not 94. How can the purchaser fix this problem without the source code? Roundtripping is the answer. This begins by disassembling the application. For convenience, the ILDASM disassembler is used:

ildasm /out=newadd.il add.exe

Open newadd.il in a text editor. In examining the MSIL code, we can find the culprit easily. The add instruction adds two byte variables. The result is cached in another byte variable. This is an unsafe action that occasionally causes an overflow in the total. Instead of notifying the application of the overflow event, an incorrect value is stored. This is the reason for the errant results. Add the ovf suffix to the conv instruction to correct the problem. An exception is now raised when the overflow occurs.

You can use roundtripping to add features that are not otherwise available in C#. For example, C# supports general exception handling but doesn’t support exception filters directly. You can implement an exception filter directly in MSIL. In MSIL, when an exception is raised, the exception filter determines whether the exception handler executes. If the exception filter evaluates to one, the handler runs. If the result is zero, the handler is skipped.

Here is a partial listing of the disassembled program. It is modified to throw an exception when the addition overflows the total. An exception filter also has been added to the exception handling. Changes in the code are highlighted:

.try

{

    IL_0029:  nop

    IL_002a:  ldarg.0

    IL_002b:  ldc.i4.0

    IL_0035: ldelem.ref
    IL_0036: call uint8 [mscorlib]System.Byte::Parse(string)
    IL_003b: stloc.1
    IL_003c: ldloc.0
    IL_003d: ldloc.1
    IL_003e: add
    IL_003f: conv.ovf.u1
    IL_0040: stloc.2
    IL_0041: ldstr "{0} + {1} = {2}"
    IL_0046: ldloc.0
    IL_0047: box [mscorlib]System.Byte
    IL_004c: ldloc.1
    IL_004d: box [mscorlib]System.Byte
    IL_0052: ldloc.2
    IL_0053: box [mscorlib]System.Byte
    IL_0058: call void [mscorlib]System.Console::WriteLine(string,
        object,
        object,
        object)
    IL_005d: nop
    IL_005e: nop
    IL_005f: leave.s IL_0072
} // end .try
filter
{
pop
ldc.i4.1
endfilter
}
// catch [mscorlib]System.Exception
{
IL_0061: stloc.3
IL_0062: nop
IL_0063: ldloc.3

Because the filter returns one, the exception is always handled. Use the ILASM compiler to reassemble the application, which completes the round trip. Here is the command:

ilasm newadd.il

Run and test the newadd application. The changed program is more robust. Roundtripping has succeeded!