Authenticode 签名查看器
选择或拖放 EXE、DLL、SYS 或 EFI 文件。文件在此页面中读取：解析 PE 头，按 Windows 的方式对文件计算 Authenticode 哈希，并验证证书表中的每个签名。粘贴你信任的根证书，即可检查发布者的证书链。
100% 本地运行——所有操作都在你的浏览器中完成，不会向任何服务器发送数据
来源：为测试套件编写的 PE 文件，使用本站公开的测试 PKI 通过 osslsigncode 2.9 签名（每个文件都通过了 osslsigncode verify）——tools/authenticode-inspector/fixtures
在浏览器中读取——文件绝不会上传。
你作为根信任的 PEM 证书。本工具不内置 Windows 自带的根证书库：不提供根证书时，仍会检查签名，但无法为发布者担保。
Where the signature lives
Authenticode is how Windows signs executables. A Portable Executable (PE) file — EXE, DLL, SYS driver, EFI application — keeps its signatures in the attribute certificate table, which the fifth data directory of the optional header (the security directory) points to, as described in the PE format specification. Each entry is a WIN_CERTIFICATE of type WIN_CERT_TYPE_PKCS_SIGNED_DATA: a PKCS #7 SignedData whose content is an SpcIndirectDataContent — the hash of the image and the algorithm that made it. Microsoft's Windows Authenticode Portable Executable Signature Format defines how that hash is computed.
What the image hash covers
A signature cannot cover the place where it is stored, so the Authenticode hash skips three things: the PE checksum field, the security directory entry, and the certificate table itself. Everything else — headers, sections, and data between them — is hashed in file order. The inspector parses the PE32 or PE32+ headers, recomputes that hash with the algorithm the signature names (SHA-256 today, SHA-1 in old signatures, which Windows no longer accepts for most purposes) and compares it with the signed one: equal means the executable is byte for byte what was signed.
What is skipped is also where things hide. Bytes inside the certificate table but outside its signature entries change nothing in the hash; installers have been abused this way to carry an unsigned payload under a valid signature (the class of problem behind CVE-2013-3900). The inspector reports such bytes, data stored after the certificate table, where none belongs, and a header checksum that does not match the file — which Windows only enforces for drivers and boot files.
Signer, dual signatures and time-stamps
Each signature has one signer. The inspector verifies the PKCS #7 signature over the signed attributes, the message digest of the indirect data, and the signer's certificate chain with the code-signing extended key usage. Windows' root store is not bundled with the page: paste the root certificate you trust — your company's code-signing root, or a public CA's — and the chain is checked against it; without one, the signature is verified but the publisher is reported as not vouched for.
Many programs carry two signatures: a SHA-1 one for old Windows versions with a SHA-256 signature nested in its unsigned attributes. The inspector lists and verifies every nested signature. A signing certificate expires; a time-stamp keeps the signature valid after that, by proving it existed while the certificate was valid. RFC 3161 time-stamp tokens and the older PKCS #9 countersignatures are both verified, and the chain is then checked at the time-stamped moment instead of now. A signature without a time-stamp stops being valid when its certificate expires — the inspector says so. Signatures that carry page hashes (used for drivers and memory integrity) are marked.
The examples were built for the test suite: PE images signed with osslsigncode from this site's published test PKI, verified with osslsigncode verify when they were generated; the test root is filled in as the trust anchor. The time-stamps inside signatures are decoded in detail by the time-stamp token inspector, the signer's certificate by the certificate decoder; Java archives are signed the same way with PKCS #7 and checked by the JAR signature inspector.