According to elf.h:
#define EI_NIDENT (16)
typedef struct
{
unsigned char e_ident[EI_NIDENT]; /* Magic number and other info */
Elf32_Half e_type; /* Object file type */
Elf32_Half e_machine; /* Architecture */
Elf32_Word e_version; /* Object file version */
Elf32_Addr e_entry; /* Entry point virtual address */
Elf32_Off e_phoff; /* Program header table file offset */
Elf32_Off e_shoff; /* Section header table file offset */
Elf32_Word e_flags; /* Processor-specific flags */
Elf32_Half e_ehsize; /* ELF header size in bytes */
Elf32_Half e_phentsize; /* Program header table entry size */
Elf32_Half e_phnum; /* Program header table entry count */
Elf32_Half e_shentsize; /* Section header table entry size */
Elf32_Half e_shnum; /* Section header table entry count */
Elf32_Half e_shstrndx; /* Section header string table index */
} Elf32_Ehdr;
Sizes for ELF32_* (in bytes):
Word: 4
Half: 2
Off: 4
Addr: 4
Looking at a regular binary like ls for example:
$ dd if=/bin/ls bs=52 count=1|xxd
1+0 records in
1+0 records out
52 bytes (52 B) copied, 3.6108e-05 s, 1.4 MB/s
0000000: 7f45 4c46 0101 0100 0000 0000 0000 0000 .ELF............
0000010: 0200 0300 0100 0000 0099 0408 3400 0000 ............4...
0000020: ec7f 0100 0000 0000 3400 2000 0800 2800 ........4. ...(.
0000030: 2000 1f00 ...
I'm using the ELF manual to analyze this.
The first line (16 bytes) is the (e_ident) value which consists of:
The ``magic'' value for the first four characters - 7f45 4c46
The file class (EI_CLASS) - 0x1 (ELF32CLASS)
Data encoding (EI_DATA) - 0x1 (ELFDATA2LSB) little endian
File version (EI_VERSION) - 0x1 current
Start of padded bytes (EI_PAD)
On the second line (e_type) 0x2 tells us it is an executable file
(e_machine) value 0x3 tells us that this was compiled on Intel Architecture
(e_version) value 0x1 tells us it is current
(e_entry) virtual address to which to control is given is 0x8049900
(e_phoff) Program headers start at offset 0x34
On the third line 0x17fec is the section header offset (e_shoff)
(e_flags) value 0x0 tells us that no flags are set
(e_ehsize) value of 0x34 tells that the header is of size 52 bytes decimal
(e_phentsize) value of 0x20 tells that one entry in the program header table size is 32 bytes
(e_phnum) value of 0x8 tells us the number of entries in the program header table is 8
(e_shentsize) value of 0x28 tells us the size of one entry in the section header table is 40 bytes
On the fourth line
(e_shnum) value of 0x20 tells us that number of entries in the section header table is 32
(e_shstrndx) value of 0x1f holds the section header table index of the entry associated with the section name string table
So what does /proc/kcore look like?
# dd if=/proc/kcore bs=52 count=1|xxd
1+0 records in
1+0 records out
52 bytes (52 B) copied, 3.9321e-05 s, 1.3 MB/s
0000000: 7f45 4c46 0101 0100 0000 0000 0000 0000 .ELF............
0000010: 0400 0300 0100 0000 0000 0000 3400 0000 ............4...
0000020: 0000 0000 0000 0000 3400 2000 0300 0000 ........4. .....
0000030: 0000 0000 ....
The first line is the same as above.
The second line:
(e_type) 0x4 tells us it is a core file (ET_CORE) *
(e_machine) value 0x3 tells us that this was compiled on Intel Architecture
(e_version) value 0x1 tells us it is current
(e_entry) virtual address to which to control is given is 0x0
(e_phoff) program headers start at offset 0x34
* this is useful to know if we are dealing with a core file...
In the third line:
(e_shoff) value is 0x0 letting us know there is no section header offset
(e_flags) value 0x0 tells us that no flags are set
(e_ehsize) value of 0x34 tells that the elf header is of size 52 bytes decimal
(e_phentsize) value of 0x20 tells that one entry in the program header table size is 32 bytes
(e_phnum) value of 0x3 tells us the number of entries in the program header table is 3
(e_shentsize) value of 0x0 tells us that there is no section header
The fourth line values are all 0x0
To make your life easier here is a C program that will extract all of that information for you :-) You must be root to run it.
Note: I know I could have done this a bit more elegantly, but decided against that...