本文是 《一文读懂对称加密、非对称加密、哈希值、签名、证书、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就是最常使用的一种，这种编码方式是大字节序的。

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

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

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

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

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

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

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

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

我们以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值相等。

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

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

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

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

让我们继续探索~

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

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

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

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

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

可见，从0x16E00处往后偏移2个DWORD才是真正的PKCS#7格式的数据。可以使用如下命令抽取SecurityDirectory中存储的PKCS#7数据：

下文中分析的数据，均为此处提取的数据。

有了上面PE结构的基本知识，让我们来看一下更加有深度的内容，首先借用微软文档中的一张图：

上图中左半部分，基本为上文中提到的PE结构。右半部分，微软对PKCS#7格式的数字签名数据部分做了一个大概的结构介绍。实际上，这部分的数据结构要远比上图复杂，不过目前为止大概只需要知道个基本结构即可。

上图中的右半部分，实际的结构对应SignedData，展开看一下该结构。

上面提到最终提取的数据，是SignedData格式，其实也是符合PKCS#7标准的数据，满足以下ASN.1描述的格式：

其中contentInfo中会存放PE文件的AuthentiCode信息，这个结构中，我们需要关注content字段中存储的数据，详情请见下文。

certificates中会存放PE文件开发者的证书等信息，我们可以从这里面提取开发者的公钥。上文中已经对证书部分做过详细介绍了，此处不再赘述。

signerInfos中存放着使用PE文件开发者私钥加密的数据和一些用于验证其他信息用的数据（可选，不一定有）。

其ASN.1语法的定义如下：

这个定义中，我们最为关注的是 encryptedDigest 字段，根据微软文档的定义，此字段记录了一段被软件签发者私钥加密的数据：

通过分析导出的PKCS#7二进制数据，最终定位到此数据的偏移为：0x15f6(需要跳过4字节头)，大小为0x0200：

将此部分二进制数据复制出来之后，使用Python.exe证书中提取出来的公钥解密：

到这里，我们再次得到了一串神秘的sha256哈希值： B300E437486CB53B647A9C1A84B2986502254681C688020158504646776C31E1。那么问题来了，这段哈希值，是哪段数据的哈希值呢？

这里分两种情况： 不存在SingedData.signerInfos.authenticatedAttributes字段和存在前述字段。其中，第二种情况还有一个巨大的坑，至于是什么坑，下文会讲到。

此种情况下，上述用公钥解密后的哈希值，应该等于ContentInfo字段用相同哈希算法计算后的值。

我们来实际操作一下。

首先是确定需要提取的二进制数据，偏移：0x3d(注意跳过2字节的头) 长度： 0x4c，上图：

验证一下提取数据的哈希值：

貌似……哈希值和上面解密出来的不一样啊……难道搞错了？其实不是的，这里的哈希值不正确是因为本例是第二种情况——其存在authenticatedAttributes字段，这里写出来只是为了作为一个例子，让各位在遇到无authenticatedAttributes字段时知道如何操作。

不过这个sha256值还是有用的， 需要大家留意一下，下文要用到。

看图， authenticatedAttributes字段位于偏移： 0x1548处（这次不需要跳过头部两字节，坑1），长度：0x9a，把此部分数据dump出来，保存为PythonExeAttribute.bin。

注意： 坑2来了，根据RFC规定， 需要将此部分数据的第一个字节，改成0x31， 即0xA1需要替换成0x31！这点一定要注意，不然会导致计算出来的哈希值不对！！

现在计算出来的SHA256就可以和上面公钥解密的数据对上了， 说明Attribute这块数据的确是Python.exe的开发者“发送”的数据，里面的内容我们可以信任。那么……里面的内容又是什么呢？请看上图的红框部分数据，这部分数据是不是“正好”是 PythonExeContentInfo.bin 的SHA256值（请参考“不存在authenticAttributes”一节的最后）？

因此根据哈希值的唯一性，我们进而可以确认ContentInfo部分的数据，也是可信的。那呃ContentInfo部分又双叒存放什么数据呢？ 请注意下图红框中的内容：

我们得到了一个SHA256值： 5A3AD43D81D56A86D97B24B374DA4944AAEE94C710E377254CFE8ECC7204066A，由上面的分析可知，此哈希值是可信的。

大家坚持一下，寻宝游戏快要结束了，因为我们即将迎来最重要的部分——AuthentiCode的计算。

根据微软的文档，AuthenticCode的计算需要跳过CheckSum字段、SecurityDirectory字段以及最后的PKCS#7格式的证书数据部分。

然而本节并不打算过分深入的追究计算过程。因为——感谢伟大的开源精神——Github上有开源的计算工具，而且还很贴心的提供了编译好的二进制程序：

上图就是本文Python.exe程序的AuthentiCode计算结果。这个工具大家可以到 这个Git Repository 中下载。

注意上图的SHA256部分，是不是再次“恰好”和ContentInfo中存放的SHA256数据相等？

PKI体系的最基本思路：

使用这个思路，梳理一下本文中做的事情和涉及到的哈希值：

首先用Python.exe父证书的公钥解密了Python.exe证书的signatureValue部分，得到了第一个哈希值： CA1C82F3FD7674305439098D87954FE2AFB4A06424BF492F273461462EEAD733，该值和Python.exe证书的tbsCertificate部分数据计算的sha256相等，因此tbsCertificate部分的消息未经篡改、可以信任。

tbsCertificate部分的数据， 包含Python.exe开发者的公钥，然后我们使用Python.exe开发者公钥解密了SingedData.SingerInfo.encryptedDigest部分数据，此时得到了第二个哈希值：B300E437486CB53B647A9C1A84B2986502254681C688020158504646776C31E1

使用相同的哈喜算法，计算SignedData.SingerInfo.authenticatedAttributes字段的哈希值，发现此哈希值和第二步中得到的哈希值二相等。经过进一步查看authenticatedAttributes中的数据发现第三个哈希值：b5e4b32d6ebae47869646ccf93416b320a113b2d35d948e7e2a9122146cb9634

使用相同的算法计算SignedData.contentInfo.content哈希值，发现其和第三步之中的哈希三相等。查看SignedData.contentInfo.content的内容，发现第四个哈希值：5A3AD43D81D56A86D97B24B374DA4944AAEE94C710E377254CFE8ECC7204066A

使用微软描述的方法计算Python.exe的AuthentiCode，发现此值和上面第四步中的哈希相等。

查看上面5步的链路，发现其实是环环相扣的，都是用一个已经确认未经篡改的消息，去验证另外一个消息，如此循环往复。从信任的Python.exe父证书开始，到后面的每一步得出的数据都应该认为是受信任的，最终通过AuthentiCode，得出PE文件未经过篡改的结论。

如果你只想白嫖现成的PE验证代码，那么可以参考下面这个Repo的代码，这个工程提供了c/c++/python的接口可以操作PE/ELF/MachO等格式的文件，且依赖很少可移植性较强：

lief-project / LIEF

同时，提供一个可移植性很强的ASN.1解析库，此库使用纯C语言编写：

TinyASN1

最后，上文中提到过的AuthentiCode计算器，开源且提供GUI和命令行版本的二进制文件：

hfiref0x/AuthHashCalc

相信通过上面三个工程以及本文的实操，大家应该可以撸一套自己的完整性校验代码出来了。

最后愿大家的代码永远都不会被Patch~咱们下一篇文章再见 ；）

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！