ELF info
Read an ELF binary's header and section table: class, architecture, entry point, sections. No disassembly.
Runs on your device. The file is never uploaded.
ELF info parses the front of a Linux executable and prints its class, endianness, object type, machine, version and entry point in hex. The program and section header tables follow, then each section's name, numeric type and byte size. It performs no disassembly, reads no symbol table and lists no relocations, so it reports layout rather than behaviour.
Questions
What does it report?
The fields readelf prints for the header and the section table, and nothing it has to infer: class as ELF32 or ELF64, endianness, object type, machine, version, entry point in hex, the count, entry size and file offset of the program headers and section headers, and the ELF header size. Then each section with its name, numeric type and size.
Does it disassemble the binary?
No. There is no disassembly, no symbol table, no relocation listing and no dynamic linking information. It reads the header and walks the section header table, so it answers what this binary is and how it is laid out, not what its code does. The section listing gives you names and sizes, which is enough to spot a packed or stripped binary by what is missing.
Why does it say my file is not an ELF file?
Because the first four bytes are not 7f 45 4c 46, and the message is "not an ELF file (missing \x7fELF magic)". A file with the magic present but too few bytes to read further gets a different message calling it truncated, because a damaged ELF and a non-ELF file are separate findings and telling you the wrong one about a real ELF would be a bug in a tool whose job is accurate reporting on damaged files.
Why did it refuse to walk the section table?
Because e_shentsize was not the size the ABI fixes it at, 64 bytes for ELF64 and 40 for ELF32. When it disagrees, the output says the value is malformed or crafted and refuses to walk rather than reading struct fields at offsets that would then be meaningless. A crafted small entry size with a huge section count is a known way to make a naive parser walk off the end of a buffer.
What does it mean when sections run past the end of the file?
That the header describes more section data than the file contains, and the output reports the declared count, entry size and offset next to the real file size, calling it truncated or malformed. You see this on partial recoveries, on carved segments and on deliberately corrupted binaries. The header fields above that line are still readable and still useful.
What machine names does it know?
x86, MIPS, PowerPC, ARM, x86-64, AArch64 and RISC-V. Anything else prints as unknown with the raw e_machine value in hex, so you can look it up. Object types are named the same way: ET_REL for relocatable, ET_EXEC for executable, ET_DYN for a shared object or PIE, and ET_CORE for a core dump.