Dissecting ConfuserEx - Invalid metadataWritten for http://www.rtn-team.cc/ by ubbelol

In this paper I’ll cover how the Invalid metadata protection works in ConfuserEx. This protection has been around in Confuser for a long time, and it’s quite effective against decompilers.

Introduction

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.

If you’re interested in this kind of stuff, feel free to check out my blog where I’ll try to put up more content similar to this: http://ubbecode.wordpress.com/

A few examples:

Reflector:

ILSpy:

DotNetResolver:

Before I start I just want to mention that I’m not gonna be going over how to reverse each metadata entry, instead I’ll just try to describe how it’s done and what it does. Additionally, de4dot has a great engine, and it’s able to automatically detect what metadata is not valid and

remove it. So running this file through the latest de4dot will quickly remove all invalid metadata and restore it to it’s original state.

Let’s start by taking a look at the difference between an unprotected file and a protected one in CFF explorer:

Protected: Unprotected:

←→

The very first thing we see is that the protected assembly has some additional Metadata streams. ConfuserEx injects an additional #Blob, #Strings, #Schema stream. The second #Strings stream is what causes Reflector to crash. But what do these streams contain?

← ← ←

The answer is nothing. These needs to be removed in order for most decompilers to work.

Now let’s take a look at the Metadata tables:

We can see that there’s an additional Assembly row along with an additional Module row. These 2 are notorious for causing issues with decompilers and have done so since a long time ago. It also adds 8 to 16 rows in the ENCLog and ENCMap tables:

int r = random.NextInt32(8, 16);

for (int i = 0; i < r; i++)

writer.MetaData.TablesHeap.ENCLogTable.Add(

new RawENCLogRow(random.NextUInt32(),

random.NextUInt32()));

r = random.NextInt32(8, 16);

for (int i = 0; i < r; i++)

writer.MetaData.TablesHeap.ENCMapTable.Add(

new RawENCMapRow(random.NextUInt32()));

These all have a Token (and FuncCode) column, which points to a dummy value:

Another interesting thing is the PE sections:

Protected: Unprotected:

←→

We can see that there’s an additional section added, and all names are erased. What is this section used for? Let’s take a peek into ConfuserEx source and look:

var newSection = new PESection("", 0xE0000040);

writer.Sections.Insert(0, newSection);

alignment = writer.TextSection.Remove(writer.MethodBodies).Value;

newSection.Add(writer.MethodBodies, alignment);

alignment = writer.TextSection.Remove(writer.Constants).Value;

newSection.Add(writer.Constants, alignment);

It looks like it writes method bodies and constants into this new section. Let’s disassemble the section to see if this is true:

It does indeed look like these are valid methods. But if the method bodies are all in the new section, what happens to the RVA’s in the Method table?

They definitely have strange addresses. Let’s try and follow 0053017A in the Address Converter:

← translates into file offset 0.

This makes it much harder to locate what method body is associated with what method.

This is essentially what the Invalid metadata protection does. There are also a few more minor things that happen, such as shuffling of metadata table rows, erasing names etc. But once again, de4dot is able to automatically fix all these changes back to it’s original state, so there’s not much more for me to go over.

Thanks for reading.