Who signed this EXE? Check before you run it
Drop a Windows program or library to see who signed it and whether the file is still exactly what they signed. It works on a Mac, a Chromebook or a phone, where the Windows Properties tab does not exist, and the file never leaves your device.
The file is read by this tab only. It is not uploaded and it is never run.
What you get
- Windows (.exe, .dll, .sys, .efi, .scr, .ocx, .cpl): the name and organisation on the signing certificate, who issued it, its serial number and validity dates, the time it was signed, and a real check that the bytes still match the signature. Then the architecture (x86, x64, ARM64), 32- or 64-bit, GUI, console, driver or EFI, the compile timestamp, whether it is a .NET assembly, every imported DLL with its function count, and the version information (company, product, file version, original file name, copyright).
- Linux and Android (ELF: programs, .so libraries, .o, .ko): 32- or 64-bit, byte order, whether it is an executable, a shared library, an object file or a core dump, the processor (x86-64, AArch64, ARM, RISC-V …), the dynamic loader it asks for, and every library it links (DT_NEEDED).
- macOS and iOS (Mach-O: apps' binaries, .dylib, bundles): each architecture of a universal file (x86_64 and arm64 side by side), the file type, the minimum OS version, every linked library (weak and re-exported ones marked), and whether an Apple code signature is present.
How the signature check works
A signed Windows program carries its signature inside the file: data directory 4 of the PE header points to a certificate table at the end of the file, holding a PKCS#7 SignedData blob. The layout is set out in Microsoft's Windows Authenticode Portable Executable Signature Format (version 1.0, 2008) and in the "Attribute Certificate Table" section of Microsoft's PE Format specification. viewhack reads it with its own DER parser and runs three checks, all in this tab with your browser's WebCrypto:
- The file digest. It hashes the whole file except three pieces the signature cannot cover: the 4-byte CheckSum field (at byte 64 of the optional header), the 8-byte Certificate Table entry, and the certificate table itself. The result must equal the digest stored in the signature's SpcIndirectDataContent. Change one byte anywhere else and this fails.
- The signed content. The signer does not sign the file digest directly; it signs a set of attributes, one of which (messageDigest) is the hash of that SpcIndirectDataContent. Someone who patched the file and wrote a fresh digest into the signature fails here.
- The signature itself. The attributes are verified against the public key in the signer's certificate: RSA (PKCS#1 v1.5) or ECDSA on P-256, P-384 or P-521. Someone who rewrote the attributes too fails here, because that needs the signer's private key.
Only when all three pass does the page say The file matches what was signed. If any fails it says the signature does not match — the file was changed after signing, and names the step. MD5 signatures, RSA-PSS and curves WebCrypto lacks (secp256k1, Brainpool) get cannot be checked here, never a match. A file with no certificate table is reported as not signed.
The same check elsewhere: on Windows, right-click the file › Properties › Digital Signatures, or signtool verify /pa /v file.exe; on Linux or a Mac, osslsigncode verify file.exe. Those also check the certificate chain, which this page does not (see below).
Reading the results
- Signed at, or not timestamped
- A timestamp (a legacy countersignature, or an RFC 3161 token from a timestamping service) records when the file was signed. Windows keeps accepting a timestamped signature after the certificate expires; an untimestamped one stops being accepted on the expiry date. The timestamp's own signature is not checked here.
- Compile timestamp
- The linker's date in the file header, shown in UTC. Since Visual Studio 2015 many builds are reproducible and put a hash there instead; when the value lies in the future or before 1990, or the file carries a reproducible-build marker, the page says so rather than showing a nonsense date. Anyone can set this field, so it is a claim, not proof.
- Version information
- Company, product and version come from the file's VS_VERSIONINFO resource, which whoever built it wrote. If the OriginalFilename differs from the name of your file, the page points it out: a system-sounding name on an unrelated program is an old disguise.
- Unsigned Windows system files
- Many files that ship with Windows, including most of System32, are signed through catalog files Windows stores separately, so they show as not signed here although Windows trusts them. A downloaded installer from a known vendor, on the other hand, is almost always signed inside the file.
- Linux and macOS files
- ELF binaries have no built-in signature: Linux distributions sign packages, not programs. A Mach-O slice is reported with its code signature present or absent; checking Apple's signature and notarisation needs
codesign -dvandspctl -a -vvon a Mac.
What this cannot tell you
- Whether the signer is trustworthy. There is no certificate-chain check against a root store: a self-signed certificate, or one from an unknown issuer, shows the same facts as one Windows trusts. Read the names, and be wary of a well-known company name on a certificate from an issuer you have never heard of.
- Whether the certificate was revoked. There is no revocation check (that needs the issuer's servers, and this page contacts none).
- Whether the program is malware. This is not a malware scan. A valid signature proves who signed and that the bytes are unchanged, not that the program is safe: signed malware exists, and stolen signing keys have been used for it.
- Anything that needs running it. viewhack never runs the file; it only reads its bytes.
- Nested and catalog signatures. Only the first embedded signature is checked; a second, nested one (often added with a newer hash) is counted but not checked, and catalog signatures are not visible from the file.
- Installers' contents. An installer's payload (the files it would unpack) is not opened. Some installers are archives; the archive viewer lists those. Windows Installer .msi files are not PE programs and are not read here.