MS.Net CLR 扩展PE结构分析2

Flier Lu <flier_lu@sina.com.cn>
  
注意：本系列文章在水木清华BBS(smth.org)之.Net版首发，
     转载请保留以上信息，发表请与作者联系
  
Metadata 篇
  
第一章 Metadata 概述
  
1.1 什么是 Metadata
  
    Metadata翻译成中文是“元数据”，可以理解为Type of Type，
说白了就是描述类型的类型数据。从最初级的语言层面支持的RTTI
（“近代”的编程语言基本上都提供了足够的支持，如C++,Delphi等，
部分较“落伍”的语言也通过不同形式如扩展库提供了模拟支持，
“现代”的编程语言则提供了强力的支持，如Java和C#<本质是CLR>)，
到后来二进制级的COM的IDL和类型库（类型库是IDL编译后的二进制形式），
到现在的Metadata，其实是遵循着相同的设计思路。只是出于不同的需求
设计、实现，有这各自的优点缺点罢了。但随着语言的发展，更多的需求集中在
灵活性方面，因而语言发展的趋势是元数据的使用越来越多、支持越来越强。
    举个最简单的例子，在IDE中，动态显示当前对象的方法、属性名列表的功能
(MS叫IntelliSense，Borland叫CodeInsight)，就得宜于类型信息
以前在VC里实现，比较麻烦，得生成专门的符号库；在VB里强一点，可以通过
COM的IDispatch,ITypeInfo,ITypeLib等接口动态获取，但编程麻烦要死；
到CLR，库一级直接提供支持，可以通过System.Reflection完全控制
甚至比COM类型库更高一级地支持动态创建。
   对用户来说，可以完全了解当前程序接口，有哪些Module,哪些Class,
哪些Method等等，这给开发者提供了巨大的创造空间。如DUnit(DotNet下
的XUnit单元测试平台)就大量使用Reflection机制，我们等会谈使用时再说。
  
1.2 Metadata在CLR中的作用
  
    对于CLR架构来说，Metadata可以算是核心操作对象，几乎绝大多数功能
都需要参考其数据。从静态的IL代码构成（二进制编码中直接使用Metadata里的Token）
到动态JIT编译器（使用Metadata定位IL代码及其关系）；从简单的代码载入执行
（Class Loader通过Metadata定位代码入口、编译执行）到复杂的不同语言互操作
（如VB.Net继承C#的类，实际上是直接继承CLR中Metadata中的类）；等等……
几乎所有地方都能看到Metadata的身影。
  
    因为本文的主要目的是介绍底层结构，这里就不再罗嗦Metadata的好处了，
反正以后文章中大家会次次看到他，各种优点自己慢慢体会吧 :)
  
1.3 如何访问和使用 Metadata
  
   做了一通广告，大家一定很关心如何使用Metadata，听我慢慢道来
   在CLR里使用Metadata，可以在三个层面进行操作。
   最简单的方法是直接通过类库提供的System.Reflection命名空间中的
若干类进行访问，例如
  
using System.Reflection;
using System;
  
public class Simple
{
    public static void Main ()
    {
         Module mod = Assembly.GetExecutingAssembly().GetModules () [0];
         Console.WriteLine ("Module Name is " + mod.Name);
         Console.WriteLine ("Module FullyQualifiedName is " +
mod.FullyQualifiedName);
         Console.WriteLine ("Module ScopeName is " + mod.ScopeName);
    }
}
  
   这种访问方式使用起来最简单，功能也足够强大，能够完成我们绝大多数的需要，
特别是在System.Reflection.Emit命名空间中，更提供了动态生成、修改的支持
功能强大得我都想不出能有什么改进了 :) （写.Net病毒就靠他了，hoho）
   不过这种方式必须有CLR环境的支持，受到库功能的限制（后面我们会看到很多
