Authenticode Signatures: What You Can Verify Offline
How Authenticode signs a PE file, which checks can be done from the file alone, and why a valid signature is not the same as a trusted one.
TL;DR. An Authenticode signature is a PKCS #7 SignedData blob stored in the PE's certificate table. It signs a hash of the file computed with a few holes. From the file alone you can check that the hash still matches, that the signed attributes cover it and that the signer's signature is mathematically valid. You cannot tell, offline, whether the certificate chains to a trusted root or has been revoked. A good signature proves integrity and provenance, not innocence.
Where the signature lives
Data directory 4 (the certificate table) is special: its "address" is a file offset, not an RVA, because the signature is not loaded into memory. It points to one or more WIN_CERTIFICATE structures — length, revision 0x0200, type 0x0002 (PKCS #7) — normally appended after the last section. Microsoft documents the format in Windows Authenticode Portable Executable Signature Format.
Inside the PKCS #7 (RFC 2315) SignedData:
SpcIndirectDataContentholds the digest algorithm and the file digest;- the embedded certificates (signer, intermediates, often the timestamping authority);
- one
SignerInfowith signed attributes (content type,messageDigest, the optional program name and URL, sometimes a signing time) and the signature over them; - unsigned attributes, typically a countersignature or an RFC 3161 timestamp, and possibly nested signatures (SHA-1 and SHA-256 side by side).
How the file hash is computed
The Authenticode hash covers the whole file except:
- the 4-byte
CheckSumfield of the optional header, - the 8-byte certificate-table entry in the data directories,
- the certificate table itself.
That is why a signed file can have its checksum updated after signing, and why anything appended after the certificate table breaks the match. Data placed between the last section and the certificate table — an overlay — is hashed, so a signed installer's payload is covered.
The three offline checks
The PE Parser performs these on every signed file:
| Check | Question | Failure means |
|---|---|---|
| File hash vs signed digest | Is the file unchanged since signing? | Patched, infected, truncated or with data appended |
messageDigest attribute | Do the signed attributes really cover that digest? | Tampered signature structure |
| Signer's RSA signature | Does the signer's key validate the signed attributes? | Damaged or forged signature |
It also shows the signer, issuer, serial number, validity period, digest algorithm, program name, the signing time and where that time comes from. A time from a countersignature or RFC 3161 token was vouched for by a timestamp authority; a bare signingTime attribute was written by the signer and proves little. See the Authenticode glossary entry.
What stays out of reach offline
- Chain trust. Whether the chain ends at a root in a Windows trust store is a property of the machine, not of the file.
- Revocation. Certificates used to sign malware are regularly revoked; that information lives in CRLs and OCSP responders.
- Catalog signatures. Many Windows system files carry no embedded signature at all: they are signed through
.catcatalog files on the system. An "unsigned"System32DLL copied off a machine may be perfectly legitimate — verify it with the catalogs on the source system. - Policy. Driver signing requirements, WDAC and SmartScreen reputation are decisions of the platform.
Reading the result in an investigation
- Unsigned: common for in-house and open-source tools; means nothing alone.
- Signed, hash matches, self-signed: identifies nobody; anyone can create such a certificate. The sample DLL in the PE Parser is signed this way on purpose.
- Signed, hash mismatch: the file was modified after signing. High priority.
- Signed by a real company, hash matches: check whether that company makes such a tool, whether the certificate was revoked, and whether the signing time fits (PE timestamps).
FAQ
Does a valid Authenticode signature mean a file is safe?
No. It means the file has not changed since someone holding that certificate signed it. Stolen, leaked or fraudulently obtained certificates have signed malware, and self-signed certificates identify nobody.
Which parts of a PE file are excluded from the Authenticode hash?
The CheckSum field of the optional header, the certificate-table entry of the data directories, and the certificate table itself. Everything else, including an overlay before the certificate table, is hashed.
Can the PE Parser tell if a certificate is trusted or revoked?
No. It verifies integrity offline: the file hash against the signed digest, the signed attributes, and the RSA signature with the embedded certificate. Trust and revocation need a trust store and online data.