The .NET File Format

Index

• Introduction
• Getting Started
• .NET PE Files
• The .NET Directory
• The MetaData Section
• The MetaData Tables
• Methods
• The #Blob Stream
• Conclusions

Introduction

The standards of the .NET format are public, you can find them on Microsoft and in your .NET SDK (look after "Partition II Metadata.doc"), but they are intended to be more like a reference, not really a guide. So, the truth is that a description of the format can be useful. I mean, there's a huge difference between having the WinNT.h and having the full explanation of its structures and stuff. The documentation given by Microsoft has some explanations, but a lot of passages aren't very clear at all. Of course, it's required that you know quite well the PE File Format. If that's not the case, you should start with that first, otherwise you won't be able to make heads or tails of this article. A little warning: I'm not going to explain how to use the libraries given by Microsoft to access the .NET format, I'm going to explain the format itself. This article is based on the Framework 2.0.

Getting Started

The only existing tool (at the moment) for viewing and editing the .NET format is my CFF Explorer. I'm sorry for the spam, but you need this tool to dig into the internal structures of the .NET format. I programmed it for this reason in the first place. The reference you could eventually need is the one I mentioned above, and you can find the includes in your Framework SDK "Include" directory (i.e., "C:\...\Microsoft.NET\SDK\v2.0\include").

.NET PE Files

Before we start with MetaData and other stuff, some small observations about .NET PEs are necessary. They all have, for default, three sections: .text, .reloc, .rsrc. The .text section contains the Import Table, the Import Address Table, and the .NET Section. The .reloc is just there to relocate the address which the EntryPoint instruction jumps to (it's the only address contained in the IAT). The IT counts just one imported module (mscoree.dll) and one imported function (_CorExeMain for executables and _CorDllMain for dynamic load libraries). The .rsrc section contains just the main icon for an executable, since all other resources are in the .NET Section. The sections flags are checked at runtime, if you change them the assembly won't start.

The .NET Directory

The obsolete COM Directory in PEs is now the .NET Directory (I call it this way). This sections starts with the COR20 structure, also known as the CLI header:

// COM+ 2.0 header structure.

typedef struct IMAGE_COR20_HEADER
{
    // Header versioning

   DWORD                   cb;              
   WORD                    MajorRuntimeVersion;
   WORD                    MinorRuntimeVersion;
    // Symbol table and startup information

   IMAGE_DATA_DIRECTORY    MetaData;        
   DWORD                   Flags;           
    // DDBLD - Added next section to replace following lin

    // DDBLD - Still verifying, since not in NT SDK

    // DWORD                   EntryPointToken;

    // If COMIMAGE_FLAGS_NATIVE_ENTRYPOINT is not set, 

    // EntryPointToken represents a managed entrypoint.

    // If COMIMAGE_FLAGS_NATIVE_ENTRYPOINT is set, 

    // EntryPointRVA represents an RVA to a native entrypoint.

   union {
      DWORD               EntryPointToken;
      DWORD               EntryPointRVA;
   };
    // DDBLD - End of Added Area

    
    // Binding information

   IMAGE_DATA_DIRECTORY    Resources;
   IMAGE_DATA_DIRECTORY    StrongNameSignature;

    // Regular fixup and binding information

   IMAGE_DATA_DIRECTORY    CodeManagerTable;
   IMAGE_DATA_DIRECTORY    VTableFixups;
   IMAGE_DATA_DIRECTORY    ExportAddressTableJumps;

    // Precompiled image info (internal use only - set to zero)

   MAGE_DATA_DIRECTORY    ManagedNativeHeader;
    
}IMAGE_COR20_HEADER, *PIMAGE_COR20_HEADER;

A brief description of the members:

• cb: Size of the structure.
• MajorRuntimeVersion and MinorRuntimeVersion: Version of the CLR Runtime.
• MetaData: A Data Directory giving the RVA and the size of the MetaData.
• Flags: These are the supported flags.

  typedef enum ReplacesCorHdrNumericDefines
  {
      // COM+ Header entry point flags.
  
     COMIMAGE_FLAGS_ILONLY               =0x00000001,
     COMIMAGE_FLAGS_32BITREQUIRED        =0x00000002,
     COMIMAGE_FLAGS_IL_LIBRARY           =0x00000004,
     COMIMAGE_FLAGS_STRONGNAMESIGNED     =0x00000008,
      // DDBLD - Added Next Line - Still verifying general usage
  
     COMIMAGE_FLAGS_NATIVE_ENTRYPOINT    =0x00000010,
      // DDBLD - End of Add
  
     COMIMAGE_FLAGS_TRACKDEBUGDATA       =0x00010000,
      // Other kinds of flags follow
  
  } ReplacesCorHdrNumericDefines;

• EntryPointToken and EntryPointRVA: Point to the EntryPoint method (the .NET one, this has nothing to do with the field in the Optional Header). Depending on if it's native or IL, it's an RVA or a Token. I'll explain what a token is in the MetaData paragraph.
• Resources: A Data Directory for the resources. These resources are referenced in the MetaData.
• StrongNameSignature: A Data Directory for the Strong Name Signature. It's a signature to uniquely identify .NET assemblies. This section is only present when the COMIMAGE_FLAGS_STRONGNAMESIGNED is set. It affects some fields in the MetaData as well (you'll see later). You can find detailed explanations about how the Strong Name Signature works and its implementation, over the internet.
• CodeManagerTable: Always 0.
• VTableFixups: I quote from the SDK: "Certain languages, which choose not to follow the common type system runtime model, may have virtual functions which need to be represented in a v-table. These v-tables are laid out by the compiler, not by the runtime. Finding the correct v-table slot and calling indirectly through the value held in that slot is also done by the compiler. The VtableFixups field in the runtime header contains the location and size of an array of VtableFixups (§14.5.1). V-tables shall be emitted into a read-write section of the PE file. Each entry in this array describes a contiguous array of v-table slots of the specified size. Each slot starts out initialized to the metadata token value for the method they need to call. At image load time, the runtime loader will turn each entry into a pointer to the machine code for the CPU and can be called directly." And this is everything you'll find here about VTableFixups.
• ExportAddressTableJumps: Always 0.
• ManagedNativeHeader: Always 0 in normal .NET assemblies, only present in native images.

Okay, now let's begin with the main subject.

The MetaData Section

