What is a PE file?
PE (Portable Executable) is the file format of Windows programs: .exe, .dll, .sys drivers, .scr, .cpl, .ocx and EFI binaries. It starts with an MS-DOS header ("MZ"), then a PE signature, a COFF file header, an optional header with 16 data directories, and a section table that maps the file into memory.
Static analysis reads that structure without running anything: what the file imports, when and with what it was built, whether it is signed, what it carries in its resources and overlay. It is the first, safe step of malware triage.
What this tool reads
- Headers: DOS, COFF and optional header (PE32 and PE32+), data directories, section table with raw/virtual sizes, flags and entropy per section, checksum recomputed.
- Imports (ordinals of ws2_32, wsock32 and oleaut32 named), delay-load and bound imports, exports and forwarders, imphash.
- Resources: version information, manifest, icons, string tables, dialogs, embedded files; overlay detection.
- Rich header decoded to Visual Studio releases, debug directory (PDB path, GUID, age), TLS callbacks, load configuration (CFG, SafeSEH), relocations.
- Authenticode: signer, certificates, timestamp, file hash versus signed digest and RSA signature check. .NET: CLR header, metadata streams, assembly, references, P/Invoke, types.
- Strings (ASCII and UTF-16LE) with categories, MD5 / SHA-1 / SHA-256 / TLSH, packer and compiler heuristics, and a batch table to spot families.
- Unpacking: UPX-packed files are rebuilt with their original imports, and executables hidden inside a file (stored as-is, XOR-encoded, or compressed with LZNT1, aPLib, zlib, gzip or LZMA) are extracted and analysed as child files.
Why it matters in an investigation
- Hashes and imphash let you search threat intelligence and group variants of the same tool; TLSH measures how close two files are.
- Compile, debug and signing times date a tool — and disagreements between them reveal tampering.
- Imports and strings show capabilities (network, injection, persistence) and indicators (URLs, IPs, paths, registry keys).
- Version information, PDB paths and the Rich header point to the author's environment; a signature says who vouched for the file.
Limitations
- Static only: UPX is unpacked in the browser, but other packers, protectors and encrypted code have to be unpacked elsewhere before their real imports and strings appear.
- Certificate chains are not validated (no trust store, no revocation): the tool checks integrity, not trust.
- Packer detection relies on a small set of heuristics, not on a signature database such as Detect It Easy's.
- No disassembly or emulation; no ssdeep (no permissively licensed implementation).
How to get the files
- Pivot from execution artefacts (Prefetch, Amcache, services, tasks) to the exact paths, then copy those files without running them.
- On a live system, sweep user-writable folders with PowerShell or collect running binaries with Velociraptor's Windows.Triage.Targets (_Live).
- Keep folder structure and hash everything before analysis.
FAQ
Is the file uploaded or executed?
Neither. The analyzer is Rust compiled to WebAssembly and runs in a Web Worker in your browser. It only reads bytes: no emulation, no sandbox, no upload endpoint.
Can it tell me if a file is malware?
No tool can from static data alone. It shows facts (imports, signature, packer, timestamps) and plain-language indicators worth a look. Combine them with context, threat intelligence and, if needed, dynamic analysis in a sandbox.
Does it verify signatures like Windows does?
Partly. It recomputes the Authenticode hash and checks it against the signed digest, then verifies the signer's RSA signature with the embedded certificate. It does not check whether the chain ends at a trusted root or whether a certificate was revoked — that needs a trust store and online data.
Can it unpack UPX and extract hidden payloads?
Yes, statically. UPX-packed EXEs and DLLs (32- and 64-bit, every compression method, also with a tampered header that makes upx -d refuse them) are decompressed as data and rebuilt with their original imports, so the imphash matches the original build. Executables hidden inside a file, stored as-is, XOR-encoded or compressed with LZNT1, aPLib, zlib, gzip or LZMA, are extracted too. Each one is added as a child file and can be saved as a ZIP protected with the password infected.
How is the imphash computed?
Exactly like pefile: lower-case "dll.function" pairs (the .dll, .ocx or .sys extension dropped, ordinals of ws2_32, wsock32 and oleaut32 named from pefile's tables, others as ordN), joined with commas, then MD5. Delay-load imports are not included.
How is this different from pestudio, PE-bear or Detect It Easy?
It brings the views analysts use most from those tools into one page with no install, handles a batch of files at once (hashes, imphash families, time range, comparison) and never needs the sample on an analysis VM. Those tools go deeper in their specialities: disassembly, signature databases, editing.