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收集整理，欢迎访问。
