Ms.net CLR Extended PE structure analysis (turn, very good article)

Flier Lu <flier_lu@sina.com.cn>

Note: This series of articles in the Water Wood Tsinghua BBS (smth.org) of the. NET version of the start,
Reprint please keep the above information, please contact the author

Overview

This series of articles will extend the PE image structure from the system-level perspective through the analysis of the ms.net CLR architecture
，
Parse the underlying part of the ms.net CLR architecture to help readers understand some important concepts in the CLR from a deeper level
This article readers should have the basic WIN32 programming experience, understand. NET, and the PE image of Win32
The structure has certain understanding, the concrete structure see Matt Pietrek in 1994.3 published in MSJ Classic article
"Peering Inside the pe:a Tour of the Win32 portable
File Format, I skip all the parts I repeat.
This series of articles will be divided into a few parts, first of all the most important metadata, followed by the IL code structure,
And then...... I have not thought well, hehe. In addition, the introduction of the CLR core concepts, ideas, and technologies will be interspersed as needed
。
As for the issues of relationship and interaction between several core parts of the CLR, I eagerly look forward to Tbsoft's masterpiece,
I will not rob his topic here, hehe.

Objective

For an excellent WIN32 programmer, the knowledge of the PE structure is the only way to understand the WIN32 architecture,
And since Chicago (Win95 's development code, WIN95 formally released the previous document to the Win95),
PE structure is relatively stable, until the emergence of ms.net, only some modest changes have taken place.
The reason for this is that the CLR is basically not changing the PE structure, just using the existing PE
The excellent scalability of the structure, extending the information it needs to the PE image. Specifically, the use of the PE knot
Frame
In the Image_optional_header. Datadirectory[image_directory_entry_com_descriptor]
To save the image_cor20_header structure that serves the CLR. In addition, the PE structure is unchanged.
Image_directory_entry_com_descriptor This section, originally designed for COM, but somehow
has not been used and is now used for saving. NET information is the highest level of information structure.
Our analysis will also focus on the structure and analysis of relevant information.
The definition of Image_cor20_header structure can be defined in Frameworksdk\include\corhdr.h
File found in the following:

The CLR 2.0 header structure.
typedef struct IMAGE_COR20_HEADER
{
Header Versioning
ULONG CB;
USHORT majorruntimeversion;
USHORT minorruntimeversion;

Symbol table and startup information
Image_data_directory MetaData;
ULONG Flags;
ULONG Entrypointtoken;

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)
Image_data_directory Managednativeheader;

} Image_cor20_header;

and detailed instructions, you can be in the Frameworksdk\tool developers Guide\Docs
Directory found. Because to turn the CLR into a standard, Ms uncharacteristically, exposing a large number of valuable documents,
Avoid me wasting time to reverse process, hehe
Although this structure has more fields, the core is actually metadata, and other information is centered around
Metadata Service. The relationship between, and so will slowly come.
CB is the structure size, majorruntimeversion.minorruntimeversion is the version number
Refers to the minimum CLR version number required to execute this program, which is currently set to 1.1. And now published. Net
The CLR version of the framework is typically 2.0.
Flags are runtime image description flags that describe the execution properties of this image. such as setting a bit
COMIMAGE_FLAGS_32BITREQUIRED=0X02, this image can only be performed on a 32-bit system
Invalid for future 64-bit CLR (ms.net a great feature is a smooth transition to 64-bit later)
Platform to prepare, think about the previous 16-bit platform to the 32-bit platform transition chaos, and now than before the
N times the amount of code on terror, MS is really a rainy day ah, hehe. If you set
COMIMAGE_FLAGS_STRONGNAMESIGNED=0X04, this image has strong name
Signature (This dongdong does not know how to translate good). This strong name signature
Plays a very important role in the CLR architecture. Why do you say that? Because this strong name
Signature plays the role of assembly's ID card, which relates to the realization of a large pile of concepts in the CLR,
In the future, I will devote a chapter to introduce him, and put down here for the time being.
Entrypointtoken is the entry point to the IL program, similar to the previous
Image_optional_header. Addressofentrypoint's role, just before the
Addressofentrypoint is an RVA that directly points to the address of the program entry Code,
(Don't tell me you don't know what RVA is, hehe, go and see peering Inside the PE)
And now Entrypointtoken point to a token. Note that is token, because the IL code is
JIT-compiled, existing in the image is the Il form of p-code (pseudo code), when needed
is dynamically read by the CLR, compiled in memory and expanded into native code (Native), and then executed.
So the program entrance here is just a MethodDef or file table entry, a token.
The MethodDef here is a metadata table that defines one method per row, while the file table is
Each row has a table with a file definition, and each row contains information for an external file. In other words, when executing a program
You can directly compile the IL code that executes one of the methods in this image, or it may be redirected to another file,
This is assembly as a logical unit of code, a big difference from the traditional DLL.
The concept of assembly is also very important, I do not want to say this here, after a special chapter to come out to speak well.
Several of the remaining fields are image_data_directory types, and this type is a block of data
Define structure, defined in Winnt.h
typedef struct _IMAGE_DATA_DIRECTORY {
DWORD virtualaddress;
DWORD Size;
} image_data_directory, *pimage_data_directory;
Oh, you know what RVA means? rva = relative Virtual address
Resources defines the CLI resource; strongnamesignature definition just mentioned
Strong name Signature In addition to Codemanagertable,
The Exportaddresstablejumps,mangednativeheader are useless.
VtableFixups for a while and then explain it in detail later.
As a result, there is only one metadata field is not introduced, but this is the most important stuff,
This is not a word can be introduced, because the following will be a dedicated whole article--metadata,
With the length of the N chapter to detailed analysis, hehe

BTW: Because I was not engaged in Win32 the bottom of the development, I do not know how to write this article,
I hope that readers will make a lot of comments, there is no explanation or wrong place in spite of the proposed.

Analysis. NET's CLR PE image is not really a difficult thing to have ready-made
Code (mono) ready-made documents (Tool developers Guide) can be seen,
Just the code is ugly (not accustomed to UNIX code style), the document is relatively long
(altogether 20 several m,poor) just. I couldn't resist the curiosity to analyze it,
Hope to be able to analyze some of their own harvest and experience to write out, save the time of other friends.

Hope to have enough time, energy and patience to complete this series of articles ...