CS 6V81-05: System Security and Malicious Code Analysis Revealing Internals of Loader Zhiqiang Lin Department of Computer Science University of Texas at Dallas March 28 th, 2012 Common Linux tools to explore object/executable files ar: creates static libraries. objdump: this is the most important binary tool; it can be used to display all the information in an object binary file. strings: list all the printable strings in a binary file. nm: lists the symbols defined in the symbol table of an object file. ldd: lists the shared libraries on which the object binary is dependent. strip: deletes the symbol table information.
ELF Views Split ELF Views - Split ELF Linking View - Important Sections Program Headers ELF Header File Contents Section Headers.interp.dynamic.symtab,.dynsym.strtab,.dynstr.plt.rel.<x>.text.data Requested Dynamic linker Dynamic linking information Symbols (static/dynamic) String tables Procedure linkage table Relocations for section x Code Initialized data 2012/3/24 Zhiqiang Lin, Nanjing University 1 ELF Loading View ELF Loading View - Segment Types Much simpler view, divides executable into Segments INTERP LOAD LOAD DYNAMIC Describes Parts of file to be loaded into memory at run time Locations of important data at run time Segments have: LOAD INTERP DYNAMIC Portion of file to be loaded into memory Pointer to dynamic linker for this executable (.interp section) Pointer to dynamic linking information (.dynamic section) A simple type Requested memory location Permissions (R/W/X) Size (in file and in memory)
ELF Loading View Loading and Executing an ELF Executable Semantics of section table (Linking View) are irrelevant in Loading View Section information can be removed from executable Operating system routines to load executable and begin execution 82 /* 83 * This structure defines the functions that are used to load the binary 84 * formats that linux accepts. 85 */ 86 struct linux_binfmt { 87 struct list_head lh; 88 struct module *module; 89 int (*load_binary)(struct linux_binprm *, struct pt_regs * regs); 90 int (*load_shlib)(struct file *); 91 int (*core_dump)(struct coredump_params *cprm); 92 unsigned long min_coredump; /* minimal dump size */ 93 }; File opened Map LOAD segments into to memory Calls the dynamic linker specified in the INTERP segment, passing information about the executable Dynamic Linker/Loader Handles all of the dynamic/shared library needs of executable Retrieves information from the DYNAMIC segment Loads all required shared libraries into memory Modifies executable such that it can access needed resources in the libraries
The Procedure Linkage Table (PLT) The Procedure Linkage Table The Procedure Linkage Table Stored in the.plt section Allows executables to call functions that aren t present at compile time Shared library functions (e.g printf()) Set of function stubs Relocations point them to real location of the functions Normally relocated lazily Program... printf("hello!\n");... PLT printf() stub libc.so.6 printf() 2012/3/24 Zhiqiang Lin, Nanjing University 14 GOT and PLT PLT and Lazy Binding Global offset table and procedure linkage table are used for shared libraries. All calls within the program to a particular routine are adjusted to be calls to the routine s entry in the PLT. The first time the program calls a routine, the PLT entry calls the run-time linker to resolve the actually address of the routine. After that, the PLT entry jumps directly to the actual address. So, after the first call, the cost of using the PLT is a single indirect jump at a procedure call and nothing at return.
PLT Details Fig. PLT Structure Code The first entry in the PLT, which is called PLT0, is special code to call the dynamic linker. At load time, the dynamically linker automatically places two values in the GOT. At GOT+4, it puts a code that identifies the particular library. At GOT+8, it puts the address of the dynamic linker s symbol resolution routine. The rest of PLT entries, which we call PLTn, each starts with an indirect jump through a GOT entry that is initially set to point to the push instructions in the PLT entry that follows the jmp. Summary NAME ld.so/ld-linux.so - dynamic linker/loader DESCRIPTION ld.so loads the shared libraries needed by a program, prepares the program to run, and then runs it. Unless explicitly specified via the -static option to ld during compilation, all Linux programs are incomplete and require further linking at run time. The necessary shared libraries needed by the program are searched for in the following order: Using the environment variable LD_LIBRARY_PATH Except if the executable is a setuid/setgid binary, in which case it is ignored. From the cache file /etc/ld.so.cache which contains a compiled list of candidate libraries previously found in the augmented library path. In the default path /lib, and then /usr/lib.
References http://www.linuxjournal.com/article/6463 http://netwinder.osuosl.org/users/p/patb/ public_html/elf_relocs.html http://en.wikipedia.org/wiki/linker_(computing) Linker and Loader http://v2.cache7.c.bigcache.googleapis.com/ books.lihui.org/cs2/linkers_and_loaders.pdf