为了方便在 mac 和 Linux 下解析与验证 PE 签名，我开发了一个跨平台工具 https://github.com/0xlane/pe-sign。安装和使用方法可以参考项目中的 README_zh.md。本文分享的是开发该工具之前做的一些签名研究内容。

具体的 PE 格式可以参考 MSDN。

签名证书的位置在 Certificate Table 里（也称为 Security Directory）：

可以从 Optional Header 的 Data Directories 里找到 Security Directory 的文件偏移：

如图表示，ProcessHacker.exe 文件的签名数据在 0x1A0400 位置，长度 0x3A20。

导航到这个偏移位置即可看到这里就是签名数据：

参考 MSDN， 签名数据的结构如下：

所以，bCertificate 是实际的证书内容，wCertificateType 表示签名证书类型，根据这个字段可知支持三种证书类型：PKCS #1、PKCS #7、X509，我看到过的文件都是使用 PKCS #7 签名。

找到 Security Directory 偏移之后，跳过前面的 8 字节就是实际的 PKCS #7 证书内容，DER 格式，代码示意：

使用项目中的 pe-sign 工具可以直接导出：

使用 --pem 参数可以将 DER 格式转换为 PEM 格式：

解析导出的证书，如果是 PEM 格式，-inform DER 改为 -inform PEM：

这里有个小疑问，从属性里看 ProcessHacker.exe 文件有两个签名，一个是 sha1,另一个是 sha256：

openssl 打印的证书信息只有 sha1 证书的，使用 -print 参数打印 pkcs7 结构也可以看到是有 sha256 证书内容的但是没正确解析。

看了下微步沙箱也只解析到了 1 个签名：https://s.threatbook.com/report/file/bd2c2cf0631d881ed382817afcce2b093f4e412ffb170a719e2762f250abfea4

经过一番观察，发现 sha256 这个证书是在 sha1 证书属性里内嵌的，并不是平级：

然后就搜了一个这个属性名 1.3.6.1.4.1.311.2.4.1 有什么特殊的地方，从 MSDN 可知，这个值表示的是 szOID_NESTED_SIGNATURE 内容（实际就是一个 pkcs#7 格式证书），ChatGPT 是这么解释这个属性的：

szOID_NESTED_SIGNATURE 是一个表示嵌套签名的对象标识符（OID），其对应的 OID 是 1.3.6.1.4.1.311.2.4.1。在 PKCS7 或 CMS（Cryptographic Message Syntax）中，嵌套签名允许在签名数据中嵌套另一个签名数据块。这种机制用于实现多层次的签名或加密操作。

使用 openssl 的 asn1parse 命令可以找出嵌套签名的偏移位置：

SET 后面开始就是嵌入数据，7658 就是嵌套数据开始的文件偏移，hl 表示头大小，l 表示数据大小，所以总的嵌套数据大小为 4+7203=7207。使用 powershell 提取这个嵌套签名：

再次使用 openssl 就可以解析出这个嵌套签名证书：

代码解析的话，需要按 ASN.1 结构手动解析，因为这里找的内容算是个固定的，只需要定位 1.3.6.1.4.1.311.2.4.1 所在位置就可以。所以就需要研究一下 OID 在证书内是以怎么方式存储的，根据之前 openssl 的 asn1parse 命令的结果可以知道偏移位置 7642 + 2 处为 1.3.6.1.4.1.311.2.4.1，长度 10：

用下面的代码读取出来为 2b 06 01 04 01 82 37 02 04 01：

可以发现有些数字是可以直接能和 1.3.6.1.4.1.311.2.4.1 对应上的：

不难看出，这里的 2b 就是表示的 1.3，82 37 表示的 311。但是 13 的十六进制表示为 D、311 的十六进制表示为 137，所以这里并不是直接的10-16转换关系。查了一些 OID 的资料，在 这篇文章 中找到了一些关于 OID 编码方式的描述：

OID 的实质就是一串整数， 而且至少由两个整数组成。 第一个数必须是 0、1、2 三者之一， 如果是 0 或 1，则第二个数必须小于 40。 因此，前两个数 X 和 Y 可以直接用 40×X+Y 来表示，不会产生歧义。

以 2.999.3 的编码为例，首先要将前两个数合并成 1079（即 40×2+999），得到 1079.3。

完成合并后再用 Base 128 编码，左侧为高位字节。 也就是说，每个字节的最高位设为 1，但最后一个字节最高位设为 0，表示一个整数到此结束。各字节的其余七位从高到低依次相连表示数值。 例如数字 3 就用一个字节 0x03 表示， 而 129 则需要两个字节 0x81 0x01。 每个数字都如此转换成字节后，拼接在一起就形成了 OID 的编码。

无论是在 BER 还是 DER 中，OID 都必须用最短的方式编码。 所以其中每个数字编码时开头都不能出现 0x80 字节。

所以只有开头的 1.3 编码方式和后面不一样，后面都是 Base 128 编码。1.3 需要先按公式变成 40x1+3 = 43，再转换为十六进制就是 2b。反着推就是 2b 的十进制表示为 43，需要先确定第一位，因为只能是 0、1、2。

0 和 1 时第二个数不能超过 40，所以可以知道第一位：

所以 43 在 [40, 80) 之间，第一位应该是 1，第二位就是 43 - 40x1 = 3。

后面每个数字都由 Base 128 编码方式存储，即数字在 128 (0x80) 以内（不包含 128）不需要转换直接存储，所以在上面能看到有些个位数的数字能直接对应上。128 之后就需要转成二进制从右向左每 7 位拆分一次，例如 311 的二进制表示为 100110111，每 7 位拆分 1 次变成：

前面补 0 变 8 位：

除最后 1 个字节（8 位）不需要动，前面每个字节最高位变成 1：

最后变成 十六进制看就是 82 37。

现在对 2b 06 01 04 01 82 37 02 04 01 整体反向解析一下，开头两位前面说过了，2b 表示 1.3，后面的数字需要 1 个接 1 个字节换成二进制形式地看：

合起来最终得到 1.3.6.1.4.1.311.2.4.1。

搞明白这个之后，可以直接通过 2b 06 01 04 01 82 37 02 04 01 定位到后 1 位再向后偏移 4 字节跳过 SET 块就是 SEQUENCE，此处便是内嵌证书的开头位置，一般直接读取到结尾就可以，严谨一点的话需要解析一下头部位置：

第 1 个字节是标签，30 表示 SEQUENCE 不用管，第二个字节最高位被设置为 1 的时候代表长编码，为 0 表示短编码，短编码时该字节就表示内容的长度，长编码时该字节表示存储长度的字节大小，0x82 最高位为 1，所以是长编码形式，去掉最高位的 1 就是 0x2，表示后面有 2 个字节用来表示 SEQUENCE 内容的长度，即 0x1c23，加上头的长度，这里是 4，内嵌证书长度就是 0x1c27。

代码实现：

现在可以直接使用项目中的 pe-sign 工具的 --embed 参数直接导出：

也可以直接传递到 openssl 解析：

PKCS #7 证书的验证可以直接调用 PKCS7_verify，该函数原型：

根据参数可以知道验证证书需要准备的东西：

里面比较特殊的是 indata 参数，根据资料显示如果证书为 detached 证书，即签名独立证书，此时证书内不包含被签名的原始数据内容，需要调用 PKCS7_verify 时传入 indata 参数，否则可以为空。

这样的话，PE 中提取的证书内必然包含被签名的原始数据，所以看似不需要传入 indata，使用这个函数对应的 openssl 命令快速验证一下：

验证失败了，导致失败的报错信息是 digest failure 和 signature failure，看起来是签名和原始数据内容并不匹配。大概查了一下，PKCS #7 SignedData 结构用 ASN.1 描述为：

ContentInfo 中保存的原始数据，encryptedDigest 中是消息摘要，验签时需要使用签名者的 publickey 解开 encryptedDigest 得到一个 hash，然后如果存在 authenticatedAttributes，里面能再提取出一个消息摘要，这个消息摘要的 hash 如果和 encryptedDigest 中的一致说明可信，验证 authenticatedAttributes 可信后，从 authenticatedAttributes 中又可以得到一个 hash，这个 hash 是 ContentInfo 中原始内容的 hash，最终通过该 hash 验证原始数据内容是否可信。假如没有 authenticatedAttributes，encryptedDigest 的消息摘要 hash 就是 ContentInfor 原始内容的 hash。

调用 PKCS7_verify 时，会自动进行上面的验证，但是当解析 ContentInfo->content 的时候，根据 ContentInfo->contentType 类型解析，只有类型为 data、ASN1_OCTET_STRING 才能被正确解析到 content（参考源码位置 pk7_doit.c#L48）。

根据 Authenticode_PE.docx 中的描述，Authenticode 相当于 PE 文件的 hash，保存在 ContentInfo->content 中，ContentInfo->contentType 必须是 SPC_INDIRECT_DATA_OBJID (1.3.6.1.4.1.311.2.1.4)，所以 PKCS7_verify 并不能解析出 content 内容，需要自行解析后通过 indata 参数传入。

以下是 SpcIndirectDataContent 的 ASN.1 定义：

对应的 asn1parse 解析结果：

下面是 pe-sign 工具中关于提取 indata 的代码：

由于 openssl 解析出的证书信息只是一些证书通用的信息，有些关键字段还需要单独解析一下：

签名时间大多数时候存储在副署签名里，少数直接在认证属性里就可以找到，在副署签名里的时候有两种情况：

第一种情况，当 unauth_attrs 直接存在副署（countersignature）属性时，该内容为 PKCS7_SIGNER_INFO 结构，表示副署签名者信息，该信息作为副署（countersignature）签名展示：

第二种情况，不存在副署（countersignature）属性，寻找 unauth_attrs 中的 1.3.6.1.4.1.311.3.3.1 属性作为副署签名，该内容为 Timestamping signature：

该属性内容被作为副署（countersignature）签名展示：

签名时间一般保存在副署签名中名为 signingTime 的 auth_attrs 里：

如果 signingTime 属性不存在（案例），签名时间保存在 contentInfo->content 中。

把案例文件的 1.3.6.1.4.1.311.3.3.1 属性内容导出：

从结果中可以看到，contentInfo->content 内容类型为 id-smime-ct-TSTInfo，里面也是一段 ASN.1 序列化数据：

从右侧可以看出，20240801004644.617Z 就是签名时间。程序中需要解析 TSTInfo 结构：

提取出 contentInfo->content，并通过 openssl 解析 asn1 结构：

没有找到能快速解析 TSTInfo 结构的方法，所以代码里直接通过搜索第一个 GENERALIZEDTIME 作为签名时间。在 ASN.1 序列化数据中 0x18 表示 GENERALIZEDTIME，后跟一个字节表示长度，因为 GENERALIZEDTIME 时间格式大多数时候为 YYYYMMDDHHMMSSZ、YYYYMMDDHHMMSS.sssZ，其他情况遇到再改代码吧，s 可以减少不一定是 3 个，所以长度在 15 - 19 这个范围，找 18 [15, 19] 序列即可。

Authenticode 信息在 indata 里，需要根据 SpcIndirectDataContent 结构解析：

SpcIndirectDataContent->messageDigest->digest 就是 authenticode，indata 数据开头的 sequence 表示的是 SpcIndirectDataContent->data，跳过这个 sequence 就是 messageDigest。

提取代码：

通过 pe-sign 工具验证证书并打印证书信息：

Authenticode_PE.docx 中有详细的 authenticode 计算步骤：

可以通过 pe-sign 工具计算 authenticode，支持 sha1、sha256、md5 三种算法：

使用 pe-sign 工具验证文件签名时，status 如果是 InvalidSignature 表示证书中的 authenticode 与实际不符，文件被篡改：

大多数工具只提供了公钥验签，不提供公钥解密功能。可以使用类似 https://www.lddgo.net/en/encrypt/rsa 的在线解密工具，对签名数据解密。

打开 cerlm.msc 证书管理窗口，导航到“受信任的根证书颁发机构->证书”，全选后导出为 p7b。

然后通过 openssl 可以转换 p7b 证书为 pem：

不过这种方式，不知道什么原因导出的证书有时候并不全，可能有缺失。

所以改用 python 的 wincertstore 库枚举系统根证书然后导出为 PEM：