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.
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.
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.
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.