Inspetor de assinaturas Authenticode (Authenticode Signature Inspector)
Escolha ou arraste um arquivo EXE, DLL, SYS ou EFI. Ele é lido nesta página: os cabeçalhos PE são analisados, o hash Authenticode é calculado sobre o arquivo do mesmo jeito que o Windows faz, e cada assinatura da tabela de certificados é verificada. Cole o certificado raiz em que você confia para verificar a cadeia do editor.
100% local — tudo roda no seu navegador, nada é enviado a nenhum servidor
Fonte: Arquivos PE escritos para a suíte de testes e assinados com o osslsigncode 2.9 usando a PKI de teste publicada por este site (o osslsigncode verify aceitou cada um) — tools/authenticode-inspector/fixtures
Lido no seu navegador — o arquivo nunca é enviado.
Certificados PEM em que você confia como raízes. O trust store do próprio Windows não vem incluído: sem uma raiz, a assinatura é verificada, mas nada confirma a identidade do editor.
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.