争怎路由网/网站教程/内容

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

网站教程2024-07-06 阅读
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,下次讲二进制实现

……

相关阅读