dnEditor – Opensource .NET decompiler using dnlib

Thought I’d share another neat project with you today created by ViRb3 which you can find at: dnEditor on GitHub.

It’s a .NET decompiler in it’s early stages of development which uses dnlib by 0xd4d as the engine to load assemblies. This means it’ll load pretty much every .NET assembly, obfuscated or not, without any issues. It has support for IL->C# decompilation using ILSpy as a base. It has a simple but user-friendly interface similar to ILSpy and Reflector:

dnEditor user interface

If you have used Reflexil before you’ll find a familiar interface in the instruction editor in dnEditor:

Instruction editor in dnEditor

Another cool feature is the color-coded IL blocks and instructions similar to SimpleAssemblyExplorer:

IL blocks

You should keep your eyes on this project as it’s being actively developed and I might even take a shot at contributing some to it myself in the future.

Make sure you check out ViRb3’s profile on GitHub: ViRb3 GitHub profile 


Updating method at runtime (native)

I thought I’d show you something fun to do in C#; changing method bodies at runtime, AFTER they’ve been JIT’d. This is a fairly simple process actually. The first thing we have to do is load our assembly using reflection:

 Assembly asm = Assembly.LoadFile(Path.GetFullPath("test.exe"));
 Type mainType = asm.EntryPoint.DeclaringType;
 MethodInfo method = mainType.GetMethod("Foo",
 BindingFlags.InvokeMethod | BindingFlags.NonPublic | BindingFlags.Static);

The method we’re gonna use looks like this:

Let’s invoke it with 1000 as parameter. Expected output would be 1000*1000:

Console.WriteLine("Original value: " + method.Invoke(null, new object[] { 1000 }));

And indeed it shows 1000*1000:

Now let’s change this method to show something else! First of all we would need to force the method to be JIT’d in order for the assembly code to even be present in memory. But since we already invoked the method, it has already been JIT’d, but if we didn’t we could use:


Okay now to the interesting part. Before I start with this you should read .NET Framework Internals: MethodDesc to understand why this works. First thing we need to do is retrieve a pointer to the native method:

IntPtr pBody = method.MethodHandle.GetFunctionPointer();

Since we know our target int is 0x3e8 (1000), we iterate the body until we find it, we then write our new 0x539 (1337) in place of it:

   var ptr = (byte*) pBody.ToPointer();
   for (var i = 0; i < 100; i++)
      // Assuming our 0xE8 byte is the first one
      if ((*(ptr+i)) == 0xe8)
           (*(int*)(ptr+i)) = 0x539;

That’s it! Let’s call the method the same way we did in the beginning:

Console.WriteLine("New value: " + method.Invoke(null, new object[] { 1000 }));

It should just return 1000*1000 as before, right? Of course not, silly. We replaced the 1000 with 1337:

I’m not sure what this could be used for in practice. Perhaps some sort of obfuscation? But then you’d probably be better off using MethodRental.SwapMethodBody to work with the IL code rather than assembly. Hope you found this little example interesting. 🙂

Download files used:

Manually deobfuscating DotNetPatcher 3.1


I’ve seen a lot of people lately having issues deobfuscating this protection, mostly because it can’t be done automatically be drag&dropping the file onto de4dot. So I’m gonna show you how to do it manually with WinDbg and De4dot in this paper.

Read it here: Manually deobfuscating DotNetPatcher 3.1

Manual global decryption of MSIL methods

Something I’ve wanted to write about for a while, and just recently got around to. This paper shows you how you can globally decrypt MSIL methods by dumping them from JIT.


If you’re not familiar with how the JIT compiler in the CLR runtime works, you should probably read or any other article covering it to understand the basics. The reason this is global is because every .NET assembly that is compiled to IL code needs to be compiled into machine code (assembly) at runtime. This is done by either mscorjit.dll (.NET 3.5 and lower) or clrjit.dll (.NET 4 or higher). Both of these have a function called “compileMethod” that does the actual compiling. Basically the raw IL code is passed to compileMethod and from there a native method is created. This means that even if an obfuscator or protector completely encrypts the body of a method, it HAS to be passed to compileMethod as a clean (obfuscation may still be present), buffer of IL code. This is why we’re gonna take advantage of compileMethod in order to dump the clean bodies.

The reason I say this is an almost global decryption method is because some protections use code virtualization, such as Agile.NET. This means the IL is converted to their own custom bytecode and never runs through the JIT compiler. So the method of decryption I’m about to show is useless against this sort of protection. However, if you’re interested in decrypting a custom bytecode such as Agile.NET’s you should take a look at de4dot.

In this demonstration I will be using the most common ‘template’ for JIT hooking, created by Daniel Pistelli. You can find it here:

Read it here: Manual global decryption of MSIL methods

Dissecting ConfuserEx paper series

As you might know I’ve written several papers covering the different protections of Confuser 1.9. Now that Yck1509 (author of Confuser) started working on a successor project I’m really excited to keep up the papers for the new ConfuserEx! It has far more complex obfuscation routines, and also introduces the use of native methods inside the .NET assembly, so hopefully I’ll learn some more x86 writing these. 🙂 So far I’ve covered 2 protections. I’ll try to continue whenever new features are added to the project. I’ll keep updating this blog entry whenever I release new papers. In the meantime, feel free to read through the list of finished ones:

Enjoy reading them. Feel free to give me feedback or questions in the comments.