ec2-13-59-218-147.us-east-2.compute.amazonaws.com | ToothyWiki | Binutils | RecentChanges | Login | Webcomic
Objdump is binutils' binary analysis tool. It basically wraps the functionality exposed by libbfd.
For Binaries and Libraries, there is functionality to:
- Display the top level information, including architecture and type (-f)
- List the code sections, their offsets and types (-h)
- Show the ELF specific code layout, dependent libraries and versions (-p)
- Display the dynamic/internal symbol tables (-T/-t)
- Show the code dynamic/internal relocation points and their targets (-R/-r)
- Disassemble code in EXEC sections (-d)
Interpretation of data:
The file "target" is a identifier of the form <file type>-<arch major>-<arch minor> describing the file format. This information is displayed whenever objdump successfully loads and identifies a binary file as one that it can interpret.
A common example is elf64-x86-64, representing an executable file in the standard "64-bit Executable and Linking Format" file format, containing code for the 64-bit version of the x86 processor architecture.
File Headers
The file headers contain the following information (ELF file format):
- Supported processor architecture and subtype (e.g: i386:x86-64)
- Content descriptor flags (see bfd.h):
- EXEC_P - File can be directly executed (not a library)
- DYNAMIC - File has library functions
- HAS_SYMS - File has symbols (requires linking before direct execution)
- D_PAGED - File can be mmapped directly into process space
- Location in address space where the code should be loaded (start address)
Code Sections
The code sections are direct file offsets into the binary file. Objdump shows:
- The section index (starts at 0 and increments)
- The section name (for example .text an .data in ELF)
- The size of the section in bytes
- The address that the section will be at if loaded in virtual memory at the start address (VMA)
- The address that the section will be at if loaded in a ROM location (LMA - rarely used)
- Offset into file, usually (VMA - start address)
- Data alignment properties (2**4, 2**2, 2**0 for 32-bit, 16-bit and unaligned)
- Flags describing section contents (see bfd.h):
- CODE - executable binary
- DATA - data for access by binary
- READONLY - section should be placed in non-writable memory location
- CONTENTS - section is not empty space, and needs to be loaded from disk
- ALLOC - section needs to be loaded into process memory for execution
- LOAD - needed for standard usage of the file
Program headers, Dependencies and Versions
See elf/common.h
The program header describes how the address space of a loaded should be structured. Much of this information is contained in the Code Sections header. The following is provided:
- Section type
- PHDR Program header (the information being displayed)
- INTERP Program to use to run the binary (usually /lib/ld-linux.so.2)
- LOAD Section of code or data
- DYNAMIC Section containing the dependent binaries and functions for the linker
- EH_FRAME Data to help generate stack traces
- RELRO Read-only memory (after relocation in memory)
- STACK Access permissions for the stack (effectively: is the stack in executable memory?)
- NOTE Extra information
- Offset Offset in file
- vaddr Offset when loaded into memory
- paddr Offset when loaded into ROM
- silesz Size on disk
- memsz Size when loaded in memory
- alignment in powers of 2 (e.g. 2**21 for 4k page boundary)
- permissions mmu settings for section (rwx)
The dynamic section lists the dependent libraries (NEEDED), the name of this library (SONAME), and the locations of various entry functions required by the linker (INIT, FINI, etc).
If this is a dynamic library, the private headers, may export a list of version tags that the library is compatible with (these become linker symbols). If the binary requires particular version of dependent libraries, these are also listed here.
Dynamic and Internal Symbol tables
The Dynamic symbol table is a list of the externally linked symbols, while the internal symbol table contains all symbols. Symbols that are defined in the binary have offsets
- Address Location within the binary (or zero if requires linking to an external module)
- Flags
- lg Displays whether the symbol is local or global
- w Weak linked symbol (e.g. a default implementation of a function)
- D Symbol is in the dynamic table
- FO Display whether the symbol is a function or an object
- Section containing the symbol (*UND* for externally linked, *ABS* for absolute position within file)
- Symbol Alignment or Size
- Symbol name and optionally the version
Relocation tables
The relocation table contains information used by the linker to move the executable around in memory. So:
- Address of relocation code point
- Operation required to apply the relocation (e.g. R_X86_64_JUMP_SLOT is a call xxx; command)
- Symbol to link to (or a relative jump point within the binary *ABS* +/- offset)
Disassembly options
Show the contents of the binary as interpreted in GNU assembly language. This is done irrespective of whether the section is executable...