写在前面

1. 本文首发于 Debugwar.com， 授权转载到看雪论坛，其他转载请注明出处。
2. 看雪的这个MarkDown的系统与我的写作系统有点冲突，排班可能会有问题，可以点上面的连接去看原文获得更好地排版体验。
3. Linux的输入法你懂的，可能会有错字别字，大家多包涵~

本文是 《一文读懂对称加密、非对称加密、哈希值、签名、证书、https之间的关系》 的姊妹篇（下文简称“姊妹篇”），在阅读本文之前，最好先阅读一下上一篇文章。

本文对日常工作中应用最广泛，也是大家最容易接触到的PE文件（也就是大家常说的exe/dll/sys文件）的签名进行了深入讲解，并一步一步讲解如何手工验证一个PE文件签名的有效性。

背景

近期工作中，有个自研驱动需要防止未授权R3程序调用，因此需要设计一个方案出来。笔者第一想到的是利用Windows的签名机制，固化签名的CommonName和受信任的父证书公钥到驱动程序中，然后分别校验驱动、调用发起者线程所在模块、调用发起者二进制程序的签名，来防止非法调用。

查了很多签名相关的资料发现都是R3下WinTrust API函数实现的，然而问题是R0下并没有这些API可以使用，看来要自己写代码实现一遍签名校验的逻辑了。

后来又经过一段时间探索， 发现现成的代码都是重度和某个平台或库绑定——例如Linux下的签名验证代码和linux的数据结构绑定、再比如其他几个开源的代码和openssl库绑定，而openssl库在R0下也是无法调用的，因为依赖了很多R0下没有的函数（例如_open等POSIX C函数）。

看来只能自己动手了，所以继续转向研究签名校验的底层原理。然而网上大部分关于签名的资料，全部都偏重于理论介绍，至少笔者没有搜到只使用哈希和RSA算法实操验证签名的例子——那没办法了，只好完全自己从头来验证一遍了……

几个概念

ASN.1

ASN.1本身只定义了表示信息的抽象句法，但是没有限定其编码的方法。 摘自维基百科

DER编码

由于ASN.1并没有规定编码方式，因此在实际组织数据的时候，还需要一些编码方式，DER就是最常使用的一种，这种编码方式是大字节序的。

PKCS#7/PKCS#1/PKCS#9

这些为多种加密格式的预定义标准。

AuthentiCode签名

微软定义的（使用了PKCS#7等标准的）一种嵌入式签名格式，另外一种常见的为CAT签名（.cat文件）。

通俗一点理解上面的几个概念：ASN.1可以理解为单个的汉字，DER编码则是规定了使用哪些汉字组成一些常用的词组，PKCS#7等标准进一步规定了用哪些词组可以组成一些固定的句式，最后AuthentiCode则综使用这些固定句式写了一篇文章出来。

再谈证书

通过姊妹篇，我们已经大概了解了证书、签名的概念和作用。但是在姊妹篇中，只给出了一张证书的大概结构（下图），并没有对其进行详细解释。

本文由于要进行手工验证，因此有必要给出证书的详细结构：

上述定义使用的是ASN1语法， 此处我们需要先了解如下信息：

• tbsCertificate为上图中的蓝色部分
• signatureValue为上图中的红色部分
• signatureAlogrithm没有体现在上图中，此字段表示使用的是哪个哈希函数对tbsCertificate的数据进行的哈希计算

知道了上述结构，我们就可以搞清楚证书是如何验证的了：

• 提取该证书的父证书（签发者或者叫Issuer）公钥
• 使用公钥解密子证书中的signatureValue部分，然后根据PKCS#9的结构，提取出哈希值1，此处记为Hash1
• 使用signatureAlgorithm中相同哈希算法对tbsCertificate数据做哈希，得到Hash2
• 如果Hash1与Hash2相等，则证书有效

手工验证证书有效性

好了，枯燥的理论暂时告一段落，我们来看一个实际的例子。

我们以Windows版本的Python.exe文件为例， 依次查看其数字签名与证书信息如下：

可以发现Python.exe的数字签名使用的是sha256算法，证书链为：

