MS.Net CLR 擴展PE結構分析(轉，很不錯的文章)
2024-07-10 13:02:13
供稿：網友
flier lu <[email protected]>
注意：本系列文章在水木清華bbs(smth.org)之.net版首發，
轉載請保留以上信息，發表請與作者聯系
概述
本系列文章，將從系統層角度，通過對ms.net clr架構對pe映像結構的擴展的分析
，
解析ms.net clr架構的底層部分運行機制，幫助讀者從更深層次理解clr中某些重要概念
本文讀者應具備基本的win32編程經驗，了解.net中常見概念意義，并對win32之pe映像
結構有一定了解，具體結構請參看matt pietrek于1994.3發表在msj的經典文章
《peering inside the pe: a tour of the win32 portable executable
file format》，與之重復的部分我一概跳過。
本系列文章，將分為幾個大部分，首先是最重要的metadata，其次是il代碼結構，
然后……我還沒想好，呵呵。此外會根據需要穿插一下clr核心概念、思想、技術的介紹
。
至于clr幾個核心部件之間的關系與交互等問題，我熱切期待tbsoft的大作，
我這里就不去搶他的話題了，呵呵。
前言
對一個優秀win32程序員來說，對pe結構的了解是對win32架構了解的必經之路，
而從chicago（win95的開發代號，win95正式發布以前的文檔對win95的稱呼）以來，
pe結構就相對穩定，直到ms.net的出現，才發生了一些不大不小的變化。
之所以說是不大不小，是因為clr基本上沒有對pe結構進行改變，只是利用現有pe
結構的優良可擴展性，將其所需的信息擴展到pe映像中。具體一點說，就是利用了pe結
構
中的image_optional_header.datadirectory[image_directory_entry_com_descriptor]
來保存服務于clr的image_cor20_header結構。此外的pe結構一律不變。
image_directory_entry_com_descriptor此節，原本是設計用于com，但不知為何
一直沒有被使用，現在用于保存.net信息的最高級信息結構。
我們的分析也將集中在此結構以及相關信息的分析上。
image_cor20_header結構的定義，可以在frameworksdk/include/corhdr.h
文件中找到，如下：
// 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;
而詳細的說明，則可以在frameworksdk/tool developers guide/docs
目錄中找到。因為要將clr變為標準，ms這次一反常態，公開大量有價值的文檔，
避免我等浪費時間去逆向過程，呵呵
此結構雖然字段較多，但實際上其核心在于metadata，其他信息都是圍繞著
metadata服務。之間的關系，等會再慢慢道來。
cb是結構大小，majorruntimeversion.minorruntimeversion是版本號
指執行此程序所需的最低clr版本號，目前一般設置為1.1。而現在發布的.net
framework的clr版本一般為2.0。
flags是runtime image描述標志，描述此映像的執行屬性。如設置位
comimage_flags_32bitrequired=0x02，則此映像只能在32位系統上執行
對以后的64位clr無效（ms.net很大的一個功能就是為以后平滑過渡到64位
平臺做準備，想想以前16位平臺到32位平臺過渡時的混亂，以及現在比以前翻了
n倍的代碼量就恐怖，ms真是未雨綢繆啊，呵呵）。如果設置
comimage_flags_strongnamesigned=0x04，則此映像有strong name
signature（這個東東不知道怎么翻譯好）。這個strong name signature
在clr架構里起到了非常重要的作用。為什么這么說呢？因為這個strong name
signature起到assembly的身份證的作用，它關系到clr中一大堆概念的實現，
以后我會專門用一章篇幅來介紹他，這里暫且放下。
entrypointtoken則是指向il程序的入口，類似于以前的
image_optional_header.addressofentrypoint的作用，只是以前的
addressofentrypoint是一個rva直接指向程序入口代碼所在地址，
（不要告訴我你不知道rva是什么啊，呵呵，趕快去看peering inside the pe）
而現在entrypointtoken指向一個token。注意，是token，因為il代碼是
jit編譯的，存在于映像中的都是il形式的p-code(pseudo code)，在需要時
才由clr動態讀取，在內存中編譯展開為本機代碼(native code)，進而執行。
因此這里的程序入口執行的只是一個methoddef或file表的入口，一個token而已。
這里的methoddef是一個metadata表，每行定義一個方法；而file表則是
每行有一個file定義的表，每行包含一個外部文件的信息。也就是說，在執行程序時
可以直接編譯執行此映像中的一個方法的il代碼，也可能是重定向到另一個文件，
這就是assembly作為一個邏輯代碼單元，與傳統dll之類相比一個很大的不同。
assembly的概念也非常重要，我不想這里一下說完，以后專門拿一章出來講好了。
剩下幾個字段都是image_data_directory類型，這個類型是一個數據塊
定義結構，在winnt.h中有定義
typedef struct _image_data_directory {
dword virtualaddress;
dword size;
} image_data_directory, *pimage_data_directory;
呵呵，知道rva的意思了吧 rva = relative virtual address
resources定義cli資源；strongnamesignature定義剛剛提到的
strong name signature；此外codemanagertable，
exportaddresstablejumps，mangednativeheader都沒用到。
vtablefixups暫且略過，以后用上時再詳細解釋。
這樣一來，就剩下一個metadata字段沒有介紹了，不過這個重中之重的東東，
這次只言片語是無法介紹了，因為下面會有專門的一整篇——metadata篇，
用n章的篇幅來詳細剖析，呵呵
btw:因為自己以前不是搞win32底層開發的，實在不知這種文章怎么寫，
希望讀者多多提意見，有沒有解釋清楚或者錯誤的地方盡管提出來。
分析.net的clr pe映像其實并不是什么困難的事情，有現成的
代碼(mono)現成的文檔(tool developers guide)可以看，
只是代碼比較難看（不習慣unix代碼風格），文檔比較長
（一共20幾m,poor）而已。我是實在耐不住好奇心才動手分析的，
希望能夠把自己分析的一些收獲和體會寫出來，節省其他朋友的時間。
希望能夠有充足的時間、精力和耐心完成這個系列文章…… 本文來源于網頁設計愛好者web開發社區http://www.html.org.cn收集整理，歡迎訪問。
