Reverse Engineering

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 

RTN-Team forum

If you’re interested in the work I do on this blog, and have a general interest in programming and/or reverse engineering you should check out a forum I’m a part of over at RTN-Team forum. It focuses on questions/help/releases related to reverse engineering but there a lot of experienced coders available to help out too.

It’s a small community right now and we want to keep it rather small, but with high quality content and members. Quality over quantity, you know. So please consider going over there and signup and hopefully join the community.

Once again the link is:

There is some more content coming to the blog as well soon, so stay tuned for that. 🙂

Dissecting ConfuserEx – Constants protection

It’s been a while since my last Dissecting ConfuserEx paper and I’m sorry for that! I’ll try to keep up better. Anyway this is the latest one in the series and it covers the constants protection in ConfuserEx, talks about 2 ways of deobfuscating it and also how to dump the decrypted strings with WinDbg. I feel as if this wasn’t the best tutorial really, but if someone has tips or feedback let me know and I’ll update it.


This protection works by taking every string and constant in the assembly, encrypt and compress them and put them into a resource. Generally in obfuscators the enrypted data is stored in an embedded resource. This was the case in Confuser 1.9, but in ConfuserEx it’s done a bit differently with a more creative way.

Read it here: Dissecting ConfuserEx – Constants Protection

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

DnSpy – More powerful .NET decompiler

I’m sure you all know of the standard decompilers such as ILSpy or Reflector. They both rely on Mono.Cecil to read assemblies, which is quite a fragile library when it comes to loading obfuscated files. Because of this you should use DnSpy, a ILSpy mod by 0xd4d which uses dnlib to read files instead of Cecil. It’ll load obfuscated files and allow you to browse them (IL->C#/VB conversion still might crash).

Check the source out: DnSpy 

or download compiled binaries:

Dissecting ConfuserEx – Invalid metadata

The latest paper in my series. It just explains a bit what the Invalid metadata protection does, and how it affects decompilers etc. I don’t go over how to fix everything manually since it’s not only self-explanatory but de4dot is able to do it automatically, so I don’t see the point.


This protection works by injecting “dummy” metadata into the assembly which the decompilers then try to parse and read. They crash since the metadata is not actually pointing to anything real.

Read it here: Dissecting ConfuserEx – Invalid metadata

Also added to the Dissecting ConfuserEx paper series blog entry.

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

Closer look at the native constant mutation in ConfuserEx

In my Dissecting ConfuserEx – x86 switch predicates paper I quickly went over the actual code used in order to understand the Switch jump flow. But I simply debugged it to see the return value, and didn’t go into detail about what the code does. I just thought it wouldn’t be that interesting or revelant to the paper. That’s why I decided to create this blog entry in order to properly explain it. You will need to read the paper in order to understand what I’m talking about here.

Let’s start by looking at an obfuscated piece of C# code;


and the IL equivalent:


Let’s follow the native method with RVA 20F0 call at:

IL_0011: call int32 <Module>::(int32)

in OllyDbg. We’ll find:

003420F0 /. 89E0 MOV EAX,ESP
003420F2 |. 53 PUSH EBX
003420F3 |. 57 PUSH EDI
003420F4 |. 56 PUSH ESI
003420F5 |. 29E0 SUB EAX,ESP
003420F7 |. 83F8 18 CMP EAX,18
003420FA |.- 74 07 JE SHORT 00342103 <-- THIS JUMP SHOULD NOT BE TAKEN
003420FC |. 8B4424 10 MOV EAX,DWORD PTR SS:[ESP+10]
00342100 |. 50 PUSH EAX
00342101 |.- EB 01 JMP SHORT 00342104
00342103 |> 51 PUSH ECX
00342104 |> B8 6D739303 MOV EAX,393736D
00342109 |. 81C0 BEBDB45E ADD EAX,5EB4BDBE
0034210F |. 59 POP ECX
00342110 |. 69C9 2538C0C9 IMUL ECX,ECX,-363FC7DB
00342116 |. 69C9 E5FC94FD IMUL ECX,ECX,-26B031B
0034211C |. 29C8 SUB EAX,ECX
0034211E |. 81C0 B2C98459 ADD EAX,5984C9B2
00342124 |. 5E POP ESI
00342125 |. 5F POP EDI
00342126 |. 5B POP EBX
00342127 \. C3 RETN

This is the code that returns the value deciding where the switch should jump next. We can skip instructions up until:

003420FC |. 8B4424 10 MOV EAX,DWORD PTR SS:[ESP+10]
00342100 |. 50 PUSH EAX

This is where it moves the data of the passed method parameter into the EAX register, in our case: 0x2515CA13. Right after it pushes the value onto stack. It then does an unconditional jump to:

00342104 |> B8 6D739303 MOV EAX,393736D
00342109 |. 81C0 BEBDB45E ADD EAX,5EB4BDBE

This should be quite self-explanatory. It moves an immediate value of 0x393736D into EAX, then adds 0x5EB4BDBE to it. EAX now contains: (0x393736D + 0x5EB4BDBE) == 0x6248312B

0034210F |. 59 POP ECX

Put whatever value is on top of stack into ECX, in our case it will load 0x2515CA13, pushed from: 00342100 PUSH EAX.

00342110 |. 69C9 2538C0C9 IMUL ECX,ECX,-363FC7DB
00342116 |. 69C9 E5FC94FD IMUL ECX,ECX,-26B031B

Here it does some more arithmetic. It first multiplies whatever is in ECX with -0x363FC7DB and stores it in ECX. It then multiplies whatever is in ECX with -0x26B031B and stores it in ECX once again. ECX now contains: (0x2515CA13 * -0x363FC7DB * -0x26B031B).

0034211C |. 29C8 SUB EAX,ECX

Subtract whatever is in EAX with ECX. EAX now contains: 0x6248312B – (0x2515CA13 * -0x363FC7DB * -0x26B031B).

0034211E |. 81C0 B2C98459 ADD EAX,5984C9B2

Add 0x5984C9B2 to EAX. EAX now contains: (0x6248312B – (0x2515CA13 * -0x363FC7DB * -0x26B031B)) + 0x5984C9B2. And now to the beautiful part. All this complicated looking math is actually equal to 2. Knowing this we can follow the jump flow of the switch as shown in the image below:


This might all seem a bit over complicated for such a simple task of hiding a constant value. But it really isn’t. Splitting a constant up into parts and reassembling it at runtime causes an array of different problems for automatic deobfuscation tools. In my project ConfuserDeobfuscator I created a simple IL emulator in order to fold these “mutated” constants into one value. But doing this in x86 assembly makes it more difficult to emulate. Additionally, these methods are “randomly” generated from a small set of opcodes. The ones showed in this example (IMUL, ADD, SUB) aren’t all. Here’s a list of the possible opcodes:

public enum x86OpCode

But all that aside, here’s what the x86 assembly code above could look like if it was implemented in C#:



I hope this gave you some more insight on what the native code actually does. Is there something incorrect in the text? Do you have any questions or feedback? Post it in the comments below. 🙂