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: https://www.rtn-team.cc/board/

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

Memory efficient strings in .NET

I’m sure all of you know the basic fundamentals about strings in .NET: They’re immutable, the equality operator compares value instead of reference, etc. But did you know each character in a string takes up 2 bytes of memory? That’s right. Every standard string in .NET is a unicode string in memory, meaning the string “abc” would look like: 61 00 62 00 63 00 in memory. This might not sound like a big deal, but think about a string that is, say, 32768 characters long would take up 65536 bytes in memory (if we exclude metadata stuff). So why is implemented like this? Most likely because of compatibility and uniform of code. For example, a lot of WinAPIs have ugly suffixes on their names such as “MessageBoxW/MessageBoxA” or “LoadLibraryW/LoadLibraryA” depending on if they take a wide unicode string or a standard ASCII string. If every string is always assumed to be unicode, this isn’t an issue.

But what if we have a string only containing characters included in the ASCII table (0-127), for example: The quick brown fox jumps over the lazy dog”. It feels redundant to add an extra 00 byte after each character, doesn’t it?

So I thought I could create a class that stores strings in memory with ASCII encoding rather than unicode, meaning we could essentially half the memory usage for each string object. But after some googling I found out Jon Skeet had a great article about this very subject. I’m gonna base my struct on his example, but extend it a bit to make it a bit easier to use in your code.

View the struct here: http://pastebin.com/tLhzTacj

Keep in mind it’s not finished, and there’s just very basic safety checks which needs to be improved. But the struct should you give you an idea on how it could be done. If you wish to take the challenge on completing the struct to mimic the .NET string better, you could look at the .NET String implementation and work from there. Also, there’s some neat implicit operator overloads that allow you to do this:

 static void Main(string[] args)
     AsciiString str1 = "hello world"; // about half memory of str2
     string str2 = "hello world";      // about double memory of str1



But enough talk. Let’s take a look at the memory usage of these two strings:

String of size 100:

ss (2014-05-27 at 12.17.53)

String of size 1000:

ss (2014-05-27 at 12.18.35)

You have to keep in mind though that since there’s no official support for Ascii strings in .NET the AsciiString object will be converted back to a full size unicode string when used in methods accepting a .NET string. Let’s just hope that in the future the .NET developers might consider adding an additional type and native support for this. 🙂

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: http://www.multiupload.nl/UR4EBGQ3BT

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