## Navigating to static constructors (.cctor) in MSIL

When reverse engineering .Net code, either with an interactive disassembler or by programmatically parsing the MSIL headers. There is some low hanging fruit and some fruit that is out of reach, unless you are a giraffe.

In IDA Pro one of the items that you never see explicitly referenced are the static constructors (.cctor). In malware these are popular as they can be added to an existing class and they are executed once and only once prior to the instance constructor (.ctor) being called. Which means that someone can take the existing class and add a static constructor to it that performs stealth, malicious behaviour without changing the code's flow.

So How do we get to these?

Dropping to the byte level. The .Net metadata header is effectively a relational database. It has tables for each object e.g. types, namespaces, methods and rows in each table. Each row contains various flags or indices into other tables. Hence why I like to think of it as a relational database.

Each user defined class will be present in what's known as the TypeDef table, this is referenced at the MSIL level as

060000 | 02 where the 02 references a specific table, namely TypeDef and in this example we're looking at row 6.

Parsing these tables is another story that is clearly defined in the ECMA CIL Partition 2 : metadata and semantics.

Once you navigate to a TypeDef row you have the following datastructure

• Flags (bitmask of type TypeAttributes) - DWORD
• Name (index into String heap) - WORD
• Namespace (index into #Strings heap) - WORD
• Extends - WORD
• FieldList (index into field table) - WORD
• MethodList (index into method table) - WORD

So from the name index we can find out what the name of the user defined type is, this is useful if you want to know about a specific class by name. Also we can find out what namespace it belongs to, you'd think that there would be a similar hierarchical reference from a namespace table to the types within it, but I don't know of such a reference.

The best parts about this datastructure are the lists, they point to the head of a contiguous block of methods or fields in there respective tables that belong to the type (class).

You probably realize where this is going, if you need to find the .cctor you could look at each row in the method table belonging to the type to see if it is the .cctor method (note that name is immune to fuzzing/obfuscation as it is reserved by the .Net runtime). Each row in the MethodDef takes following form:

• RVA to method's MSIL - DWORD
• ImplFlags (bitmask of type MethodImplAttributes) - WORD
• Flags (bitmask of type MethodAttribute) - WORD
• Name (index into String heap) - WORD
• Signature (index into Blob heap) - WORD
• ParamList (index into Param table) - WORD

So you can use the name index to check the name the method within the #Strings stream (.Net ususally having 5 streams #~/#-, #Strings,#US,#GUID,#Blob). Then once you've confirmed it's the .cctor, you'll have access to the method's MSIL via the RVA.

One snag with the design of these List head indices is that the stop condition is defined by either the end of the table or the head index of the next contiguous run of method, fields or params, which will be pointed to by the next row in the parent table.

Assuming the first method in the list was indeed the static constructor (which sadly it usually is) the goofy, pseudo-SQL would be:  SQL SELECT t.name, m.RVA FROM Types t INNER JOIN Methods m ON m.id = t.mlisthead JOIN Strings s ON s.id = m.id WHERE s.name = '.cctor'  SQL _This goofy illustrative SQL was not well thought out, or even tested_