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:
If you have used Reflexil before you’ll find a familiar interface in the instruction editor in dnEditor:
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.
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.
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.
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).
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.