ELF is to Linux what Mach-O is to macOS and PE/EXE is to Windows. Almost every binary on a modern Linux/Unix system — your shell, your text editor, every command in /usr/bin — is an ELF file. Shared libraries (.so), static archives (.a are wrappers around ELF objects), object files (.o), kernel modules (.ko), and core dumps from crashed processes all use the format.
The ELF header starts with magic bytes `7F 45 4C 46` (the ASCII for "ELF" prefixed with 0x7F). The next bytes encode bit width (32 or 64), endianness (little or big), the machine type (x86-64, ARM, RISC-V, MIPS, PowerPC), and the ELF type — executable, shared object, relocatable, or core dump. Tools like `readelf`, `objdump`, and `file` parse all this to tell you what you're looking at, including which dynamic libraries the binary depends on.
Identifying a file as ELF tells you very little about its safety — ELF is just the wrapper format. The contents could be a trusted system tool, a build artefact you compiled yourself, or an untrusted binary downloaded from the internet. Don't run ELF binaries from sources you don't trust. On most Linux distros, system binaries live in /usr/bin and /usr/lib; manually-installed programs should go in /usr/local/bin to keep them out of the package manager's space.
Technical details
Full Name
ELF Executable
MIME Type
application/x-executable
Developer
Unix System Laboratories (1990s)
Magic Bytes
7F 45 4C 46
Safety
.elf requires caution. ELF is a container format — safety depends entirely on the binary's contents, not the format itself. Don't execute ELF binaries from untrusted sources.
What opens it
readelf (CLI)
FREELinux / Unix
objdump (CLI)
FREELinux / Unix
Ghidra
FREEAll
IDA Pro
Commercial licenseAll
* Inspect ELF headers and sections * Disassemble ELF binaries * Reverse engineering and disassembly
FAQ
Why don't most Linux executables have a file extension?
Unix tradition — file types are determined by content (magic bytes), not by extension. The shell uses the executable bit (`chmod +x`) to decide whether to run a file, and the kernel reads the magic bytes to dispatch the right loader. Extensions are a Windows convention; on Linux they're optional and usually only used for shared libraries (.so), kernel modules (.ko), and convenience suffixes.
How can I tell what an ELF binary depends on?
`ldd path/to/binary` lists the shared libraries the binary needs at runtime. `readelf -d path/to/binary` shows the dynamic section including library names and rpath entries. `file path/to/binary` gives a one-line summary including architecture and whether the binary is statically or dynamically linked.
Is an ELF binary the same on every Linux distro?
Not exactly. The ELF format is universal, but specific binaries depend on specific glibc versions, library paths, and kernel features. A binary compiled on Ubuntu 24 might fail to run on Debian 11 if it links against newer glibc symbols. Static linking (everything compiled into one binary) sidesteps this; AppImage and Flatpak solve it differently.