Authenticode 署名インスペクター
EXE、DLL、SYS、EFI ファイルを選択またはドロップしてください。ファイルはこのページ内で読み込まれます。PE ヘッダーを解析し、Windows と同じ方法でファイルの Authenticode ハッシュを計算して、証明書テーブル内の各署名を検証します。発行元のチェーンを確認するには、信頼するルート証明書を貼り付けてください。
100% ローカル：すべてブラウザー内で処理され、どのサーバーにも何も送信されません
出典：テストスイート用に作成し、当サイトが公開しているテスト PKI を使って osslsigncode 2.9 で署名した PE ファイルです。いずれも 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.