通过姊妹篇我们知道，整个PKI体系，是建立在信任一些随操作系统或浏览器分发的证书体系之上的。为了方便本文描述，假设我们信任的是上述体系链中的 DigiCert SHA2 Assured ID Code Singing CA 这一张证书，我们选择“详细信息”下的“复制到文件”就可以导出该证书用于研究（记得导出的时候选择DER格式）：

首先我们需要获得父证书的公钥，可以使用openssl命令获取，下面的命令将Python.exe的父证书（PythonParent.cer）公钥输出到了PythonParentPublicKey.pem文件中：

现在父证书公钥有了，接下来我们需要分离Python.exe证书的tbsCertificate和signatureValue部分。那么我们如何知道这两部分在证书中的偏移和长度呢？答案是： 继续使用万能的openssl命令：

首先来直观感受一下Pythone.exe的证书信息：

上述 Signature Algorithm: sha256WithRSAEncryption 下面的即为 signatureValue 部分，把他复制到任意的二进制编辑器中，然后另存为 PythonExeSignatureValue.bin, 最后使用openssl解密这部分数据：

上面是提取的签名数据， 使用下面的命令解密， 解密后的文件保存到 PythonExeSignatureValueDecrypted.bin

上面解密后的“神秘数据”其实是DER编码的PKCS#9消息， 其依然使用ASN1语法规范， 因此可以继续使用openssl解析：

至此，我们得到了第一个哈希值， 该哈希值是一个SHA256值：

CA1C82F3FD7674305439098D87954FE2AFB4A06424BF492F273461462EEAD733

接下来我们需要提取Python.exe证书的tbsCertificate部分， 可以使用如下openssl命令先查看Python.exe证书的结构（为了描述直观，输出内容做了删减）：

上述结果中，每一行冒号开始前的数字代表在数据中的偏移， hl代表头长度， l代表实际的数据长度。根据上文中证书的ASN1结构定义， 我们需要从offset 4开始提取4+1327=1331长度的数据， 此部分数据即为Python.exe证书的tbsCertificate部分， 使用如下命令提取：

然后， 我们对提取的这部分tbsCertificate数据做sha256:

可以看到， 得到的第二个sha2256值“恰好”与上面的第一个sha256值相等。

证书验证小结

回顾一下上面我们干了什么。

1. 从信任证书 DigiCert SHA2 Assured ID Code Singing CA 中提取了此证书的公钥
2. 使用这个公钥解密了Python.exe证书中的signatureValue部分，得到第一个sha256值
3. 提取Python.exe证书的tbsCertificate部分数据，并对提取的数据做sha256运算，得到第二个sha256值
4. 第一个sha256值与第二个sha256相等

因此，得出结论，Python.exe使用的证书是合法有效且没有经过篡改的，因此这张证书中记录的数据，确切的说是这张证书tbsCertificate部分记录的数据，可以完全信任。那么tbsCertificate记录着什么重要数据需要这么“大费周章”的保护呢？答案是：Python.exe开发者的公钥！

众所周知，RSA作为非对称加密，公钥加密的数据只能由私钥解密（不知道的请去读姊妹篇），反之依然。也就是说，现在我们用Python.exe开发者的公钥去解密一段数据，只要解密成功了，这段数据就一定是开发者“发送”的，因为理论上， Python.exe开发者的私钥， 只有可能被开发者所持有。

那么，我们应该拿着Python.exe开发者的公钥去解密哪块数据呢？

让我们继续探索~

PE文件AuthentiCode

在继续之前，我们又需要补充一部分理论知识了。

一点PE文件结构的知识

估计各位对PE文件结构已经不陌生了，但是为了本文的完整性这里还是要简单说一下，熟悉的可以直接跳过。

这里借用一张PE文件结构的图 [参考5]:

我们可以由DOS Header入手， 找到PE Header， 然后是Optional Header中的IMAGE_DATA_DIRECTORY结构。PE签名涉及到的数据，在IMAGE_DATA_DIRECTORY的第5项（下标为4），这一项记录着SecurityDirectory的偏移和长度，使用PE文件结构分析工具，可以轻松定位这块数据：

从上图中可知，此段数据位于RawOffset 0x16E00处，大小为0x1A10，这段数据定义如下：

[注意]看雪招聘，专注安全领域的专业人才平台！