Every ELF (Executable and Linkable Format) file starts with a header. Think of this as the Passport of the program. Before the Linux kernel even thinks about executing a single line of your assembly code, it reads this header to answer three vital questions:

1. Is this actually a program I can run? (The Magic Number)
2. What kind of CPU is this built for? (The Architecture)
3. Where exactly does the code start? (The Entry Point)

0x01: The “Magic” bytes

The first 4 bytes of every ELF file are constant. They are the file’s “signature.”

• 7F 45 4C 46 If you convert these to ASCII, they spell out: (DEL) E L F.

If the kernel sees anything else at the very start of a file, it will refuse to run it, throwing an “Exec format error.”

0x02: The Entry Point (e_entry)

This is the most important memory address for a reverse engineer. It is the exact coordinate where the CPU will begin executing instructions.

• In our previous assembly code, this address corresponds to the label _start.
• If a malware author wants to hide their code, they might change this address to point to a “packer” or a “decrypter” instead of the actual malicious logic.

0x03: The Machine Field (e_machine)

This field identifies the target CPU architecture.

• 0x3E: x86-64 (Intel/AMD)
• 0xB7: AArch64 (ARM 64-bit)

If you try to run an ARM64 binary on an Intel processor, the kernel reads this header, sees 0xB7, compares it to the host CPU, and immediately terminates the process because the instruction sets are incompatible.

0x04: Interactive Lab (The Header Analyst)

Your mission is to perform “Manual Reconnaissance” on a raw hex dump. Identify the architecture and the entry point of the binary.

0x05: Mission Task

Current Objective: Use the readelf -h <filename> command on your Linux system.

Challenge: Run it on the example.so binary we created earlier. Find the “Entry point address” and the “Machine” field. Does the output match what you expected from your assembly code?