Chapter 03
FILE FORMAT
Contents
◼ Background
◼ ELF
◼ PE
◼ Summary
Why learning the executable file format
◼ Machine essentially run binary code
◼ Good people
◼ Reverse Engineering
◼ Malicious Code Analysis
◼ File patching (vá tệp)
◼ File Carving (khắc tệp)
◼ Bad people
◼ Reverse Engineering
◼ Developing Exploits
◼ Developing virus
◼ Secret stealing
ELF (Executable and Linkable Format)
◼ The [Link] format served the Unix community well for over 10 years.
◼ However, to better support cross-compilation, dynamic linking,
initializer/finalizer and so on, [Link] has been replaced by the ELF file
format
◼ ELF
◼ Standard binary format for object files
◼ Derived from AT&T System V Unix, now supported by UNIX/Linux
◼ One unified format for
◼ relocatable object files (.o)
◼ executable object files
◼ shared object files (.so)
ELF File Types
◼ ELF defines the format of executable binary files. There are three
different types
◼ Relocatable: Created by compilers or assemblers. Need to be processed by
the linker before running.
◼ Executable: Have all relocation done and all symbol resolved except
perhaps shared library symbols that must be resolved at run time
◼ Shared object: Shared library containing both symbol information for the
linker and directly runnable code for run time
ELF Structure
◼ ELF files have a dual nature:
◼ Compilers, assemblers, and linkers treat the file as a set of logical sections
described by a section header table
◼ The system loader treats the file as a set of segments described by a
program header table.
ELF object file format
◼ Elf header
◼ magic number, type (.o, exec, .so), machine, byte
ordering, etc.
◼ Program header table
◼ page size, virtual addresses for memory segments
(sections), segment sizes.
◼ .text section
◼ Code
◼ .data section
◼ initialized (static) data
◼ .bss section
◼ uninitialized (static) data
◼ “Block Started by Symbol”
◼ “Better Save Space”
◼ has section header but occupies no spac
ELF object file format
◼ .symtab section
◼ symbol table
◼ procedure and static variable names
◼ section names
◼ .[Link] section
◼ relocation info for .text section
◼ addresses of instructions that will need to be
modified in the executable
◼ instructions for modifying.
◼ .[Link] section
◼ relocation info for .data section
◼ addresses of pointer data that will need to be
modified in the merged executable
◼ .debug section
◼ info for symbolic debugging (gcc -g)
An example
ELF Header
◼ The Elf header is always at offset zero of the file.
◼ The offset of program header table (PHT) and the section
header table (SHT) in the file are defined in the ELF header. Any
positions for PHT and SHT will be ok.
◼ The header is decodable even on machines with a different byte
order from the file’s target architecture.
◼ After reading class and byte order fields, the rest fields in the elf header
can be decoded.
◼ The elf format can support two different address sizes:
◼ 32 bits
◼ 64 bits
Example
Relocatable Files
◼ A relocatable or shared object file is a collection of sections.
◼ Each section contains a single type of information, such as
program code, read-only data,or read/write data,relocation
entries,or symbols.
◼ Every symbol’s address is defined relative to a section.
◼ Therefore, a procedure’s entry point is relative to the program code
section that contains that procedure’s code
Example
Segments vs. Sections
◼ A single segment usually consist of several sections.
◼ E.g., a loadable read-only segment could contain sections for executable
code, read-only data, and symbols for the dynamic linker.
◼ Relocatable files have section header tables. Executable files have
program header tables. Shared object files have both.
◼ Sections are intended for further processing by a linker, while the
segments are intended to be mapped into memory
Various Sections
◼ .text:
◼ This section holds executable instructions of a program.
◼ Type: PROGBITS
◼ Flags: ALLOC + EXECINSTR
◼ .data:
◼ This section holds initialized data that contributes to the program’s image.
◼ Type: PROGBITS
◼ Flags: ALLOC + WRITE
◼ .got:
◼ This section holds the global offset table.
◼ Type: PROGBIT
◼ .plt:
◼ This section holds the procedure linkage table.
◼ Type: PROGBIT
String table
◼ String table sections hold null-terminated character sequences,
commonly called strings.
◼ The object file uses these strings to represent symbol and section
names.
◼ We use an index into the string table section to reference a string
Symbol table
◼ An object file’s symbol table holds information needed to locate
and relocate a program’s symbolic definition and references.
◼ A symbol table index is a subscript into this array.
PE
◼ PE stands for Portable Executable
◼ Microsoft introduced PE in Windows NT 3.1
◼ It originates from Unix COFF
◼ Features dynamic linking, symbol exporting/ importing
◼ Can contain Intel, Alpha, MIPS and even .NET MSIL binary code
Complete Picture of PE
File Headers: MZ header
File Headers: PE Header
File Headers: File Header
File Headers: Optional Header
File Headers: Optional Header
File Headers: Image Directory
File Headers: Section Header
PE Image Loading
Memory Layout
Import Symbols
◼ Symbols (functions/data) can be imported from external DLLs
◼ The loader will load external DLLs automatically
◼ All the dependencies are loaded as well
◼ DLLs will be loaded only once
◼ External addresses are written to the Import Address Table (IAT)
◼ IAT is most often located in the .idata section
DLL Dependency
Import Symbols
◼ Each DLL has one IMAGE_IMPORT_DESCRIPTOR
◼ The descriptor points to two parallel lists of symbols to import
◼ Import Address Table (IAT)
◼ Import Name Table (INT)
◼ The primary list is overwritten by the loader, the second one is not
◼ Executables can be pre-bound to DLLs to speed up loading
◼ Symbols can be imported by ASCII name or ordinal
Imports
Import Descriptors
Exporting Symbols
◼ Symbols can be exported with ordinals, names or both
◼ Ordinals are simple index numbers of symbols
◼ Name is a full ASCII name of the exported symbol
◼ Exports are described by three simple lists
◼ List of ordinals
◼ List of symbol addresses
◼ List of symbol names
◼ Exports can be forwarded to another DLL
◼ Example: [Link]
Resources
◼ Resources in PE are similar to an archive
◼ Resource files can be organised into directory trees
◼ The data structure is quite complex but there are tools to handle it
◼ Most common resources:
◼ Icons
◼ Version information
◼ GUI resources
Base Relocation
Base Relocation
◼ Sometimes a DLL can not be loaded to its preferred address
◼ When rebasing, the loader has to adjust all hardcoded addresses
◼ Relocations are done in 4KiB blocks (page size on x86)
◼ Each relocation entry gives a type and points to a location
◼ The loader calculates the base address difference
◼ The offsets are adjusted according to the difference
Summary
◼ Binary executable file format is important for (many reasons)
◼ ELF (executable, shared, compiled)
◼ PE (executable, DLL)
◼ ELF/PE has its own structure and definition