Executable Forensics - Free Online PE/ELF/Mach-O Analyzer
Executable Forensics
Load a Windows PE (.exe/.dll), Linux ELF, or macOS Mach-O binary to inspect its headers, sections, imports and exports, embedded resources, and code-signature coverage - without uploading anything.
Drop a PE, ELF or Mach-O binary here
.exe .dll .sys .so .o .dylib or any ELF/Mach-O binary - or click to browse from your device
Choose fileOverview
What this binary is, its target platform and architecture, and what stands out about how it was built.
Headers
The file, optional/program and load-command headers that describe how the loader should map and run this binary, plus provenance markers such as the PE Rich header, the compiler comment string, and .NET/CLI detection - and the two pivot hashes, the import hash (imphash) and the Rich header hash, computed exactly as pefile and VirusTotal compute them.
Sections
Every section or segment, its permissions, and its byte entropy - a section that is both writable and executable, or unusually high-entropy, is worth a closer look. Below the table, the overlay: any data past the end of what the headers describe, with its size, entropy, whether it holds the code-signing certificate, and buttons to save it or open it in Binary & Archive Forensics.
Imports
Every external library and symbol this binary declares it needs at load time - DLLs and functions for PE, needed shared objects and dynamic symbols for ELF, loaded dylibs for Mach-O. For PE, each DLL opens to its imported functions, and functions on the suspicious-API list (process injection, keylogging, anti-debugging, credential access and more) are flagged and summarised by category.
Exports
Symbols this binary makes available to whatever loads it - names, ordinals, and forwarders that redirect to another module entirely.
Resources
PE version information and embedded manifest, decoded from the resource directory tree - including whether the file's recorded original filename matches its actual one.
Code Signature
Whether the binary carries an embedded signature, and who it names as signer - presence and coverage only. This tool never validates a certificate chain or confirms a signature actually verifies.
Strings
Readable ASCII and UTF-16 text pulled from anywhere in the file, useful for spotting file paths, URLs, and command-line fragments a header-only view would miss.
--
Understanding Executable Forensics
Three Formats, One Idea
Windows PE, Linux ELF and macOS Mach-O all solve the same problem - describe a program's code, data and dependencies so an operating system loader can map it into memory and run it - with different header layouts. PE prefixes a DOS stub before its real header for backward compatibility, ELF uses a compact fixed-size header naming every section, and Mach-O organizes everything as a stream of typed load commands. Reading the headers directly, rather than trusting the file's extension, is the first step of any real analysis, exactly as it is for any other file format.
Why Section Entropy Matters Here Too
A normal code section reads as low-to-moderate entropy - instructions and string tables are structured, not random. A section that reads as close to 8 bits of entropy per byte across its whole length is usually compressed or encrypted, which is exactly what a packer does to hide a binary's real code from static analysis until it unpacks itself in memory at runtime. Comparing entropy across every section, rather than the file as a whole, is what makes this a useful signal here.
What a Code Signature Actually Proves
An Authenticode, ELF, or Mach-O code signature ties a binary to whoever signed it and lets a change to the file be detected after the fact - but a signature only proves the file matches what was signed, not that the signer is trustworthy or that the certificate chain is currently valid. This tool reports whether a signature is present and who it names, never whether it verifies - a real verification needs to walk a live certificate chain against a trust store, which happens outside the browser sandbox this tool runs in.
Why the Compile Timestamp Is Worth Reading
A PE file's header records the exact moment the linker produced it, and while this value can be forged or zeroed by a deliberately evasive build, most ordinary binaries carry it unmodified. A timestamp far in the future, sitting at the Unix epoch, or wildly inconsistent with a file's other metadata is a small but genuine signal that something about the build process was not what it appears to be.
Imphash and the Rich Header Hash
Two samples rebuilt from the same source code rarely share a SHA-256, but they usually share an import hash - the MD5 of every imported library and function in table order - and a Rich header hash, the MD5 of the undocumented block in which the Microsoft linker records every compiler and tool version that produced the file. Neither proves two files are the same; both are pivots for finding the rest of a family in VirusTotal, MalwareBazaar or YARA. This tool computes both the way pefile does, including its ordinal-name tables for Winsock and OLE Automation imports, so the values can be searched as-is.
What an Overlay Is
An executable's headers describe exactly how many bytes the loader maps; anything after that is an overlay that the operating system never loads. Installers and self-extracting archives keep their payload there, a signed file keeps its Authenticode certificate there, and droppers hide a second stage there. Data appended after a valid signature is a known abuse because some verifiers ignore it. The overlay's size and entropy say what kind of data it is; saving it, or opening it in Binary & Archive Forensics, shows what it actually contains.