在Reflection一级里不提供的信息:），因此MS为工具软件开发商提供了另一套
较底层的开发库，Metadata Unmanaged API。这套库通过一系列COM接口，
提供了直接访问Metadata的强大支持，System.Reflection应该就是使用它实现的。
有兴趣的朋友可以参看FrameworkSDK\Tool Developers Guide\docs
目录下的Metadata Unmanaged API.doc文档，里面有详细的说明。
如同其名字所示，它必须用Unmanaged代码来使用，如传统的VC,Delphi等。
   可以说99%的工作，都可以通过上面两套库来完成，不过总有些象我这样的人，
喜欢对技术追根究底，想把隐藏在美好面纱下的底层架构纠出来暴露一把，呵呵
因此有了第三个层面，二进制层面的逆向工程分析。
   好在MS为了让其CLI(CLR的子集)标准化，公开了大量文档，总算没要我用上
SoftIce之类的牛刀，Partition II Metadata.doc文档中对Metadata的
二进制格式实现给出了比较详尽的说明，加上GNOME的mono项目已经做了很多工作
因而对Metadata的二进制层面分析不是那么困难。
   接下去的文章中，我会逐渐将Metadata在PE中的组织结构逐渐剥离开来，
让大家能够了解这个神秘的CLR核心到底是什么，里面隐藏了些什么，我们能够通过
他做什么，为什么要这样设计，等等……
  
1.4 Metadata在PE中的组织结构
  
   说了一通废话后，回到正体上来，谈谈Metadata在PE中的组织结构。
  
注意：这一章里面我只把Metadata结构的大概情况介绍一下，下一章会专门
针对二进制模式分析进行详细讲解。如果你只想了解底层结构，可以跳过
下一章。以后的文章也会遵循这种方式组织，讲一些结构、原理，跟着讲
一些实际数据分析方法。
  
   上次我们提到CLR的头信息里面专门有一个字段指向Metadata数据块，
实际上这个数据块只是Metadata的一个头结构，保存有Metadata的信息，
而Metadata的实际数据，是通过若干不同的Heap或者说Stream保存的。
这里我统一使用Stream“流“作为他的名字，但很多文档中以Heap”堆“作为
其称呼，我们可以理解他是一个二进制流，其中数据以堆的结构进行组织。
   Metadata里最常见的有五种流，#String, #Blob, #Guid,
#US(User String)和#~流("#"是流名字的前缀)
   String流就是一个字符串堆，Metadata内部用到的所有字符串如类或方法
的名字等等都以UTF8编码保存在此堆内。而用户的字符串如字符串常量，
则以Unicode编码保存在US(User String)堆内。值得注意的是，
US流和String流在二进制结构组织上不同，我们后面将分析时会详细提及。
Guid流是保存程序中使用到的Guid的数组，如Assembly中Module的MVID。
Blob流是一个通用存储空间，除了Guid和字符串以外基本上所有
乱七八糟的东西都放在里面，呵呵，如PublicKey，常量的值等等。
   最重要的是#~流，这是Metadata实际信息存放的地方。#~流结构上以
若干张表(Table)的形式组织，每张表存储某一方面的Metadata信息，
如MethodDef表存储所有方法的信息。每张表又由若干的行(Row)组成
每行有n个列(Column)，每列代表一种信息，如MethodDef表中每一行
都有一个方法的RVA,类型标志,名字,Signature等等信息。在其中通过
各种索引来相互关联，整个组织结构和关系数据库很相似。
   比较特殊的是，这里所有的表通过一个64bit的有效位图来表示其存在与否
每种类型的表有一个编号，如MethodDef表的编号是6，则第(1<<(6-1))位置1
因而每个表的每一行，可以使用一个唯一的Token表示。此Token是一个32bit
无符号整型数，最高一个字节表示表的编号，低三个字节表示表中的索引号。
如0x06000003表示0x06表（MethodDef）中第3行（如MyApp::Add）
这个Token概念在CLR中频繁使用，如IL代码调用函数、使用变量都是使用Token。
   与之类似的还有Coded Index，下次讲二进制实现时再说。