This section begins with a header that I called the MetaData Header (yes, I'm full of imagination indeed). Let's take a look at this header (since it's a dynamic header, it makes no sense declaring a structure, I'll just list the members):

• Signature: It's a simple DWORD-signature (similar to the ones you find in the DOS Header and the Optional Header). Anyway, the value of this signature has to be 0x424A5342.
• MajorVersion and MinorVersion: Two word elements that are totally ignored by the loader. The value is 0x0001 for both.
• Reserved: A DWORD, the value of which is always 0.
• Length: The length of the UTF string that follows (it's the version string, something like: "v1.1.4322"). The length has to be rounded up to a multiple of 4.
• Version: The string we just talked about.
• Flags: Reserved, this word is always 0.
• Streams: A word telling us the number of streams present in the MetaData.
• StreamHeaders: Every stream has a name, an offset, and a size. The number of stream headers is given by the number above.

But what is a stream? A stream is a "section" in the MetaData which contains a specific kind of data. A stream header is made of two DWORDs (an offset and a size) and an ASCII string aligned to the next 4-byte boundary. Take a look:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00074690                                        6C 00 00 00               l...
000746A0   FA 37 01 00 23 53 74 72  69 6E 67 73 00 00 00 00   ú7..#Strings....
000746B0   68 38 01 00 15 6F 00 00  23 55 53 00 80 A7 01 00   h8...o..#US.ۤ..
000746C0   94 B3 00 00 23 42 6C 6F  62 00 00 00 14 5B 02 00   ”³..#Blob....[..
000746D0   10 00 00 00 23 47 55 49  44 00 00 00 24 5B 02 00   ....#GUID...$[..
000746E0   EC 59 02 00 23 7E 00 00                            ìY..#~..

I marked every last byte of every Stream Header. As you can see, the string (plus its terminator) is always rounded up to 4. I think seeing it in a hex editor makes it easier to understand the disposition.

The offset in a Stream Header is not a File Offset, but an offset you have to add to the MetaData Header offset to obtain a File Offset. In other words, the offset is relative to the start of the MetaData section.

Default streams are:

• #Strings: An array of ascii strings. The strings in this stream are referenced by MetaData Tables (I'll explain later). These stream contains UTF8 strings with a null terminator byte.
• #US: Array of unicode strings. The name stands for User Strings, and these strings are referenced directly by code instructions (ldstr). This stream starts with a null byte exactly like the #Blob one. Each entry of this stream begins with a 7bit encoded integer which tells us the size of the following string (the size is in bytes, not characters). Moreover, there's an additional byte at the end of the string (so that every string size is odd and not even). This last byte tells the framework if any of the characters in the string has its high byte set or if the low byte is any of these particular values: 0x01–0x08, 0x0E–0x1F, 0x27, 0x2D.
• #Blob: Contains data referenced by MetaData Tables. I cannot talk about this stream before explaining the MetaData Tables. I mean, you will understand this stream along with the MetaData Tables. I will add a brief description about this stream afterwards.
• #GUID: Contains 128 bits long unique identifiers. Also referenced in MetaData Tables.
• #~: The most important stream. It contains the MetaData Tables, and is, for this reason, the main subject of this article. I cannot make a brief description of this stream: a new paragraph is necessary.

The MetaData Tables

They are also known as #~ Stream. This stream begins with a header I call "MetaData Tables Header", here are the members:

• Reserved: The first DWORD is always 0.
• MajorVersion and MinorVersion: Two bytes.
• HeapOffsetSizes: This field is very important, it's a byte that tells us the size that indexes in to the "#String", "#GUID" and "#Blob" streams will have. I quote here the description and the bit mask details from the SDK:

"The HeapSizes field is a bit vector that encodes how wide indexes into the various heaps are. If bit 0 is set, indexes into the "#String" heap are 4 bytes wide; if bit 1 is set, indexes into the "#GUID" heap are 4 bytes wide; if bit 2 is set, indexes into the "#Blob" heap are 4 bytes wide. Conversely, if the HeapSizes bit for a particular heap is not set, indexes into that heap are 2 bytes wide."

Bit mask	Description
0x01	Size of "#String" stream >= 2^16.
0x02	Size of "#GUID" stream >= 2^16
0x04	Size of "#Blob" stream >= 2^16.

• Reserved: BYTE, always 1.
• Valid: It's a bitmask-QWORD that tells us which MetaData Tables are present in the assembly. Of course, since this is a QWORD, the maximum number of tables is 64. However, most of the tables aren't defined yet. So, the high bits of this QWORD are always 0.
• Sorted: Also a bitmask-QWORD. It tells us which tables are sorted.

Following this, there's an array of DWORDs with the number of rows for each table present. OK, this has to be explained. For every table, there can be n rows. Let's say we have three tables: A, B, and C. And the Valid mask tells us that the B table is not present, but A and C are. In this case, there will be two DWORDs (not three), one for the rows in the A table and one for the C table. The B table rows are skipped since there is no B table in the assembly.

Following the array, we will find the actual MetaData Tables. The defined tables are:

00 - Module                  01 - TypeRef                02 - TypeDef
04 - Field                   06 - MethodDef              08 - Param
09 - InterfaceImpl           10 - MemberRef              11 - Constant
12 - CustomAttribute         13 - FieldMarshal           14 - DeclSecurity
15 - ClassLayout             16 - FieldLayout            17 - StandAloneSig
18 - EventMap                20 - Event                  21 - PropertyMap
23 - Property                24 - MethodSemantics        25 - MethodImpl
26 - ModuleRef               27 - TypeSpec               28 - ImplMap
29 - FieldRVA                32 - Assembly               33 - AssemblyProcessor
34 - AssemblyOS              35 - AssemblyRef            36 - AssemblyRefProcessor
37 - AssemblyRefOS           38 - File                   39 - ExportedType
40 - ManifestResource        41 - NestedClass            42 - GenericParam
44 - GenericParamConstraint

As you can see, some numbers are missing, that's because some tables, as I said before, are not defined yet. It's important you understand how the tables are stored. A table is made of an array of rows; a row is a structure (let's call it this way for the moment, to make things easier). After the rows of a given table end, the rows of the next table follow. The problem with a row (remember, think of it like a structure) is that some of its fields aren't always of the same size and they change from assembly to assembly, so you have to calculate them dynamically. For example, I talked about the HeapOffsetSizes field and how it tells us the size that indexes into the "#String", "#GUID", and "#Blob" streams will have; this means, if I have in a structure of one of these tables, an index into the "#String" stream, its size is determined by HeapOffsetSizes, and so it could be a WORD or a DWORD. Of course, that's not the only kind of index that can change in size, there are others. A very simple one to calculate is a direct index into another table.

For example, the first element of a NestedClass row is an index into the TypeDef table, the size of this index depends on how much rows the TypeDef table counts: if the rows are > 0xFFFF, a DWORD is necessary to store the number, otherwise a WORD will do the job. The remaining indexes are the most annoying, they can index into a table or another. The Microsoft documentation is not so clear about this (at all), so I'll try to explain it in an easy way.

Let's consider the TypeDefOrRefIndex, this is a kind of index that can either reference a row in the TypeRef table, in the TypeDef table, or in the TypeSpec table. The low bits of the value tell us which table is being indexed and the remaining bits represent the actual index; since the choice is between three tables, it only takes two bits to encode the table for this kind of an index. So if we have a WORD and the two low bits are reserved to encode the table that is being indexed, the remaining 14 bits can index a row in one of the three tables, but what if one of those three tables has more rows than a value of 14 bits can encode? Well, then a DWORD is needed. So, to get the size of an index like this, it's necessary to compare the rows of each table it can reference, get the table with the biggest number of rows, and then see if this number fits into the remaining bits of a WORD, if not, a DWORD is required. I quote here from the SDK, the list of this kind of indexes and the values to encode the tables for each index type (which is the "Tag" column):

TypeDefOrRef: 2 bits to encode tag	Tag
TypeDef	0
TypeRef	1
TypeSpec	2

HasConstant: 2 bits to encode tag	Tag
FieldDef	0
ParamDef	1
Property	2

HasCustomAttribute: 5 bits to encode tag	Tag
MethodDef	0
FieldDef	1
TypeRef	2
TypeDef	3
ParamDef	4
InterfaceImpl	5
MemberRef	6
Module	7
Permission	8
Property	9
Event	10
StandAloneSig	11
ModuleRef	12
TypeSpec	13
Assembly	14
AssemblyRef	15
File	16
ExportedType	17
ManifestResource	18

HasFieldMarshall: 1 bit to encode tag	Tag
FieldDef	0
ParamDef	1

HasDeclSecurity: 2 bits to encode tag	Tag
TypeDef	0
MethodDef	1
Assembly	2

MemberRefParent: 3 bits to encode tag	Tag
TypeDef	0
TypeRef	1
ModuleRef	2
MethodDef	3
TypeSpec	4

HasSemantics: 1 bit to encode tag	Tag
Event	0
Property	1

MethodDefOrRef: 1 bit to encode tag	Tag
MethodDef	0
MemberRef	1

MemberForwarded: 1 bit to encode tag	Tag
FieldDef	0
MethodDef	1

Implementation: 2 bits to encode tag	Tag
File	0
AssemblyRef	1
ExportedType

CustomAttributeType: 3 bits to encode tag	Tag
Not used	0
Not used	1
MethodDef	2
MemberRef	3
Not used	4

ResolutionScope: 2 bits to encode tag	Tag
Module	0
ModuleRef	1
AssemblyRef	2
TypeRef	3

OK, I hope what I wrote above is clear. If not, you should try reading it again... and again. Now, I will list each table, give a brief description of it (and whatever I have to say in addition) and list (copy them from the SDK) its columns. Ah, before I forget, a token is a DWORD-value that represents a table and an index into that table. For example, the EntryPointToken 0x0600002C references table 0x06 (MethodDef) and its row 0x2C. I think this is pretty simple to understand if you understood all the other stuff.

00 - Module Table

It's a one row table representing the current assembly.

Columns:

• Generation (2-byte value, reserved, shall be zero).
• Name (index into the String heap).
• Mvid (index into the GUID heap; simply a GUID used to distinguish between two versions of the same module).
• EncId (index into GUID heap, reserved, shall be zero).
• EncBaseId (index into GUID heap, reserved, shall be zero).

01 - TypeRef Table

Each row represents an imported class, its namespace, and the assembly which contains it.

Columns:

• ResolutionScope (index into Module, ModuleRef, AssemblyRef or TypeRef tables, or null; more precisely, a ResolutionScope coded index).
• TypeName (index into String heap).
• TypeNamespace (index into String heap).

02 - TypeDef Table

Each row represents a class in the current assembly.

Columns:

• Flags (a 4-byte bit mask of type TypeAttributes).
• TypeName (index into String heap).
• TypeNamespace (index into String heap).
• Extends (index into TypeDef, TypeRef or TypeSpec table; more precisely, a TypeDefOrRef coded index).
• FieldList (index into Field table; it marks the first of a continuous run of fields owned by this type). The run continues to the smaller of:
  • the last row of the Field table.
  • the next run of Fields, found by inspecting the FieldList of the next row in this TypeDef table.
• MethodList (index into MethodDef table; it marks the first of a continuous run of methods owned by this type). The run continues to the smaller of:
  • the last row of the MethodDef table.
  • the next run of Methods, found by inspecting the MethodList of the next row in this TypeDef table.

The available flags are:

typedef enum CorTypeAttr
{
       // Use this mask to retrieve the type visibility information.

    tdVisibilityMask        =   0x00000007,
    tdNotPublic             =   0x00000000,     
       // Class is not public scope.

    tdPublic                =   0x00000001,     
       // Class is public scope.

    tdNestedPublic          =   0x00000002,     
       // Class is nested with public visibility.

    tdNestedPrivate         =   0x00000003,     
       // Class is nested with private visibility.

    tdNestedFamily          =   0x00000004,     
       // Class is nested with family visibility.

    tdNestedAssembly        =   0x00000005,     
       // Class is nested with assembly visibility.

    tdNestedFamANDAssem     =   0x00000006,     
       // Class is nested with family and assembly visibility.

    tdNestedFamORAssem      =   0x00000007,     
       // Class is nested with family or assembly visibility.


       // Use this mask to retrieve class layout information

    tdLayoutMask            =   0x00000018,
    tdAutoLayout            =   0x00000000,     
       // Class fields are auto-laid out

    tdSequentialLayout      =   0x00000008,     
       // Class fields are laid out sequentially

    tdExplicitLayout        =   0x00000010,     
       // Layout is supplied explicitly

       // end layout mask


       // Use this mask to retrieve class semantics information.

    tdClassSemanticsMask    =   0x00000060,
    tdClass                 =   0x00000000,     
       // Type is a class.

    tdInterface             =   0x00000020,     
       // Type is an interface.

       // end semantics mask


       // Special semantics in addition to class semantics.

    tdAbstract              =   0x00000080,     
       // Class is abstract

    tdSealed                =   0x00000100,     
       // Class is concrete and may not be extended

    tdSpecialName           =   0x00000400,     
       // Class name is special. Name describes how.


       // Implementation attributes.

    tdImport                =   0x00001000,     
       // Class / interface is imported

    tdSerializable          =   0x00002000,     
       // The class is Serializable.


       // Use tdStringFormatMask to retrieve string information for native interop

    tdStringFormatMask      =   0x00030000,
    tdAnsiClass             =   0x00000000,     
       // LPTSTR is interpreted as ANSI in this class

    tdUnicodeClass          =   0x00010000,     
       // LPTSTR is interpreted as UNICODE

    tdAutoClass             =   0x00020000,     
       // LPTSTR is interpreted automatically

    tdCustomFormatClass     =   0x00030000,     
       // A non-standard encoding specified by CustomFormatMask

    tdCustomFormatMask      =   0x00C00000,     
       // Use this mask to retrieve non-standard encoding 

       // information for native interop. 

       // The meaning of the values of these 2 bits is unspecified.


       // end string format mask


    tdBeforeFieldInit       =   0x00100000,     
       // Initialize the class any time before first static field access.

    tdForwarder             =   0x00200000,     
       // This ExportedType is a type forwarder.


       // Flags reserved for runtime use.

    tdReservedMask          =   0x00040800,
    tdRTSpecialName         =   0x00000800,     
       // Runtime should check name encoding.

    tdHasSecurity           =   0x00040000,     
       // Class has security associate with it.

} CorTypeAttr;

04 - Field Table

Each row represents a field in a TypeDef class. The fields of one class are not stored casually: after the fields of one class end, the fields of the next class begin.

Columns:

• Flags (a 2-byte bit mask of type FieldAttributes).
• Name (index into String heap).
• Signature (index into Blob heap).

Available flags are:

typedef enum CorFieldAttr
{
       // member access mask - Use this mask to retrieve 

       // accessibility information.

    fdFieldAccessMask           =   0x0007,
    fdPrivateScope              =   0x0000,     
       // Member not referenceable.

    fdPrivate                   =   0x0001,     
       // Accessible only by the parent type.

    fdFamANDAssem               =   0x0002,     
       // Accessible by sub-types only in this Assembly.

    fdAssembly                  =   0x0003,     
       // Accessibly by anyone in the Assembly.

    fdFamily                    =   0x0004,     
       // Accessible only by type and sub-types.

    fdFamORAssem                =   0x0005,     
       // Accessibly by sub-types anywhere, plus anyone in assembly.

    fdPublic                    =   0x0006,     
       // Accessibly by anyone who has visibility to this scope.

       // end member access mask

       // field contract attributes.

    fdStatic                    =   0x0010,     
       // Defined on type, else per instance.

    fdInitOnly                  =   0x0020,     
       // Field may only be initialized, not written to after init.

    fdLiteral                   =   0x0040,     
       // Value is compile time constant.

    fdNotSerialized             =   0x0080,     
       // Field does not have to be serialized when type is remoted.

    fdSpecialName               =   0x0200,     
       // field is special. Name describes how.

       // interop attributes

    fdPinvokeImpl               =   0x2000,     
       // Implementation is forwarded through pinvoke.

       // Reserved flags for runtime use only.

    fdReservedMask              =   0x9500,
    fdRTSpecialName             =   0x0400,     
       // Runtime(metadata internal APIs) should check name encoding.

    fdHasFieldMarshal           =   0x1000,     
       // Field has marshalling information.

    fdHasDefault                =   0x8000,     
       // Field has default.

    fdHasFieldRVA               =   0x0100,     
       // Field has RVA.

} CorFieldAttr;

06 - MethodDef Table

Each row represents a method in a specific class. The method's sequence follows the same logic as the field's one.

Columns:

• RVA (a 4-byte constant).
• ImplFlags (a 2-byte bit mask of type MethodImplAttributes).
• Flags (a 2-byte bit mask of type MethodAttribute).
• Name (index into String heap).
• Signature (index into Blob heap)
• ParamList (index into the Param table). It marks the first of a contiguous run of Parameters owned by this method. The run continues to the smaller of:
  • The last row of the Param table.
  • The next run of Parameters, found by inspecting the ParamList of the next row in the MethodDef table

Available flags are:

typedef enum CorMethodAttr
{
       // member access mask - Use this mask to retrieve 

       // accessibility information.

    mdMemberAccessMask          =   0x0007,
    mdPrivateScope              =   0x0000,     
       // Member not referenceable.

    mdPrivate                   =   0x0001,     
       // Accessible only by the parent type.

    mdFamANDAssem               =   0x0002,     
       // Accessible by sub-types only in this Assembly.

    mdAssem                     =   0x0003,     
       // Accessibly by anyone in the Assembly.

    mdFamily                    =   0x0004,     
       // Accessible only by type and sub-types.

    mdFamORAssem                =   0x0005,     
       // Accessibly by sub-types anywhere, plus anyone in assembly.

    mdPublic                    =   0x0006,     
       // Accessibly by anyone who has visibility to this scope.

       // end member access mask


       // method contract attributes.

    mdStatic                    =   0x0010,     
       // Defined on type, else per instance.

    mdFinal                     =   0x0020,     
       // Method may not be overridden.

    mdVirtual                   =   0x0040,     
       // Method virtual.

    mdHideBySig                 =   0x0080,     
       // Method hides by name+sig, else just by name.


       // vtable layout mask - Use this mask to retrieve vtable attributes.

    mdVtableLayoutMask          =   0x0100,
    mdReuseSlot                 =   0x0000,     // The default.

    mdNewSlot                   =   0x0100,     
       // Method always gets a new slot in the vtable.

       // end vtable layout mask


       // method implementation attributes.

    mdCheckAccessOnOverride     =   0x0200,     
       // Overridability is the same as the visibility.

    mdAbstract                  =   0x0400,     
       // Method does not provide an implementation.

    mdSpecialName               =   0x0800,     
       // Method is special. Name describes how.


       // interop attributes

    mdPinvokeImpl               =   0x2000,     
       // Implementation is forwarded through pinvoke.

    mdUnmanagedExport           =   0x0008,     
       // Managed method exported via thunk to unmanaged code.


       // Reserved flags for runtime use only.

    mdReservedMask              =   0xd000,
    mdRTSpecialName             =   0x1000,     
       // Runtime should check name encoding.

    mdHasSecurity               =   0x4000,     
       // Method has security associate with it.

    mdRequireSecObject          =   0x8000,     
       // Method calls another method containing security code.


} CorMethodAttr;

typedef enum CorMethodImpl
{
    // code impl mask
    miCodeTypeMask      =   0x0003,   // Flags about code type.
    miIL                =   0x0000,   // Method impl is IL.
    miNative            =   0x0001,   // Method impl is native.
    miOPTIL             =   0x0002,   // Method impl is OPTIL
    miRuntime           =   0x0003,   // Method impl is provided by the runtime.
    // end code impl mask

    // managed mask
    miManagedMask       =   0x0004,   // Flags specifying whether the code is managed
                                      // or unmanaged.
    miUnmanaged         =   0x0004,   // Method impl is unmanaged, otherwise managed.
    miManaged           =   0x0000,   // Method impl is managed.
    // end managed mask

    // implementation info and interop
    miForwardRef        =   0x0010,   // Indicates method is defined; used primarily
                                      // in merge scenarios.
    miPreserveSig       =   0x0080,   // Indicates method sig is not to be mangled to
                                      // do HRESULT conversion.

    miInternalCall      =   0x1000,   // Reserved for internal use.

    miSynchronized      =   0x0020,   // Method is single threaded through the body.
    miNoInlining        =   0x0008,   // Method may not be inlined.
    miMaxMethodImplVal  =   0xffff,   // Range check value
} CorMethodImpl;

The RVA points to the method body, I'll explain the format of that later. The Signature gives information about the method declaration. Remember that the data stored in the #Blob stream follows 7 bit encoding/decoding rules.

08 - Param Table

Each row represents a method's parameter.

Columns:

• Flags (a 2-byte bit mask of type ParamAttributes).
• Sequence (a 2-byte constant).
• Name (index into String heap).

Available flags are:

typedef enum CorParamAttr
{
    pdIn                        =   0x0001,     // Param is [In]

    pdOut                       =   0x0002,     // Param is [out]

    pdOptional                  =   0x0010,     // Param is optional


    // Reserved flags for Runtime use only.

    pdReservedMask              =   0xf000,
    pdHasDefault                =   0x1000,     // Param has default value.

    pdHasFieldMarshal           =   0x2000,     // Param has FieldMarshal.


    pdUnused                    =   0xcfe0,
} CorParamAttr;

09 - InterfaceImpl Table

Each row tells the framework a class that implements a specific interface.

Columns:

• Class (index into the TypeDef table).
• Interface (index into the TypeDef, TypeRef or TypeSpec table; more precisely, a TypeDefOrRef coded index).

10 - MemberRef Table

Also known as the MethodRef table. Each row represents an imported method.

Columns:

• Class (index into the TypeRef, ModuleRef, MethodDef, TypeSpec, or TypeDef tables; more precisely, a MemberRefParent coded index).
• Name (index into String heap)
• Signature (index into Blob heap)

11 - Constant Table

Each row represents a constant value for a Param, Field, or Property.

Columns:

• Type (a 1-byte constant, followed by a 1-byte padding zero).
• Parent (index into the Param or Field or Property table; more precisely, a HasConstant coded index)
• Value (index into Blob heap)

12 - CustomAttribute Table

I think the best description is given by the SDK: "The CustomAttribute table stores data that can be used to instantiate a Custom Attribute (more precisely, an object of the specified Custom Attribute class) at runtime. The column called Type is slightly misleading – it actually indexes a constructor method – the owner of that constructor method is the Type of the Custom Attribute."

Columns:

• Parent (index into any metadata table, except the CustomAttribute table itself; more precisely, a HasCustomAttribute coded index).
• Type (index into the MethodDef or MethodRef table; more precisely, a CustomAttributeType coded index).
• Value (index into Blob heap).

13 - FieldMarshal Table

Each row tells the way a Param or Field should be treated when called from/to unmanaged code.

Columns:

• Parent (index into Field or Param table; more precisely, a HasFieldMarshal coded index).
• NativeType (index into the Blob heap).

14 - DeclSecurity Table

Security attributes attached to a class, method or assembly.

Columns:

• Action (2-byte value).
• Parent (index into the TypeDef, MethodDef, or Assembly table; more precisely, a HasDeclSecurity coded index).
• PermissionSet (index into Blob heap).

15 - ClassLayout Table

Remember "#pragma pack(n)" for VC++? Well, this is kind of the same thing for .NET. It's useful when handing something from managed to unmanaged code.

Columns:

• PackingSize (a 2-byte constant).
• ClassSize (a 4-byte constant).
• Parent (index into TypeDef table).

16 - FieldLayout Table

Related with the ClassLayout.

Columns:

• Offset (a 4-byte constant).
• Field (index into the Field table).

17 - StandAloneSig Table

Each row represents a signature that isn't referenced by any other table.

Columns:

• Signature (index into the Blob heap).

18 - EventMap Table

List of events for a specific class.

Columns:

• Parent (index into the TypeDef table).
• EventList (index into Event table). It marks the first of a contiguous run of Events owned by this Type. The run continues to the smaller of:
  • The last row of the Event table.
  • The next run of Events, found by inspecting the EventList of the next row in the EventMap table.

20 - Event Table

Each row represents an event.

Columns:

• EventFlags (a 2-byte bit mask of type EventAttribute).
• Name (index into String heap)
• EventType (index into TypeDef, TypeRef, or TypeSpec tables; more precisely, a TypeDefOrRef coded index) [this corresponds to the Type of the Event; it is not the Type that owns this event].

Available flags are:

typedef enum CorEventAttr
{
    evSpecialName           =   0x0200,     
       // event is special. Name describes how.


       // Reserved flags for Runtime use only.

    evReservedMask          =   0x0400,
    evRTSpecialName         =   0x0400,     
       // Runtime(metadata internal APIs) should check name encoding.

} CorEventAttr;

21 - PropertyMap Table

List of Properties owned by a specific class.

Columns:

• Parent (index into the TypeDef table).
• PropertyList (index into Property table). It marks the first of a contiguous run of Properties owned by Parent. The run continues to the smaller of:
  • The last row of the Property table.
  • The next run of Properties, found by inspecting the PropertyList of the next row in this PropertyMap table.

23 - Property Table

Each row represents a property.

Columns:

• Flags (a 2-byte bit mask of type PropertyAttributes).
• Name (index into String heap).
• Type (index into Blob heap). [The name of this column is misleading. It does not index a TypeDef or TypeRef table – instead it indexes the signature in the Blob heap of the Property.)

Available flags are:

typedef enum CorPropertyAttr
{
    prSpecialName           =   0x0200,     
       // property is special. Name describes how.


       // Reserved flags for Runtime use only.

    prReservedMask          =   0xf400,
    prRTSpecialName         =   0x0400,     
       // Runtime(metadata internal APIs) should check name encoding.

    prHasDefault            =   0x1000,     // Property has default


    prUnused                =   0xe9ff,
} CorPropertyAttr;

24 - MethodSemantics Table

Links Events and Properties to specific methods. For example, an Event can be associated to more methods. A property uses this table to associate get/set methods.

Columns:

• Semantics (a 2-byte bit mask of type MethodSemanticsAttributes).
• Method (index into the MethodDef table).
• Association (index into the Event or Property table; more precisely, a HasSemantics coded index).

Available flags are:

typedef enum CorMethodSemanticsAttr
{
    msSetter    =   0x0001,     // Setter for property

    msGetter    =   0x0002,     // Getter for property

    msOther     =   0x0004,     // other method for property or event

    msAddOn     =   0x0008,     // AddOn method for event

    msRemoveOn  =   0x0010,     // RemoveOn method for event

    msFire      =   0x0020,     // Fire method for event

} CorMethodSemanticsAttr;

25 - MethodImpl Table

I quote: "MethodImpls lets a compiler override the default inheritance rules provided by the CLI. Their original use was to allow a class "C", that inherited method "Foo" from interfaces I and J, to provide implementations for both methods (rather than have only one slot for "Foo" in its vtable). But MethodImpls can be used for other reasons too, limited only by the compiler writer’s ingenuity within the constraints defined in the Validation rules below.".

Columns:

• Class (index into TypeDef table).
• MethodBody (index into MethodDef or MemberRef table; more precisely, a MethodDefOrRef coded index).
• MethodDeclaration (index into MethodDef or MemberRef table; more precisely, a MethodDefOrRef coded index).

26 - ModuleRef Table

Each row represents a reference to an external module.

Columns:

• Name (index into String heap).

27 - TypeSpec Table

Each row represents a specification for a TypeDef or TypeRef. The only column indexes a token in the #Blob stream.

Columns:

• Signature (index into the Blob heap).

28 - ImplMap Table

I quote: "The ImplMap table holds information about unmanaged methods that can be reached from managed code, using PInvoke dispatch. Each row of the ImplMap table associates a row in the MethodDef table (MemberForwarded) with the name of a routine (ImportName) in some unmanaged DLL (ImportScope).". This means all the unmanaged functions used by the assembly are listed here.

Columns:

• MappingFlags (a 2-byte bit mask of type PInvokeAttributes).
• MemberForwarded (index into the Field or MethodDef table; more precisely, a MemberForwarded coded index. However, it only ever indexes the MethodDef table, since Field export is not supported).
• ImportName (index into the String heap).
• ImportScope (index into the ModuleRef table).

Available flags are:

typedef enum  CorPinvokeMap
{
    pmNoMangle          = 0x0001,   
       // Pinvoke is to use the member name as specified.


       // Use this mask to retrieve the CharSet information.

    pmCharSetMask       = 0x0006,
    pmCharSetNotSpec    = 0x0000,
    pmCharSetAnsi       = 0x0002,
    pmCharSetUnicode    = 0x0004,
    pmCharSetAuto       = 0x0006,

    pmBestFitUseAssem   = 0x0000,
    pmBestFitEnabled    = 0x0010,
    pmBestFitDisabled   = 0x0020,
    pmBestFitMask       = 0x0030,

    pmThrowOnUnmappableCharUseAssem   = 0x0000,
    pmThrowOnUnmappableCharEnabled    = 0x1000,
    pmThrowOnUnmappableCharDisabled   = 0x2000,
    pmThrowOnUnmappableCharMask       = 0x3000,

    pmSupportsLastError = 0x0040,   
       // Information about target function. Not relevant for fields.


       // None of the calling convention flags is relevant for fields.

    pmCallConvMask      = 0x0700,
    pmCallConvWinapi    = 0x0100,   
       // Pinvoke will use native callconv appropriate to target windows platform.

    pmCallConvCdecl     = 0x0200,
    pmCallConvStdcall   = 0x0300,
    pmCallConvThiscall  = 0x0400,   
       // In M9, pinvoke will raise exception.

    pmCallConvFastcall  = 0x0500,

    pmMaxValue          = 0xFFFF,
} CorPinvokeMap;

29 - FieldRVA Table

Each row is an extension for a Field table. The RVA in this table gives the location of the initial value for a Field.

Columns:

• RVA (a 4-byte constant).
• Field (index into Field table).

32 - Assembly Table

It's a one-row table. It stores information about the current assembly.

Columns:

• HashAlgId (a 4-byte constant of type AssemblyHashAlgorithm).
• MajorVersion, MinorVersion, BuildNumber, RevisionNumber (2-byte constants).
• Flags (a 4-byte bit mask of type AssemblyFlags).
• PublicKey (index into Blob heap).
• Name (index into String heap).
• Culture (index into String heap).

Available flags are:

typedef enum CorAssemblyFlags
{
    afPublicKey             =   0x0001,     
       // The assembly ref holds the full (unhashed) public key.

    
    afPA_None               =   0x0000,     
       // Processor Architecture unspecified

    afPA_MSIL               =   0x0010,     
       // Processor Architecture: neutral (PE32)

    afPA_x86                =   0x0020,     
       // Processor Architecture: x86 (PE32)

    afPA_IA64               =   0x0030,     
       // Processor Architecture: Itanium (PE32+)

    afPA_AMD64              =   0x0040,     
       // Processor Architecture: AMD X64 (PE32+)

    afPA_Specified          =   0x0080,     
       // Propagate PA flags to AssemblyRef record

    afPA_Mask               =   0x0070,     
       // Bits describing the processor architecture

    afPA_FullMask           =   0x00F0,     
       // Bits describing the PA incl. Specified

    afPA_Shift              =   0x0004,     
       // NOT A FLAG, shift count in PA flags <--> index conversion


    afEnableJITcompileTracking  =   0x8000, // From "DebuggableAttribute".

    afDisableJITcompileOptimizer=   0x4000, // From "DebuggableAttribute".


    afRetargetable          =   0x0100,     
       // The assembly can be retargeted (at runtime) to an

       //  assembly from a different publisher.

} CorAssemblyFlags;

The PublicKey is != 0, only if the StrongName Signature is present and the afPublicKey flag is set.

33 - AssemblyProcessor Table

This table is ignored by the CLI and shouldn't be present in an assembly.

Columns:

• Processor (a 4-byte constant).

34 - AssemblyOS Table

This table is ignored by the CLI and shouldn't be present in an assembly.

Columns:

• OSPlatformID (a 4-byte constant).
• OSMajorVersion (a 4-byte constant).
• OSMinorVersion (a 4-byte constant).

35 - AssemblyRef Table

Each row references an external assembly.

Columns:

• MajorVersion, MinorVersion, BuildNumber, RevisionNumber (2-byte constants).
• Flags (a 4-byte bit mask of type AssemblyFlags).
• PublicKeyOrToken (index into Blob heap – the public key or token that identifies the author of this Assembly).
• Name (index into String heap).
• Culture (index into String heap).
• HashValue (index into Blob heap).

The flags are the same ones of the Assembly table.

36 - AssemblyRefProcessor Table

This table is ignored by the CLI and shouldn't be present in an assembly.

Columns:

• Processor (4-byte constant).
• AssemblyRef (index into the AssemblyRef table).

37 - AssemblyRefOS Table

This table is ignored by the CLI and shouldn't be present in an assembly.

Columns:

• OSPlatformId (4-byte constant).
• OSMajorVersion (4-byte constant).
• OSMinorVersion (4-byte constant).
• AssemblyRef (index into the AssemblyRef table).

38 - File Table

Each row references an external file.

Columns:

• Flags (a 4-byte bit mask of type FileAttributes).
• Name (index into String heap).
• HashValue (index into Blob heap).

Available flags are:

typedef enum CorFileFlags
{
    ffContainsMetaData      =   0x0000,     
       // This is not a resource file

    ffContainsNoMetaData    =   0x0001,     
       // This is a resource file or other non-metadata-containing file

} CorFileFlags;

39 - ExportedType Table

I quote: "The ExportedType table holds a row for each type, defined within other modules of this Assembly, that is exported out of this Assembly. In essence, it stores TypeDef row numbers of all types that are marked public in other modules that this Assembly comprises". Be careful, this doesn't mean that when an assembly uses a class contained in my assembly, I export that type. In fact, I haven't yet seen this table in an assembly.

Columns:

• Flags (a 4-byte bit mask of type TypeAttributes).
• TypeDefId (4-byte index into a TypeDef table of another module in this Assembly). This field is used as a hint only. If the entry in the target TypeDef table matches the TypeName and TypeNamespace entries in this table, resolution has succeeded. But if there is a mismatch, the CLI shall fall back to a search of the target TypeDef table.
• TypeName (index into the String heap).
• TypeNamespace (index into the String heap).
• Implementation. This can be an index (more precisely, an Implementation coded index) into one of 2 tables, as follows:
  • File table, where that entry says which module in the current assembly holds the TypeDef.
  • ExportedType table, where that entry is the enclosing Type of the current nested Type.

The flags are the same ones of the TypeDef.

40 - ManifestResource Table

Each row references an internal or external resource.

Columns:

• Offset (a 4-byte constant).
• Flags (a 4-byte bit mask of type ManifestResourceAttributes).
• Name (index into the String heap).
• Implementation (index into File table, or AssemblyRef table, or null; more precisely, an Implementation coded index).

Available flags are:

typedef enum CorManifestResourceFlags
{
    mrVisibilityMask        =   0x0007,
    mrPublic                =   0x0001,     
       // The Resource is exported from the Assembly.

    mrPrivate               =   0x0002,     
       // The Resource is private to the Assembly.

} CorManifestResourceFlags;

If the Implementation index is 0, then the referenced resource is internal. We obtain the File Offset of the resource by adding the converted Resources RVA (the one in the CLI Header) to the offset present in this table. I wrote an article, you can either find on NTCore or CodeProject, about Manifest Resources, anyway I quote some parts from the article to give at least a brief explanation, since this section is absolutely undocumented. There are different kinds of resources referenced by this table, and not all of them can be treated in the same way. Reading a bitmap, for example, is very simple: every Manifest Resource begins with a DWORD that tells us the size of the actual embedded resource... And that's it... After that, we have our bitmap. OK, but what about those ".resources" files? For every dialog in a .NET Assembly, there is one, which means every resource of a dialog is contained in the dialog's own ".resources" file.

A very brief description of the ".resources" files format: "The first DWORD is a signature which has to be 0xBEEFCACE, otherwise the resources file has to be considered as invalid. The second DWORD contains the number of readers for this resources file, don't worry, it's something we don't have to talk about... Framework stuff. The third DWORD is the size of reader types. This number is only good for us to skip the string (or strings) that follows, which is something like: "System.Resources.ResourceReader, mscorlibsSystem.Resources.RuntimeResourceSet, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089". It tells the framework the reader to use for the resources file.

OK, now we get to the interesting part. The next DWORD tells us the version of the resources file (existing versions are 1 and 2). After the version, another DWORD gives the number of actual resources in the file. Another DWORD follows and gives the number of resource types.

To gather the additional information we need, we have to skip the resource types. For each type, there's a 7 bit encoded integer which gives the size of the string that follows. To decode these kind of integers, you have to read every byte until you find one which hasn't the highest bit set and make some additional operations to obtain the final value... For the moment, let's just stick to the format. After having skipped the types, we have to align our position to an 8 byte base. Then we have a DWORD * NumberOfResources, and each DWORD contains the hash of a resource. Then we have the same amount of DWORDs, this time with the offsets of the resource names. Another important DWORD follows: the Data Section Offset. We need this offset to retrieve resources' offsets. After this DWORD, we have the resource names. Well, actually it's not just the names (I just call it this way), every name (7 bit encoded integer + Unicode string) is followed by a DWORD, an offset which you can add to the Data Section offset to retrieve the resource offset. The first thing we find, given a resource offset, is a 7 bit encoded integer, which is the type index for the current resource".

If you're interested in this subject, check out the other article I wrote, since there you can find code that may help you understand this better.

41 - NestedClass Table

Each row represents a nested class. You know what a nested class is, right?

There are only two columns, of course.

Columns:

• NestedClass (index into the TypeDef table).
• EnclosingClass (index into the TypeDef table).

42 - GenericParam Table

I quote: "The GenericParam table stores the generic parameters used in generic type definitions and generic methoddefinitions. These generic parameters can be constrained (i.e., generic arguments shall extend some class and/or implement certain interfaces) or unconstrained.".

Columns:

• Number (the 2-byte index of the generic parameter, numbered left-to-right, from zero)
• Flags (a 2-byte bitmask of type GenericParamAttributes)
• Owner (an index into the TypeDef or MethodDef table, specifying the Type or Method to which this generic parameter applies; more precisely, a TypeOrMethodDef coded index)
• Name (a non-null index into the String heap, giving the name for the generic parameter. This is purely descriptive and is used only by source language compilers and by Reflection)

Available flags are:

typedef enum CorGenericParamAttr
{
    // Variance of type parameters, only applicable to generic parameters 
    // for generic interfaces and delegates
    gpVarianceMask          =   0x0003,
    gpNonVariant            =   0x0000, 
    gpCovariant             =   0x0001,
    gpContravariant         =   0x0002,

    // Special constraints, applicable to any type parameters
    gpSpecialConstraintMask =  0x001C,
    gpNoSpecialConstraint   =   0x0000,      
    gpReferenceTypeConstraint = 0x0004,      // type argument must be a reference type
    gpNotNullableValueTypeConstraint   =   0x0008,      // type argument must be a value
                                                        // type but not Nullable
    gpDefaultConstructorConstraint = 0x0010, // type argument must have a public
                                             // default constructor
} CorGenericParamAttr;

44 - GenericParamConstraint Table

I quote: "The GenericParamConstraint table records the constraints for each generic parameter. Each generic parameter can be constrained to derive from zero or one class. Each generic parameter can be constrained to implement zero or more interfaces. Conceptually, each row in the GenericParamConstraint table is ‘owned’ by a row in the GenericParam table. All rows in the GenericParamConstraint table for a given Owner shall refer to distinct constraints.".

The columns needed are, of course, only two

Columns:

• Owner (an index into the GenericParam table, specifying to which generic parameter this row refers)
• Constraint (an index into the TypeDef, TypeRef, or TypeSpec tables, specifying from which class this generic parameter is constrained to derive; or which interface this generic parameter is constrained to implement; more precisely, a TypeDefOrRef coded index)

OK, that's all about MetaData tables. The last thing I have to explain, as I promised, is the Method format.

Methods

Every method contained in an assembly is referenced in the MethodDef table, the RVA tells us where the method is. The method body is made of three or at least two parts:

• A header, which can be a Fat or a Tiny one.
• The code, the code size is specified in the header.
• Extra sections. These sections are not always present, the header tells us if they are. Those sections can store different kinds of data, but for now they are only used to store Exception Sections. Those sections specify try/catch handlers in the code.

The first byte of the method tells us the type of header used. If the method uses a tiny header, the CorILMethod_TinyFormat (0x02) flag will be set, otherwise the CorILMethod_FatFormat (0x03) flag. If the tiny header is used, the two low bits are reserved for flags (header type) and the rest specify the code size. Of course, a tiny header can only be used if the code size is less than 64 bytes. In addition, it can't be used if maxstack > 8 or local variables or exceptions (extra sections) are present. In all these other cases, the Fat header is used:

Offset	Size	Field	Description
0	12 (bits)	Flags	Flags (CorILMethod_FatFormat shall be set in bits 0:1).
12 (bits)	4 (bits)	Size	Size of this header expressed as the count of 4-byte integers occupied (currently 3).
2	2	MaxStack	Maximum number of items on the operand stack.
4	4	CodeSize	Size in bytes of the actual method body.
8	4	LocalVarSigTok	Metadata token for a signature describing the layout of the local variables for the method. 0 means there are no local variables present. This field references a stand-alone signature in the MetaData tables, which references an entry in the #Blob stream.

The available flags are:

Flag	Value	Description
CorILMethod_FatFormat	0x3	Method header is Fat.
CorILMethod_TinyFormat	0x2	Method header is Tiny.
CorILMethod_MoreSects	0x8	More sections follow after this header.
CorILMethod_InitLocals	0x10	Call default constructor on all local variables.

This means that when the CorILMethod_MoreSects is set, extra sections follow the method. To reach the first extra section, we have to add the size of the header to the code size and to the file offset of the method, then align to the next 4-byte boundary.

Extra sections can have a Fat (1 byte flags, 3 bytes size) or a Small header (1 byte flags, 1 byte size); the size includes the header size. The type of the header and the type of the section is specified in the first byte, of course:

Flag	Value	Description
CorILMethod_Sect_EHTable	0x1	Exception handling data.
CorILMethod_Sect_OptILTable	0x2	Reserved, shall be 0.
CorILMethod_Sect_FatFormat	0x40	Data format is of the Fat variety, meaning there is a 3-byte length. If not set, the header is Small with a 1-byte length.
CorILMethod_Sect_MoreSects	0x80	Another data section occurs after this current section.

No other types than the exception handling sections are declared (this doesn't mean you shouldn't check the CorILMethod_Sect_EHTable flag). So if the section is Small, it will be:

Offset	Size	Field	Description
0	1	Kind	Flags as described above.
1	1	DataSize	Size of the data for the block, including the header, say n*12+4.
2	2	Reserved	Padding, always 0.
4	n	Clauses	nsmall exception clauses.

Otherwise:

Offset	Size	Field	Description
0	1	Kind	Which type of exception block is being used
1	3	DataSize	Size of the data for the block, including the header, say n*24+4.
4	n	Clauses	nfat exception clauses.

The number of the clauses is given by the DataSize. I mean, you have to subtract the size of the header and then divide by the size of a Fat/Small exception clause (this, of course, depends on the kind of header). The Small one:

Offset	Size	Field	Description
0	2	Flags	Flags, see below.
2	2	TryOffset	Offset in bytes of try block from the start of the header.
4	1	TryLength	Length in bytes of the try block
5	2	HandlerOffset	Location of the handler for this try block
7	1	HandlerLength	Size of the handler code in bytes
8	4	ClassToken	Meta data token for a type-based exception handler
8	4	FilterOffset	Offset in method body for filter-based exception handler

And the fat one:

Offset	Size	Field	Description
0	4	Flags	Flags, see below.
4	4	TryOffset	Offset in bytes of try block from the start of the header.
8	4	TryLength	Length in bytes of the try block
12	4	HandlerOffset	Location of the handler for this try block
16	4	HandlerLength	Size of the handler code in bytes
20	4	ClassToken	Meta data token for a type-based exception handler
20	4	FilterOffset	Offset in method body for filter-based exception handler

Available flags are:

Flag	Value	Description
COR_ILEXCEPTION_CLAUSE_EXCEPTION	0x0000	A typed exception clause
COR_ILEXCEPTION_CLAUSE_FILTER	0x0001	An exception filter and handler clause
COR_ILEXCEPTION_CLAUSE_FINALLY	0x0002	A finally clause
COR_ILEXCEPTION_CLAUSE_FAULT	0x0004	Fault clause (finally that is called on the exception only)

OK, that's all.

The #Blob Stream

This stream contains different things as you might have already noticed going through the MetaData tables, but the only thing in this stream which is a bit difficult to understand are signatures. Every signature referenced by the MetaData tables is contained in this stream. What does a signature stand for? For instance, it could tell us the declaration of a method (be it a defined method or a referenced one), this meaning the parameters and the return type of that method. The various kinds of signatures are: MethodDefSig, MethodRefSig, FieldSig, PropertySig, LocalVarSig, TypeSpec, and MethodSpec.

When I first wrote this article (11/12/2005) the .NET reference content about signatures was a little bit poor, but now, after the April 2006 release, it has a very rich and full explanation about this subject. So there's no point in explaining the schema of every kind of signatures, you can find those in the reference. I'll explain one type of signature and I think it should be enough to understand the logic behind all of them. Let's take for instance the LocalVarSig signature. If there's a method like:

private void f()
{

    int A = 3;
    bool B = false;

    if (A == 3 && B == false)
    {
        // I had to put the "if" clause,

        // because without it the local variables

        // would have been discarded for being unreferenced   

    }
}

The signature for the local variables in this method would be: 04 07 02 08 02. Keep in mind that every integer in the Blob is encoded but that in this case we won't notice it because the signature is made of values which are all less than 0x80. The first byte stands for the number of bytes of the signature, which in this case are 4 (keep in mind that this length is encoded).. So, the actual signature begins form the second byte and its first member is 0x07, which is the LOCAL_SIG (it stands for the .locals directive). Every LocalVarSig starts with this directive. The second byte (or the third one, depending if you count the signature size) is the number of local variables (or, technically speaking, types) for this method, in our case there are only two types and so the value of this field is 0x02. The bytes who follow are the types themselves. You can find a list of possible kind of types either in the SDK reference or in the CorHdr.h. I will paste the enum from the header, because it seems to me that the brief description next to the values is even easier to understand than the one in the reference.

typedef enum CorElementType
{
    ELEMENT_TYPE_END            = 0x0,

    ELEMENT_TYPE_VOID           = 0x1,
    ELEMENT_TYPE_BOOLEAN        = 0x2,
    ELEMENT_TYPE_CHAR           = 0x3,
    ELEMENT_TYPE_I1             = 0x4,
    ELEMENT_TYPE_U1             = 0x5,

    ELEMENT_TYPE_I2             = 0x6,
    ELEMENT_TYPE_U2             = 0x7,
    ELEMENT_TYPE_I4             = 0x8,
    ELEMENT_TYPE_U4             = 0x9,
    ELEMENT_TYPE_I8             = 0xa,

    ELEMENT_TYPE_U8             = 0xb,
    ELEMENT_TYPE_R4             = 0xc,
    ELEMENT_TYPE_R8             = 0xd,
    ELEMENT_TYPE_STRING         = 0xe,

    // every type above PTR will be simple type


    ELEMENT_TYPE_PTR            = 0xf,      // PTR <type>

    ELEMENT_TYPE_BYREF          = 0x10,     // BYREF <type>


    // Please use ELEMENT_TYPE_VALUETYPE.

    // ELEMENT_TYPE_VALUECLASS is deprecated.

    ELEMENT_TYPE_VALUETYPE      = 0x11,  // VALUETYPE <class Token>

    ELEMENT_TYPE_CLASS          = 0x12,  // CLASS <class Token>

    ELEMENT_TYPE_VAR            = 0x13,  // a class type variable VAR <U1>

    // MDARRAY <type> <rank> <bcount>

    // <bound1> ... <lbcount> <lb1> ...

    ELEMENT_TYPE_ARRAY          = 0x14,
    // GENERICINST <generic type> <argCnt> <arg1> ... <argn>

    ELEMENT_TYPE_GENERICINST    = 0x15,
    // TYPEDREF  (it takes no args) a typed referece to some other type

    ELEMENT_TYPE_TYPEDBYREF     = 0x16,

    // native integer size

    ELEMENT_TYPE_I              = 0x18,

    // native unsigned integer size

    ELEMENT_TYPE_U              = 0x19,
    // FNPTR <complete sig for the function

    // including calling convention>

    ELEMENT_TYPE_FNPTR          = 0x1B,

    // Shortcut for System.Object

    ELEMENT_TYPE_OBJECT         = 0x1C,
    // Shortcut for single dimension zero lower bound array

    // SZARRAY <type>

    ELEMENT_TYPE_SZARRAY        = 0x1D,

    // a method type variable MVAR <U1>

    ELEMENT_TYPE_MVAR           = 0x1e,

    // This is only for binding

    // required C modifier : E_T_CMOD_REQD <mdTypeRef/mdTypeDef>

    ELEMENT_TYPE_CMOD_REQD      = 0x1F,

    ELEMENT_TYPE_CMOD_OPT       = 0x20,
    // optional C modifier : E_T_CMOD_OPT <mdTypeRef/mdTypeDef>


    // This is for signatures generated internally

    // (which will not be persisted in any way).

    ELEMENT_TYPE_INTERNAL       = 0x21,

    // INTERNAL <typehandle>


    // Note that this is the max of base type excluding modifiers

    ELEMENT_TYPE_MAX            = 0x22,
    // first invalid element type



    ELEMENT_TYPE_MODIFIER       = 0x40,

    // sentinel for varargs

    ELEMENT_TYPE_SENTINEL       = 0x01 | ELEMENT_TYPE_MODIFIER,
    ELEMENT_TYPE_PINNED         = 0x05 | ELEMENT_TYPE_MODIFIER,
    // used only internally for R4 HFA types

    ELEMENT_TYPE_R4_HFA         = 0x06 | ELEMENT_TYPE_MODIFIER,
    // used only internally for R8 HFA types


    ELEMENT_TYPE_R8_HFA         = 0x07 | ELEMENT_TYPE_MODIFIER,

} CorElementType;

The two type bytes in the signature are 0x08 and 0x02, which translated are: ELEMENT_TYPE_I4 and ELEMENT_TYPE_BOOLEAN. As you can see, these are exactly the local variables we had in our method: a 32 bit unsigned integer and a boolean. Of course, I haven't told you everything about signatures, but you should have understood the way they work.

Conclusions

I hope this article gave you an easy insight into the .NET format.

You must Sign In to use this message board.

FAQ    Noise Tolerance Very HighHighMediumLowVery Low   Layout Expand Posts & RepliesThread ViewNo JavascriptNo JS + Preview   Per page 102550

Msgs 1 to 25 of 56 (Total in Forum: 56) (Refresh) FirstPrevNext

Local verible. Pilot87 6:45 17 Jan '10   Hi, I am Alex. I am exploring .NET Format. In programm "Hello, World!" (Visual Basic .NET) in each method, which have a FAT format, the LocalVarSigTok field a references row in a table 11 (Constant Table) but this table a not present in this programm. So how do I can find local veribles? Best whishes. Sign In·View Thread·PermaLink #US stream strings length AndreiASM 7:25 31 Dec '09   Hi there! First of all, what can I say except the fact that this is a great article! I would like to share the fact that inside #US stream, the first byte is null, being followed by a 7 bit encoded integer which tells the length in bytes of the next UNICODE string, and then another special byte etc. However, if the length of a string exceeds 127 bytes (which is 01111111 binary), 2 bytes will be used to encode its length; to find the actual length of te string you take this word value and substract 0x8000 from it. To make it simple, if the most significant/sign bit of the length byte is set, then the length is actual a word (2 bytes - the string is more than 127 bytes long). Thanks and once again congrats for this article! Happy new year, cheers. Sign In·View Thread·PermaLink Another question Jerry.Wang 2:46 19 Nov '08   Thanks for your patience. If I modify the IL code in the PE file, I mean I just modify the IL code, I do not change the IL code length, just replace the IL code bytes, need I set the signature for the method ? Sign In·View Thread·PermaLink Re: Another question Daniel Pistelli 2:50 19 Nov '08   No, the signature only identifies the arguments of the method and its return type. It has nothing to do with the code. Sign In·View Thread·PermaLink Re: Another question Jerry.Wang 2:52 19 Nov '08   Thank you one more time Sign In·View Thread·PermaLink What is the BaseAddress for the RVA field in the MethodDef Table?? Jerry.Wang 23:16 18 Nov '08   What is the BaseAddress for the RVA field in the MethodDef Table?? I want to get the IL code in the method body Sign In·View Thread·PermaLink Re: What is the BaseAddress for the RVA field in the MethodDef Table?? Daniel Pistelli 1:15 19 Nov '08   The BaseAddress only applies at execution time, when the assembly is loaded into memory. When considering the file you only have to convert the RVA to an offset (like in every PE) and the skip the method header in order to get to the code. Quite easy. Sign In·View Thread·PermaLink Re: What is the BaseAddress for the RVA field in the MethodDef Table?? Jerry.Wang 2:38 19 Nov '08   I have get the binary data by RVA in byte data. Could you please explain more for me? First, I have a simple function: public void TestAAA() { MessageBox.Show("1"); } this is a TINY method body I get it upon the RVA ------------- [0x0] 0x36 [0x1] 0x00 [0x2] 0x72 [0x3] 0x61 [0x4] 0x00 [0x5] 0x00 [0x6] 0x70 [0x7] 0x28 [0x8] 0x20 [0x9] 0x00 [0xa] 0x00 [0xb] 0x0a [0xc] 0x26 [0xd] 0x2a ------------------- The [0x1] to [0xd] is the IL code, I have compared the IL code with the one I got via C# Reflection. They are the same, so that is correct. But how about the first byte? The structure define: typedef struct IMAGE_COR_ILMETHOD_TINY { BYTE Flags_CodeSize; } IMAGE_COR_ILMETHOD_TINY; The first byte is the CodeSize, the CodeSize is larger than the IL code byte array's length. I want to get the length, which equals to what I can get in System.Reflection.MethodBody.GetILAsByteArray() But why it is 0x36? Sign In·View Thread·PermaLink Re: What is the BaseAddress for the RVA field in the MethodDef Table?? Jerry.Wang 2:43 19 Nov '08   I think I find the answer: /**//***************************************************************************/ /**//* Used when the method is tiny (< 64 bytes), and there are no local vars */ typedef struct tagCOR_ILMETHOD_TINY : IMAGE_COR_ILMETHOD_TINY { bool IsTiny() const { return((Flags_CodeSize & (CorILMethod_FormatMask >> 1)) == CorILMethod_TinyFormat); } unsigned GetCodeSize() const { return(((unsigned) Flags_CodeSize) >> (CorILMethod_FormatShift-1)); } unsigned GetMaxStack() const { return(8); } BYTE* GetCode() const { return(((BYTE*) this) + sizeof(struct tagCOR_ILMETHOD_TINY)); } DWORD GetLocalVarSigTok() const { return(0); } COR_ILMETHOD_SECT* GetSect() const { return(0); } } COR_ILMETHOD_TINY; /**//************************************/ // This strucuture is the 'fat' layout, where no compression is attempted. // Note that this structure can be added on at the end, thus making it extensible typedef struct tagCOR_ILMETHOD_FAT : IMAGE_COR_ILMETHOD_FAT { bool IsFat() const { return((Flags & CorILMethod_FormatMask) == CorILMethod_FatFormat); } unsigned GetMaxStack() const { return(MaxStack); } unsigned GetCodeSize() const { return(CodeSize); } mdToken GetLocalVarSigTok() const { return(LocalVarSigTok); } BYTE* GetCode() const { return(((BYTE*) this) + 4*Size); } const COR_ILMETHOD_SECT* GetSect() const { if (!(Flags & CorILMethod_MoreSects)) return(0); return(((COR_ILMETHOD_SECT*) (GetCode() + GetCodeSize()))->Align()); } } COR_ILMETHOD_FAT; Sign In·View Thread·PermaLink Re: What is the BaseAddress for the RVA field in the MethodDef Table?? Daniel Pistelli 2:45 19 Nov '08   Again, it is all explained in the article in the "Methods" paragraph. Sign In·View Thread·PermaLink CustomAttributes and #Blob Stream datenkabel 3:17 4 Nov '08   Hi Daniel, I still have some Problems on treating CustomAttributes. I've found nearly everything but can't bring it to an end... By using TypeRef and MemberRef table i get this information: MemberRef: TypeRef Index -> Name MyAttribute (from TypeRef Table) Name c'tor Signature 0x0026 -> 04 20 01 01 0E Can you explain the meaning of this bytes? I think four is the length. CustomAttribute: Blob 0x0170 -> 0E 01 00 09 34 2E 31 31 2E 32 30 30 38 00 00 Thanks Heiko Sign In·View Thread·PermaLink Re: CustomAttributes and #Blob Stream datenkabel 23:14 19 Nov '08   Seemed as nobody is helping me. So I did it on my own and solved the problem Sign In·View Thread·PermaLink 1.00/5 (1 vote) [Message Removed] Katekortez 10:29 25 Oct '08   Spam message removed Sign In·View Thread·PermaLink New tables Przemyslaw Celej 7:28 21 Jun '08   Hello, 4th edition (Jun 2006) of ECMA-355 introduces two additional tables: - GenericParamConstraint - 44 - recording the constraints for each generic parameter. - GenericParam - 42 - storing the generic parameters used in generic type definitions and generic method definitions. Cheers Sign In·View Thread·PermaLink Re: New tables Daniel Pistelli 7:48 21 Jun '08   You are right, those tables are supported by the CFF Explorer. I inserted them at the time the new ECMA came out, but somehow I forgot to update the article. I'll update a new version as soon as I can. Ciao Sign In·View Thread·PermaLink Re: New tables Daniel Pistelli 8:51 21 Jun '08   Ok, I updated the article: http://ntcore.com/Files/dotnetformat.htm[^] The version on codeproject should be updated soon. Sign In·View Thread·PermaLink Two questions Przemyslaw Celej 13:41 21 Jun '08   Thanks Daniel for reply , I'm writing my own reflection engine, and I have few questions for you: 1) What is the signature (in the blob heap of course) for storing assembly's public key (referenced by the Assemby.PublicKey column) ? Especially from where we can obtain a size of the public key ? There is no mention about this in ECMA spec. 2) Specification says that above-mentioned public key precedes AssemblyHashAlgorithm, we can choose algorithm to hash assembly from one of the following positions: None 0x0000 Reserved (MD5) 0x8003 SHA1 0x8004 However I've noticed that some assemblies (ok one assembly ) have flag: 0x80A0 (For instance take SQLite data base instance, System.Data.SQLite.dll version: 1.0.47.2 - http://sqlite.phxsoftware.com/[^]) Do you know something about it ? Thanks in advance. Sign In·View Thread·PermaLink Re: Two questions Daniel Pistelli 14:04 21 Jun '08   Przemyslaw Celej wrote: 1) What is the signature (in the blob heap of course) for storing assembly's public key (referenced by the Assemby.PublicKey column) ? Especially from where we can obtain a size of the public key ? There is no mention about this in ECMA spec. Well, this one I can answer. Let's take for instance the public key of system.drawing.design.dll (i took a random dll): Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F Ascii 00001070 80 A0 00 24 00 00 04 80 00 00 94 00 00 00 06 02 € .$..€..”...< 00001080 00 00 00 24 00 00 52 53 41 31 00 04 00 00 01 00 ...$..RSA1.../. 00001090 01 00 07 D1 FA 57 C4 AE D9 F0 A3 2E 84 AA 0F AE /.ÑúWÄ®Ùð£.„ª® 000010A0 FD 0D E9 E8 FD 6A EC 8F 87 FB 03 76 6C 83 4C 99 ý.éèýj쏇û>vlƒL™ 000010B0 92 1E B2 3B E7 9A D9 D5 DC C1 DD 9A D2 36 13 21 ’²;çšÙÕÜÁÝšÒ6! 000010C0 02 90 0B 72 3C F9 80 95 7F C4 E1 77 10 8F C6 07 <r<ù€•äáwæ> 000010D0 77 4F 29 E8 32 0E 92 EA 05 EC E4 E8 21 C0 A5 EF wO)è2’êìäè!À¥ï 000010E0 E8 F1 64 5C 4C 0C 93 C1 AB 99 28 5D 62 2C AA 65 èñd\L“Á«™(]b,ªe 000010F0 2C 1D FA D6 3D 74 5D 6F 2D E5 F1 7E 5E AF 0F C4 ,úÖ=t]o-åñ~^¯Ä 00001100 96 3D 26 1C 8A 12 43 65 18 20 6D C0 93 34 4D 5A –=&ŠCe.mÀ“4MZ 00001110 D2 93 Ò“ The first 2 bytes encode the size. You have to look at how the blob enodes lenghts (it is written in the ecma). Basically it uses a bit system where the high bits of the first byte tell you how big the the lenght value is (1 byte, 2 bytes or 4 bytes). Keep in mind that the value is stored in big endian. So, 0x80 (first byte) tells me in its first 2 bits that the value is a WORD. Thus, removing the signalling bits it becomes: 0x00 0xA0. In little endian 0xA0 0x00 and in fact the size of the the public key is 0xA0. I hope this helps. For the second question I really don't know. I never encountered a 0x80a0 value. Sign In·View Thread·PermaLink Re: Two questions Przemyslaw Celej 15:08 21 Jun '08   Daniel Pistelli wrote: The first 2 bytes encode the size. You have to look at how the blob enodes lenghts (it is written in the ecma). Basically it uses a bit system where the high bits of the first byte tell you how big the the lenght value is (1 byte, 2 bytes or 4 bytes). Keep in mind that the value is stored in big endian. So, 0x80 (first byte) tells me in its first 2 bits that the value is a WORD. Thus, removing the signalling bits it becomes: 0x00 0xA0. In little endian 0xA0 0x00 and in fact the size of the the public key is 0xA0. I hope this helps. Oh yes, now I see, I forgot about compressed integers... Daniel Pistelli wrote: For the second question I really don't know. I never encountered a 0x80a0 value. Sorry, I mistakenly took 0x80A0 value from the begining of the PublicKey heap rather than from HashAlgId Thanks for your effort ! Sign In·View Thread·PermaLink HexEdit PE template Andrew Phillips 3:23 20 May '08   Hi Daniel - great article! I have recently been researching the PE file format and the .NET part in particular in order to update the PE template for HexEdit, which is how I stumbled on your fine article. I should first explain that I have a hex editor (see http://www.hexedit.com) which has a very powerful template facility. Some years ago someone sent me a PE template (as you know that is the format used for Windows EXE/DLL etc files). Unfortunately, it only supported the IMPORT table. I have recently grown tired of waiting for him to update it (sorry Vinny), and took it on myself to add support for the other tables even though I know nothing of the format myself. I noticed in your article that you said you created your CFF Explorer as there wasn't anything else to do the job. This is a shame as if you had discovered HexEdit and simply created a template it would have saved me a lot of trouble I think it would also have saved you the considerable work that you appear to have put into CFF Explorer. By now you are thinking that a HexEdit template could never be as powerful or useful as a custom program. This is true to an extent, but you should not underestimate the power of HexEdit templates. I had a quick play with your CFF Explorer, and it would be easy to create something similar with a template. There are some things that it would be easy to do better, if I do say so myself. For example, I noticed in your TypeDef table (table 3 in the #~ stream) that you pop up a dialog of checkboxes in order to edit the Flags field. HexEdit templates support bit-fields, so you could create a 4-bit bit-field for "scope" with an associated "enum" (private, public, family etc). The user can then easily see the value and even change it using a drop-down list One really nice thing about templates is that you don't need to worry about programming Windows controls at all (trees, multi-column lists, checkboxes etc) In the past I have had to reverse engineer file formats and even write software to manipulate them. This is a tedious process where you painstakingly count bytes etc in a hex editor, write and build a program then try it to see where it fails, then repeat the process many times. Creating templates in HexEdit is orders of magnitude easier and faster as you don't have to worry about building software and you create the template right in the hex editor. I have been researching the PE tables (I recently added support for the EXPORT and RESOURCES tables - this is called PE.XML in ExtraHexEditTemplates.zip downloadbale from http://www.hexedit.com/download.htm[^]). This has taken me many hours/days of research to understand the file format but only a fraction of that time to update the template. For someone who already understands the file format creating the template would be dead easy. Andrew Phillips http://www.hexedit.com andrew @ hexedit.com Sign In·View Thread·PermaLink Re: HexEdit PE template Daniel Pistelli 4:00 20 May '08   Andrew Phillips wrote: I noticed in your article that you said you created your CFF Explorer as there wasn't anything else to do the job. This is a shame as if you had discovered HexEdit and simply created a template it would have saved me a lot of trouble [Smile] I think it would also have saved you the considerable work that you appear to have put into CFF Explorer. A hex editor with templates can't possibily display all sorts of data like for instance an import table. Even if you display it, it's not like opening it with a PE editor. Andrew Phillips wrote: By now you are thinking that a HexEdit template could never be as powerful or useful as a custom program. This is true to an extent, but you should not underestimate the power of HexEdit templates. I had a quick play with your CFF Explorer, and it would be easy to create something similar with a template. I don't see how a Resource Editor or a dependency walker can be written in a template-like style. Besides the CFF Explorer isn't just a tool for analysis but it has many rebuilding features as well (not to mention the scripting language). HexEdit (I have just tried it) shows only up to the section table of an exe, there's still very much work to do, and I also have a bit of doubts how you'll handle the dynamic size of table indexes of the .NET format in a template. Surely it's not a common type of template implementation. There's still very much work for hexed to do in order to fully represent the data of an executable. As for the CFF Explorer, I am currently rewriting it to make it multi-format and extendable. I am also a supporter of expandable programs to support file formats, I just don't believe in the template solution which is too easy for complex file formats (at least in its common implementation) and not readable without using other kind of non-hex representations (like the tables used in the CFF). At last but not least, the CFF Explorer is freeware, whereas Hexed isn't: It costs 40$. Best regards Daniel P.S. By the way, If I apply a template on a file (like the Exe template) I get an error. It shows me the structures, but it doesn't follow them in the hex editor. So that I can't actually reach the data. Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: HexEdit PE template Andrew Phillips 3:22 21 May '08   Thanks for your reply in which you wrote: > At last but not least, the CFF Explorer is freeware, whereas Hexed isn't: It costs 40$. Sorry to correct you but HexEdit 2.5F (not to be confused with any other program called Hexed) is completely free. As for your other comments I respect your opinion but humbly plead that you keep an open mind. As I said above a template "cannot be as powerful as a custom program" but I believe it can come close. One thing you and others might consider is using HexEdit templates to prototype programs like CFF Explorer, before actually writing the software. I had a colleague who spent weeks reverse-engineering a file format and writing code to load it. I looked at his code, and created a template from it in 30 minutes. Moreover, after loading in hundreds of example files using the template, the template error checking ability revealed some situations he had not considered and were not seen in his program. > HexEdit (I have just tried it) shows only up to the section table of an exe,... You must have been using the old template, created several years ago. The new version available as a separate download supports the IMPORT, EXPORT and RESOURCE tables and I will add the other tables later. Last night I added some support for CLI metadata. It now supports all Metadata tables (Modules, TypeRefs, etc). And yes it quite easily handles the dynamically sized tables, thanks. For example, here is a bit of the template tree view I copied to the clipboard. (Another advantage of using HexEdit is the multi-column tree view has built-in support for copying to the clipboard, printing etc - thanks to Chris Maunder's grid control http://www.codeproject.com/KB/miscctrl/gridctrl.aspx.) TypeDef[1] NameSpace1.Class1 Visibility NotPublic Layout Auto Semantics Class Abstract 0 Sealed 0 SpecialName 0 RTSpecialName 0 Import 0 Serializable 0 StrFormat ANSI HasSecurity 0 BeforeFieldInit 1 Forwarder 0 CustomFormat 0 NameIdx 46 Name "Class1" NamespaceIdx 53 Namespace "ConTest2" ExtendsIdx 5 Base Class = TypeRef 0 (System.Object) FirstFieldIdx 1 FirstMethodDefIdx 1 This is just the tree and data columns for one row of the TypeDef table, and doesn't really show the tree structure and how eg you can easily change the Visibility by just selecting another value from the drop down list. Note that the template looks into the #String stream for the class and namespace name. It also looks into the TypeRef table to get the base class name (System.Object). > [HexEdit] shows me the structures, but it doesn't follow them in the hex editor. So that I can't actually reach the data. It does this if you turn "AutoSync" on (ie keep the template and hex views in sync). Or you can simply click the "Sync" button to manually sync. As for your other points about the IMPORT table and not being able to display anything but hex. HexEdit can quite nicely display the IMPORT table. It can also display the data in a huge variety of formats in the Data column of the template view, which you must have missed (eg various integer, floating point, date, string etc completely customizeable formats). Moreover, you can edit the values too - as I explained before you can even associate an enum with an integer (or bit-field) and select from a drop-down list of valid values. Andrew Phillips http://www.hexedit.com andrew @ hexedit.com Sign In·View Thread·PermaLink Re: HexEdit PE template Daniel Pistelli 4:07 21 May '08   Andrew Phillips wrote: Sorry to correct you but HexEdit 2.5F (not to be confused with any other program called Hexed) is completely free. Ok, my mistake. I downloaded the version 3.2 instead of 2.5F. I now downloaded the new version and the extra templates. But I still get lots of errors and in one case nothing got displayed. I actually had to kill hexedit from the task manager because it entered an infinite loop when opening adobe reader. I opened a smaller executable which hexedit managed to open, although it took about 30 seconds to load it. I now see the imported functions etc. I am still not fully convinced by the way it displays the data, although I agree with you that it can be used in order not to write any code and analyze a format. However, it seems to me that there are still some bugs, it can't be that it got stuck 30 seconds to open an exe. If you are using the Grid provided by Maunder you might take into account that it is very memory consuming and that it isn't a good idea to load ALL the data of a file format into the same control. That's perhaps the reason I had to kill hexedit when trying to open adobe reader. Well, good luck in further development, freeware is always appreciated. Best regards Daniel Sign In·View Thread·PermaLink Re: HexEdit PE template Andrew Phillips 2:33 23 May '08   Thanks for trying it. I have not encountered any problems but I have yet to try the template on a large EXE file. Also re the speed - It is quite possible to create templates that have infinite loops and infinite recursion. However, in this case I think the template is just very slow. You are probably displaying it with "allow editing" on (ie, design mode) which also make it a lot slower. Generally, with design mode off and a small EXE it only takes a few seconds to process. You are also right that using Chris Maunder's grid control is part of the speed problem. Actually the grid can be very fast for large grids when using "virtual" mode. Unfortunately, I am using the "tree column" extensions which are very handy but they preclude using "virtual mode". However, I am looking at ways to speed this up, eg by not filling in branches of the tree until they are opened. I am looking to one day rewrite HexEdit in C# (using the same template format of course). One of the priorities will be to greatly speed up template processing. I still haven't found a decent multi-column tree control though. And, yes there are probably still bugs in this template. It may take me a few more days to sort them out. Thanks again, for your article and your comments. Andrew Phillips http://www.hexedit.com andrew @ hexedit.com Sign In·View Thread·PermaLink Re: HexEdit PE template Andrew Phillips 15:13 29 May '08   Hi Daniel, I have been busy on other things and just got around to testing the problems you reported. I am a bit confused - I ran HexEdit 2.5F with the latest template available for download and tried it on various .EXE files. The largest files I could find were Skype.exe (25Mb) and DotNetFX3.exe (50Mb). Both loaded and displayed the template in a few seconds. They both displayed the message "Data past expected end of file" but I verified that they do contain data past the last section of the file. I also tried several other files including .NET ones and had no problems. I tried them with the latest template for download and they never take more than 15 seconds to open. I also tried with my latest template (not available yet) and they take a little longer (as the template is doing a lot more) but still less than 30 seconds. I could not reproduce any of the problems you reported. Are you sure you are using the latest template files? Andrew Phillips http://www.hexedit.com andrew @ hexedit.com Sign In·View Thread·PermaLink

Last Visit: 17:12 9 Feb '10     Last Update: 17:12 9 Feb '10 123 Next »