Structure of PE files in. Net

Development Learning. NetMediumStructure of PE files. After we create source code files using any language that supports CLR, the compiled files are managed modules ), this managed module can run on CLR. Therefore, we call this type of File a Managed Executable File ). The format of the general PE file has been recorded in note 3. Here, only some of the distinctive parts of the hosted file are recorded.

　　An important part of Managed execution files

　　1. CLR Header

 

We know that the PE Header contains a Data Directory Table. The first item of this Table is the RVA and size containing the CLR header, you can use it to find the CLR Header. Record several main fields in the CLR Header:

(1) Flags

 

 

This is a binary flag. The optional values include:

A. the COMIMAGE_FLAGS_ILONLY (0x00000001) file only contains pure IL Code and is not embedded with any Native Code (except Dos Stub, this stub will be ignored by all systems that can recognize CLR ).

B. The COMIMAGE_FLAGS_32BITREQUIRED (0x00000002) file can only be loaded into a 32-bit process space.

C. The COMIMAGE_FLAGS_STRONGNAMESIGNED (0x00000008) file is protected by a strong name signature.

 

 

(2) EntryPointToken

This is a MeteData Identifier that specifies the entry point of this PE file. It points to a method definition or file reference, and the only thing that points to file reference is: if the entry point of a multi-module assembly is not in the main module, the entry point in the main module points to the module file containing the entry point. The entry point can only appear in the executable file. If your code does not contain the entry point, the IL compiler will refuse to compile the EXE file for you. However, non-executable files are divided into two types: if the program is a pure managed program, there is no entry point; if the program contains the IL code and the machine code (generated by the MC ++ compiler and the linker), you must use DLLMain () as the entry point function, it needs to perform some necessary initialization operations on the unmanaged code in the Assembly.

(3) VTableFixups

 

 

To understand this field, you must first understand the concept of v-table. This is a description I picked from a foreigner. It should be very accurate. "Certain ages, 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 ". V-table is used to call services for virtual methods, while VTableFixups contains the addresses and sizes of a group of v-tables.

According to my current understanding, v-table is useful only when the hosted file needs to interact with the non-hosted environment (for example, this managed code is called by an unmanaged environment ), it may be useless in a pure hosting environment. Of course, we all know that C #, as a typical OO language, also has the concept of virtual functions, but its implementation mechanism of virtual functions is different from that of v-table in C ++. I am not sure yet.

 

　　2. Text section)

The entire CLR Header is placed in a text segment. This is a read-only segment that contains metadata tables, IL code, and introduction tables. The entire structure is shown in:

 

 

 

 

 

The parts in this section are not generated at the same time. The box with the serial number is used to prompt this point.

 

 

　　3. Resources

Two different types of resources can be embedded in a hosted file: resources related to an unmanaged platform, or managed resources. These two types of resources are stored in different sections of the PE file (the hosted resources have already appeared in the text segment above, aren't they ?), The unmanaged resources are placed in a separate. rsrc segment, while the managed resources are placed in the text segment.

Note that the IL assembler can only embed one resource file (. RES) in each hosted executable file ). The IL anti-assembler locates the section and releases all the content in the section as a. RES file.

　　3. Metadata structure

 

 

Used. net's Reflection feature has a concept of metadata, which is a complete description of the logic structure of the entire managed module, including all the elements declared and referenced in the module. In terms of structure, all metadata is similar to a relational database. The data in it is embodied in a group of cross-referenced tables (rather than a tree or other data structures ), and there is only one copy of any data (other locations that use this data will contain a reference pointing to this data ). In terms of usage, these tables are divided into three types: definition table, reference table, and manifest table ).

The entire metadata is a binary data block. You can use the tool to compile the metadata information of the generated collection, such as ildasm.exe (you can find the command for displaying metadata information in the "View" menu ).

　　(1) Metadata structure Overview

 

I used ildasm.exe to collect the metadata information of a very small Demo program I wrote. I put it here for reference with the following content: