当前位置: 首页 > 知识库问答 >
问题:

验证PE文件的签名

郤仰岳
2023-03-14

我试图用OpenSSL验证一个PE文件的证书/签名(或者实际上用Python,但是看起来Python在证书处理方面很糟糕)。

我已从PE文件中提取了DER PKCS7证书,如下所述:http://blog.didierstevens.com/2008/01/11/the-case-of-the-missing-digital-signatures-tab/

我已经创建了一个没有校验和和签名数据的PE文件的修改版本,就像这里描述的:http://www.mail-archive.com/cryptography@c2.net/msg04202.html

修改文件的sha1sum与证书中的sha1sum相同。

我尝试使用openssl验证未签名、修改过的PE文件,例如:openssl smime-verify-in签名。der-内容修改的可执行文件。exe-inform DER-binary但我只得到

验证失败140415508248232:错误:21075075:PKCS7例程:PKCS7_verify:证书验证错误:pk7_smime. c:342:验证错误:不支持证书目的

如果我将-noverify添加到刚刚得到的命令中

验证失败140595583981224:错误:21071065:PKCS7例程:PKCS7_签名验证:摘要失败:pk7_doit。c:1097:140595583981224:错误:21075069:PKCS7例程:PKCS7_验证:签名失败:pk7_smime。c:410:

我错过了什么?

共有3个答案

姬翰林
2023-03-14

我已经创建了一个没有校验和和签名数据的PE文件的修改版本,就像这里描述的:http://www.mail-archive.com/cryptography@c2.net/msg04202.html

为什么不使用微软发布的格式呢?没有必要求助于逆向工程。

我错过了什么?

一个PE/PE可执行文件有部分签名,而不是整个文件。当消化数据时,您必须省略OptionalHeader中的校验和,省略Data Directory中的证书表,并省略属性证书表部分。

以下是您可能需要熟悉的两个参考资料:

  • 微软PE和COFF规范
  • Windows Authenticode便携式可执行签名格式

要省略的部分如Windows Authenticode可移植可执行签名格式第6页所示。其内容转载如下。

如果您需要以编程方式了解PE文件格式的帮助,请参阅Matt Pietrek在MSDN杂志上的《深入了解Win32可移植可执行文件格式》。

山越
2023-03-14

验证失败140415508248232:错误:21075075:PKCS7例程:PKCS7_verify:证书验证错误:pk7_smime. c:342:验证错误:不支持证书目的

正如已经指出的,在验证smime(或cms)时,OpenSSL有一个特性:它的行为就像已经传递了-目的smimemark。这里有详细信息。

如果您的签名证书与OpenSSL的smimesign目的不兼容(请参阅man x509,关于"目的"列表的CERTIFICATE EXTENS部分),那么您将不得不禁用使用的扩展检查任何(如果您的策略需要,请将它们与其他函数进行检查)。

如果我在命令中添加-noverify

你可能不想。此选项禁用对签名者证书的任何检查。

司寇烨伟
2023-03-14

假设:以下是使用OpenSSL 0.9.8e在Cygwin上完成的

对于“不支持的证书用途”,直接签名者可能没有S/MIME用途。

$ openssl x509 -purpose -in goodcert.pem -noout
Certificate purposes:
SSL client : No
SSL client CA : No
SSL server : No
SSL server CA : No
Netscape SSL server : No
Netscape SSL server CA : No
S/MIME signing : No
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
CRL signing : No
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes

关于这一点,我添加了开关“-purpose any”。然后我不再看到“不支持的证书用途”,但仍然会遇到相同的摘要

1900:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:pk7_doit.c:948:
1900:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:312:

根据本文的提示和大量的研究(#1,#2),结果证明输入到-content的“modified_exe”是错误的。它应该是PKCS#7 SignedData序列ContentInfo中的内容字段,不包括其DER标记和长度字节
请参阅Authenticode\u PE。签署数据声明的docx
(我觉得太多细节不合适,包括!)请检查以下内容以了解清楚程度:

openssl asn1parse -inform der -in signature.der > signature.txt
head signature.txt -n30
    0:d=0  hl=4 l=5464 cons: SEQUENCE          
    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
   15:d=1  hl=4 l=5449 cons: cont [ 0 ]        
   19:d=2  hl=4 l=5445 cons: SEQUENCE          //SignedData
   23:d=3  hl=2 l=   1 prim: INTEGER           :01 //Version
   26:d=3  hl=2 l=  11 cons: SET               //DigestAlgorithmIdentifiers
   28:d=4  hl=2 l=   9 cons: SEQUENCE          
   30:d=5  hl=2 l=   5 prim: OBJECT            :sha1
   37:d=5  hl=2 l=   0 prim: NULL              
   39:d=3  hl=2 l= 104 cons: SEQUENCE          //ContentInfo
   41:d=4  hl=2 l=  10 prim: OBJECT            :1.3.6.1.4.1.311.2.1.4 //ContentType
   53:d=4  hl=2 l=  90 cons: cont [ 0 ]        
   55:d=5  hl=2 l=  88 cons: SEQUENCE          //SpcIndirectDataContent (exclude this tag and length bytes)
   57:d=6  hl=2 l=  51 cons: SEQUENCE          //SpcAttributeTypeAndOptionalValue
   59:d=7  hl=2 l=  10 prim: OBJECT            :1.3.6.1.4.1.311.2.1.15 //ObjectID
   71:d=7  hl=2 l=  37 cons: SEQUENCE          
   73:d=8  hl=2 l=   1 prim: BIT STRING        
   76:d=8  hl=2 l=  32 cons: cont [ 0 ]        
   78:d=9  hl=2 l=  30 cons: cont [ 2 ]        
   80:d=10 hl=2 l=  28 prim: cont [ 0 ]        
  110:d=6  hl=2 l=  33 cons: SEQUENCE          //DigestInfo
  112:d=7  hl=2 l=   9 cons: SEQUENCE          //AlgorithmIdentifier
  114:d=8  hl=2 l=   5 prim: OBJECT            :sha1 //ObjectID
  121:d=8  hl=2 l=   0 prim: NULL              
  123:d=7  hl=2 l=  20 prim: OCTET STRING      [HEX DUMP]:<hash of modified_exe> //digest OCTETSTRING
  145:d=3  hl=4 l=4774 cons: cont [ 0 ]        
  149:d=4  hl=4 l=1332 cons: SEQUENCE          
  153:d=5  hl=4 l= 796 cons: SEQUENCE          
  157:d=6  hl=2 l=   3 cons: cont [ 0 ]        
  159:d=7  hl=2 l=   1 prim: INTEGER           :02

从偏移量57到144的字节流是-Content的正确输入!
确切的偏移量取决于您的文件。
作为粗略的指导,1.3.6.1.4.1.311.2.1.15之前的两行是SpcInDirectDataContent,在这一行中,请注意55 2 88-1=144。下一行从57开始。最终cmd:

openssl smime-verify-Notify-DER-in签名。der-二进制-内容签名数据-CAfile myCA。crt用途任意输出tmp

 类似资料:
  • > 文件,将ZIP文件的内容描述为XML(文件); 包含传输文档内容的文件(例如,文件); 具有分离数字签名内容的文件(文件-分离数字签名); > 方法(请参阅下面的此方法)当前未使用文件的分离签名。我确实试过了,但没有成功。如何正确验证文件对应文件的分离签名? 在方法(请参阅下面的方法)中,如何验证从文件中提取的证书与从Base64格式的输入字符串中提取的证书的一致性? 代码行-->Certif

  • 问题内容: 我正在尝试以编程方式验证jar文件是否未被明显篡改。我有2个要防止的用例。1)修改现有类2)在罐子中添加新类 我使用jarsigner签名了罐子。当我用jarsigner验证以上两种情况之一时,它的工作方式就与我期望的一样。 当我尝试使用如何以编程方式验证用jarsigner签名的jar 或如何通过自签名的jar验证签名中的示例以编程方式进行操作时 ?但是,我没有任何SecurityE

  • 我已经使用Node rsa在Node中生成了一对私钥和公钥,并且可以在Node中使用这些密钥成功地进行签名和验证。 我尝试使用公钥的模和指数来验证中的签名(由节点中的私钥签名)。网 e、 g.我有一个string=“foo”,它有一个由Node生成的签名“abc123”。在里面NET我想使用公钥的模和指数来确认签名“abc123”对“foo”有效。 我想使用模数和指数而不是直接使用公钥的原因是因为

  • 问题内容: 我正在研究可分析android应用程序的Java SE应用程序。 是否有任何可用于验证AndroidManifest.xml的架构/ DTD?如果找到名称空间定义,例如: 但是schemas.android.com不能解析为实际主机,因此那里没有架构文件:-( 注:我 不 希望做验证在Android作为一个平台。 问题答案: Android XML没有DTD /方案 ,您必须依靠其他可

  • 问题内容: 我正在研究可分析android应用程序的Java SE应用程序。 是否有任何可用于验证AndroidManifest.xml的架构/ DTD?如果找到名称空间定义,例如: 但是schemas.android.com不能解析为实际主机,因此那里没有架构文件:-( 注:我 不 希望做验证在Android作为一个平台。 问题答案: Android XML没有DTD /方案 ,您必须依靠其他可

  • 是否可以验证带有p7s分离签名的文件?我正试图使用Openssl实现这一点,但我得到了一条关于Openssl的默认消息和 这是我的命令: 是否可以使用openssl进行文件验证和p7s签名? --编辑。。。 只是想让你知道。我有一个p7s文件和一个pdf文件。我想知道如何验证这一点。