PE文件解析-异常处理表与数字签名

一、异常处理表

1.位置及概述

    PE文件头可选映像头中数据目录表的第4成员IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_DIRECTORY_ENTRY_EXCEPTION]指向异常处理表，它保存在PE文件中，通常在".pdata"区段。

    x86系统采用动态的方式构建SEH结构，相比而言x64系统下采用静态的方式处理SEH结构。

2.异常处理表结构

    数据目录表的第四个元素指向异常表，RVA指向的是一个IMAGE_IA64_RUNTIME_FUNCTION_ENTRY的结构体，其结构如下：

typedef struct _IMAGE_IA64_RUNTIME_FUNCTION_ENTRY {DWORD BeginAddress;      //与SEH相关代码的起始偏移地址DWORD EndAddress;        //与SEH相关代码的末尾偏移地址DWORD UnwindInfoAddress; //指向描述上面两个字段之间代码异常信息的UNWIND_INFO
} IMAGE_IA64_RUNTIME_FUNCTION_ENTRY, *PIMAGE_IA64_RUNTIME_FUNCTION_ENTRY;

    BeginAddress与EndAddress之间，是异常处理函数的内容。UnwindInfoAddress指向的位置是用来描述BeginAddress与EndAddress之间的代码异常属性信息的UNWIND_INFO。UNWIND_INFO也叫作异常展开信息，此结构用来描述堆栈指针的记录属性与寄存器中保存的地址属性，它的结构体如下：

struct _UNWIND_INFO {UBYTE Version:3;        UBYTE Flags:5; UBYTE SizeOfProlog;        UBYTE CountOfCodes;   UBYTE FrameRegister:4;UBYTE FrameOffset:4;UNWIND_CODE UnwindCode[1];union {// If (Flags & UNW_FLAG_EHANDLER)OPTIONAL ULONG ExceptionHandler;//异常/终止函数的映像相对地址指针// Else if (Flags & UNW_FLAG_CHAININFO)OPTIONAL ULONG FunctionEntry;//展开信息链的映像相对地址指针};// If (Flags & UNW_FLAG_EHANDLER)ULONG ExceptionData[1];//异常处理程序的数据
} UNWIND_INFO, *PUNWIND_INFO;

Version:异常展开信息的版本号，一般为0x001
Flags:共有四种标志：
    1.当它为0x0的时候表示UNW_FLAG_NHANDLER，没有异常处理函数。
    2.当它为0x1的时候表示UNW_FLAG_EHANDLER，有异常处理函数。
    3.当它为0x2的时候表示UNW_FLAG_UHANDLER，有系统默认的处理函数。
    4.当它为0x4的时候表示UNW_FLAG_CHAININFO，表示FunctionEntry指向的是前一个RUNTIME_FUNCTION的RAV。
SizeOfProlog:函数起始部分字节的长度
CountOfCodes:UNWIND_INFO结构包含的UNWIND_CODE结构数
FrameRegister:寄存器帧指针，为0则指定函数不使用框架
FrameOffset:若上面字段不为0，表示函数偏移
UnwindCode:指定永久性寄存器与RSP的数组项目数
ExceptionHandler:异常句柄
FunctionEntry:展开信息链（函数）的映像相对地址指针（如果设置了UNW_FLAG_CHAININFO标识）
ExceptionData:异常处理程序的数据

异常处理相关内容参考自：https://blog.csdn.net/tutucoo/article/details/83828700

二、数字签名

1.位置描述

    数字签名有时又叫做安全表，用于存储Authenticode格式的数字签名。如果一个PE文件有数字签名，数据目录表的第5成员IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY]就指向数字签名，判断方法是该数据目录的VirtualAddress成员不为0。该VirtualAddress不同于其他数据，在这里代表了文件偏移地址，而不是RVA地址。通常该结构存储在文件末尾。

    Authenticode®是一种数字签名格式，它是用来验证二进制软件的来源和完整性。Authenticode是基于公开密匙加密标准(PKCS) #7 来签名数据，并使用X.509证书来绑定经过数字签发的二进制程序与其软件发布者的身份的联系。这份文档包含Authenticode签名的结构和技术细节。

    这份文档不讨论如何签发/处理X.509证书，如何使用Windows SDK工具来签署二进制程序，如何部署代码签名基础设施，或者相关的Windows® API函数。这方面的相关信息可以查看在本文档最后的“资源”章节。

本资料应用于下列操作系统：
      Windows Server® 2008
      Windows Vista®
      Windows Server 2003
      Windows® XP
      Windows 2000

这里引用和讨论的相关资源列于这份文档的结尾。

在PE文件中的可信代码数字签名是PKCS #7 签名块结构。该签名可以保证：

·         这份软件源于某个确定的软件发布者。

·         这份软件自从签署以来没有经过修改。

一份PKCS #7 签名块结构包含该PE文件的哈希值、通过软件发布者私匙创建的签名以及将软件发布者的签名密匙绑定到一个合法实体的X.509 v3证书。一份PKCS #7签名块可以包含以下可选信息：

·         关于软件发布者的描述

·         软件发布者的链接

·         可信代码签名的时间戳

签名时间戳由时间戳权威机构(TSA)生成，并且保证软件发布者所做的签名在这个时间戳之前已经存在。这个时间戳可以延长了这个签名的生命期，即便相关的签名证书已经过期或者后来被废除。

可信代码签名可以被嵌入到Windows的PE文件中，位于PE文件的Optional Header Data Directories结构中Certificate Table所指向的位置。当可信代码签名被用于签署一个Windows PE文件时，计算文件数字签名哈希值的算法略过PE文件结构中的特定字段。当把数字签名嵌入文件时，签名过程可以修改这些字段，而不致于影响文件的哈希值。

图1显示了一幅简单的PE文件全局图，它描述了数字签名是如何包含在PE文件中的。它包含了嵌入的可信代码数字签名和指出那些被略过计算PE文件哈希值的PE结构字段。

关于PE文件结构的细节，请参阅“Microsoft Portable Executable and Common Object File Format Specification”(PE/COFF specification)。

关于可信代码数字签名中PKCS #7部分的细节，请参阅本文档后面的Abstract Syntax Notation version 1 (ASN.1) 结构定义。

关于可信代码数字签名如何计算PE文件哈希值的细节，参阅本文档后面的“Calculating the PE Image Hash”。

2.数字签名结构

    数据目录表的第5成员指向数字签名，该成员的VirtualAddress是数字签名的物理偏移地址，Size是签名文件的长度。该地址指向的是一个WIN_CERTIFICATE结构体。f

typedef struct _WIN_CERTIFICATE {DWORD       dwLength;WORD        wRevision;WORD        wCertificateType;   // WIN_CERT_TYPE_xxxBYTE        bCertificate[ANYSIZE_ARRAY];
} WIN_CERTIFICATE, *LPWIN_CERTIFICATE;

dwLength:此结构体的长度。
wRevision:在bCertificate里面保护的证书的版本号，版本号有两种，如下表，一般为0x0200。

wCertificateType:证书类型，有如下表格中的类型：

bCertificate:包含一个或多个证书，一般来说这个证书的内容一直到安全表的末尾。