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.
In this paper I’ll show you crack a 64-bit loader. The reason I made this paper is because most unpackers/dumpers cannot process a 64-bit application. So this creates some issues when trying to retrieve the packed assembly that’s being loaded. I’ll show you how you can use WinDbg to dump most .NET loaders.
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 http://geekswithblogs.net/ilich/archive/2013/07/09/.net-compilation-part-1.-just-in-time-compiler.aspx 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: http://www.codeproject.com/Articles/26060/NET-Internals-and-Code-Injection#JIT_Hooking_Example.