ELF, Not Data: Identifying a Linux Binary by Its 7F 45 4C 46 Header
The challenge
A suspicious file named blob.dat was left in /tmp on a Linux server. Open it in the hex viewer, compare the first bytes to the reference signatures, and type the real file type.
What you'll learn
- Recognise the ELF signature 7F 45 4C 46 and read 'ELF' from the ASCII bytes
- Interpret the class and endianness bytes (64-bit, little-endian) that follow
- Read the e_type and e_machine fields to confirm an x86-64 executable
- Explain why a .dat file with an ELF header is a malware red flag
- Distinguish ELF from PE/MZ, Mach-O, and Java class signatures
Skills tested
Prerequisites
- Basic awareness that Linux executables use the ELF format
- Comfort reading hexadecimal byte values
How it works
On Linux, native executables, shared libraries, and core dumps all use the ELF (Executable and Linkable Format) container. Every ELF file begins with the four-byte signature 7F 45 4C 46. The leading 0x7F is a deliberately non-printable byte (it breaks tools that try to treat the file as text), and the next three bytes are the ASCII letters ELF.
The bytes right after the magic are the ELF identification header and confirm the diagnosis. 02 sets the class to 64-bit (a 01 would be 32-bit), 01 sets the data encoding to little-endian, and 01 is the ELF version. A little further in, the e_type field 02 00 marks the file as an executable and e_machine 3E 00 identifies the x86-64 architecture.
A file named blob.dat sitting in /tmp with this header is a textbook sign of dropped malware: the harmless-looking extension hides a runnable binary. The reference list contrasts ELF with the other major executable formats - PE/MZ (4D 5A, 'MZ') for Windows, Mach-O (FE ED FA CE) for macOS, and Java class files (CA FE BA BE) - none of which match.
Common mistakes
- Treating .dat as opaque data. The extension is intentionally vague, but the header is a concrete ELF signature.
- Stumbling on the 7F byte. It is non-printable by design; the readable
ELFfollows immediately. - Confusing ELF with a Java class. Java class files start
CA FE BA BE('cafebabe'), which is unrelated to7F 45 4C 46. - Guessing the OS from the filename. The format - not the name or location - tells you it is a Linux binary.
How to defend against it
Linux defenders should classify dropped files by content and watch the directories malware favours.
- Monitor world-writable paths like
/tmp,/dev/shm, and/var/tmpfor new files whose magic bytes are ELF, regardless of extension. - Mount those paths
noexecwhere feasible so a dropped ELF cannot be run directly. - Use content-based file typing in your EDR and alert on extension-vs-type mismatches.
- Baseline expected binaries and flag unsigned or unknown ELF files appearing outside package-managed locations.