Inspector de firmas Authenticode online
Elige o suelta un archivo EXE, DLL, SYS o EFI. Se lee en esta página: se analizan los encabezados PE, se calcula el hash Authenticode del archivo como lo hace Windows y se verifica cada firma de la tabla de certificados. Pega el certificado raíz en el que confías para comprobar la cadena del editor.
100 % local: todo se ejecuta en tu navegador y nada se envía a ningún servidor
Fuente: Archivos PE creados para la batería de pruebas y firmados con osslsigncode 2.9 con la PKI de prueba publicada por este sitio (osslsigncode verify aceptó cada uno) — tools/authenticode-inspector/fixtures
Se lee en tu navegador: el archivo nunca se sube.
Certificados PEM en los que confías como raíces. El almacén raíz de Windows no viene incluido: sin una raíz, la firma se comprueba, pero nadie avala al 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.