Detailed Analysis of the ELF File Format (Part 2)

ELF file format is the foundation for native hooking and reverse engineering; understanding it reveals linker behavior and allows inspection of .so files.

ELF consists of three main parts: the ELF Header, the Section Header Table/Program Header Table, and the Sections/Segments.

The ELF Header, fixed at 52 bytes, includes fields like e_ident, e_type, e_machine, e_version, e_entry, e_phoff, e_shoff, e_phentsize, e_phnum, e_shentsize, e_shnum, and e_shstrndx, which identify the file type, architecture, and locate the header tables.

The Section Header Table contains multiple 40‑byte Section Headers that specify each section’s name, type, offset, and size; sections such as .dynsym, .dynstr, and .shstrtab store symbols and string tables.

Symbol Table entries are 16 bytes each, with fields like st_name (index into .dynstr), st_info (type and binding), st_shndx (section index), and st_value (offset), enabling lookup of function symbols.

The Program Header Table lists Segment Headers (e.g., LOAD) that describe how segments are mapped into memory, including virtual addresses.

Using Android 7.0’s libmedia.so as an example, the article shows how to examine the ELF Header with readelf -h , view the Section Header Table with readelf -S , and locate the function _ZN7android11AudioRecord4readEPvjb by parsing the headers, finding the relevant symbol in .dynsym, and adjusting for the segment’s virtual address.

Verification is performed with objdump -d to disassemble libmedia.so and by opening the binary at the calculated offset to confirm the function’s instructions.

Understanding the ELF format thus aids in implementing native hooks, as it clarifies how dlopen and dlsym resolve function addresses.