Email Password Remember me?  Lost your password?

• Download source - 4 Kb

TABLE OF CONTENTS

1. Introduction
2. Prerequisites
3. Brief introduction to the ELF format
   • 3.1 Historical notes
   • 3.2 ELF structure
     • 3.2.1 The ELF header
     • 3.2.2 Program header and segments
     • 3.2.3 The section header
     • 3.2.4 The string table
     • 3.2.5 Let's write some code...
     • 3.2.6 The symbol table
     • 3.2.7 Relocation table
     • 3.2.8 Dynamic section
     • 3.2.9 Hash tables
     • 3.2.10 Let's write more code...
4. ELF loading
   • 4.1 Program headers
   • 4.2 Dynamic section
   • 4.3 The PLT
5. Building up our lab...
6. PLT: a practical example
7. Conclusions
8. References

In the last few weeks I've found myself playing around with Linux for various reasons, so the first thing that I thought was to apply some of the well known Win32-methods to this operating system, most of them from the point of view of a reverser.
This is the first part of a two-part article which will deal with code injection under Linux. The technique presented here resembles a well known win32 technique: inject a DLL (shared object on Linux and UNIX-like systems) into a running process, thus being able to hook some of the process' imported functions. There are two ways which may lead us to code injection: 1) using the LD_PRELOAD method (this requires to restart the process in which we are injecting our shared object) 2) injecting a stub into the target process which loads the required library. Of course as you may have guessed, the second way requires the presence of "libdl" in the address space of the target process, but that's a reasonable requirement, since most modern softwares for Linux and UNIXes are quite complex, and most of them will have libdl mapped into their address space. We will use the second method, since our goal is to inject a shared object into a running process.
Regarding the hook technique, we will use PLT redirection, which is a well known technique under Linux/UNIX to hook functions imported from other libraries in a simple and elegant way.

This first part will teach you the basics of the ELF format (the standard object format on most Linux and UNIX-like operating systems) with some code examples, so it will be an introduction to the next part, which will show you the actual technique, but this one is a required reading, since it will build up the required concepts.

Before moving further down the article it's best that you take a look at the ELF manuals. They are a required reading to understand most of what I'm writing, I'll give you just a brief introduction to the ELF format, but there so much to write about it that we might forget our goal with this article (which IS NOT an article about the ELF format, but it is about shared object injection). In various parts of the text I will recall the manuals, so let's see "how" you should read them: you have to download two manuals, the first is the general one, the second is the x86-specific one. If you take a look at the general one, you will see that it miss some parts, which you will find in the specific one (there is one additional ELF manual for each platform which supports the ELF format), missing parts starts with a marker, so you will notice them.

You should have a good knowledge of the C programming language and you should know how to use gcc and gdb. A minimal knowledge of x86 assembly language is required. This is the reference system:

• xubuntu 8.10 with kernel 2.6.27-generic
• gcc 4.3.2
• GNU gdb 6.8-debian
• GNU readelf (GNU Binutils for Ubuntu) 2.18.93.20081009
• GNU objdump (GNU Binutils for Ubuntu) 2.18.93.20081009

In this chapter the principal aspects of the ELF format will be covered from a programmer's point of view. This chapter will not be a raw copy of the ELF manuals, but it will just introduce you to some aspects of the format, so you ARE REQUIRED to read the manuals. This chapter will deal with the various structures of the ELF format and how to read them. Dynamic linking will be demanded to the next chapter.

The ELF format (which is an acronym for Executable and Linking Format) is one of the many formats that describes the structure of an object file (a file which contains compiled code), from a logical and/or physical point of view. Object file formats similar to ELF includes: the PE format (Portable Executable, used mainly on Microsoft platforms), the Mach-O (used on OSX), the COFF and the a.out. From an historical point of view, the COFF and the a.out where very influential for the development of the the newer formats, such as the PE (which derives from COFF) and the ELF (which takes some of its aspects from the a.out format). As you may guess from the name, the ELF format allows both executable and libraries to be described

The ELF format was introduced to replace the a.out and COFF formats on UNIX systems, becoming a standard as of 1999. Today most non-Microsoft platforms uses the ELF format, being well suited to adapt to most platforms, moreover the "ld" linker can be instructed (through the use of custom ld-scripts) to build custom ELF files, which can meet almost every requirement you may need. Examples of non-UNIX platforms using the ELF formats inclludes: PSP, PS2, PS3, Wii, Dreamcast, BeOS, Haiku, AmigaOS, MorphOS, SymbianOS (which actually uses a format derived from ELF). This flexibility comes from the fact that most of the ELF main structures are not bound to a specific platform (e.g. the format (fields and their size) of the relocation structure is independent of the platform used, but its contents are highly platform-dependent).

The ELF structure is similar to others image (which is a synonym for object file) formats: it has an header, followed by sections which decribes the content of various segments of memory. In the following paragraphs we will make use of the "readelf" utility on a test executable, namely "/bin/ls" (which you should have in your system...).

Working with a file format, the first thing that comes into mind is its header, which is the most important part of a file. Regarding the ELF format, the header contains the architecture for which the file was built, its endianness (the byte order) which in most of cases is bound to the architecture (there are some exceptions: modern ARMs and PPCs can be set either to big-endian or to little-endian), the number of sections contained in the file, the number of sgments (a single segment contains one or more sections), etc... . Using the C structure syntax (in the same way as the manual) lets take a look at the header:

#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;

• e_ident: allows the identification of the file. It is an array of 16 bytes, and it is the ONLY part of the file which does not depend on byte ordering. The first four bytes are the ELF signature and they holds the following values: {0x7F, 'E', 'L', 'F'}, indexed by the constants EI_MAG0, EI_MAG1, EI_MAG2, EI_MAG3. The next bytes allows to identify the dimensions of the ELF objects (i.e. if we're dealing with a 32bit or 64bit ELF), the byte ordering and other parameters which we don't care about. The header file elf.h defines two constants which indexes the endianness byte and the dimension byte, they are EI_CLASS,EI_DATA. Dealing with an x86 architecture will lead to e_ident[EI_CLASS] = ELFCLASS32 and e_ident[EI_DATA] = ELFDATA2LSB as it will be shown a few paragraphs apart.
• e_entry: this fields holds and address, which is the entry point of the image, that is the first instruction to be executed by the system, once the image has been completely loaded into memory. For executable files, this fields will holds a virtual address (since executable are always loaded at the same base address), for libraries (.so file or shared objects) it will holds a relative virtual address (i.e. a virtual address minus the base address).
• e_phoff: a physical offset from the beginning of the file, which tells were the program header table resides. So to read the program header table, you have just to "lseek" to this offset. A program header describes a segment, which is a collection of sections (described by the section header).
• e_shoff: same as above, but this holds the section header table offset.
• e_phentsize: size of one entry of the program header table.
• e_shentsize: size of one entry of the section header table.
• e_phnum: number of program headers.
• e_shnum: number of section headers.
• e_shstrndx: an index into the section header table, which holds the string table that must be used to get the section names (string tables will be covered a few paragraphs away).

/* Type for a 16-bit quantity.  */
typedef uint16_t Elf32_Half;
typedef uint16_t Elf64_Half;

/* Types for signed and unsigned 32-bit quantities.  */
typedef uint32_t Elf32_Word;
typedef    int32_t  Elf32_Sword;
typedef uint32_t Elf64_Word;
typedef    int32_t  Elf64_Sword;

/* Types for signed and unsigned 64-bit quantities.  */
typedef uint64_t Elf32_Xword;
typedef    int64_t  Elf32_Sxword;
typedef uint64_t Elf64_Xword;
typedef    int64_t  Elf64_Sxword;

/* Type of addresses.  */
typedef uint32_t Elf32_Addr;
typedef uint64_t Elf64_Addr;

/* Type of file offsets.  */
typedef uint32_t Elf32_Off;
typedef uint64_t Elf64_Off;

/* Type for section indices, which are 16-bit quantities.  */
typedef uint16_t Elf32_Section;
typedef uint16_t Elf64_Section;

/* Type for version symbol information.  */
typedef Elf32_Half Elf32_Versym;
typedef Elf64_Half Elf64_Versym;

quake2@quake2-desktop:~$ readelf -h /bin/ls
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8049b20
  Start of program headers:          52 (bytes into file)
  Start of section headers:          95096 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         9
  Size of section headers:           40 (bytes)
  Number of section headers:         28
  Section header string table index: 27

typedef struct
{
  Elf32_Word    p_type;            /* Segment type */
  Elf32_Off    p_offset;        /* Segment file offset */
  Elf32_Addr    p_vaddr;        /* Segment virtual address */
  Elf32_Addr    p_paddr;        /* Segment physical address */
  Elf32_Word    p_filesz;        /* Segment size in file */
  Elf32_Word    p_memsz;        /* Segment size in memory */
  Elf32_Word    p_flags;        /* Segment flags */
  Elf32_Word    p_align;        /* Segment alignment */
} Elf32_Phdr;

• p_type: this field holds the type of the segment. There can be more than one segment of each type (but this is not valid for all types, e.g. there can be only one segment of type PT_DYNAMIC and PT_INTERP). Take a look at the ELF manual for a description of the possible types. Of course each different type of program header holds different kind of informations.
• p_offset: file offset at which the segment begins.
• p_vaddr: in-memory virtual address at which the segment begins.
• p_paddr: in-memory physical address at which the segment begins, this has no meaning on most modern architectures, usually holds the same value of p_vaddr.
• p_filesz: size of the segment in the file (on-disk size), this might be different from memory size (and usually is for text and data sections).
• p_memsz: in-memory size of the segment.
• p_flags: a bit-mask which holds the usual memory protection flags (read,write,execute) take a look at the manual.
• p_align: segment alignment, if this field is not equal to 0 or 1, then p_vaddr % p_align = 0.

quake2@quake2-desktop:~$ readelf -l /bin/ls

Elf file type is EXEC (Executable file)
Entry point 0x8049b20
There are 9 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x00120 0x00120 R E 0x4
  INTERP         0x000154 0x08048154 0x08048154 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x08048000 0x08048000 0x16eb4 0x16eb4 R E 0x1000
  LOAD           0x016ef0 0x0805fef0 0x0805fef0 0x003a0 0x0081c RW  0x1000
  DYNAMIC        0x016f04 0x0805ff04 0x0805ff04 0x000e8 0x000e8 RW  0x4
  NOTE           0x000168 0x08048168 0x08048168 0x00020 0x00020 R   0x4
  GNU_EH_FRAME   0x016dec 0x0805edec 0x0805edec 0x0002c 0x0002c R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
  GNU_RELRO      0x016ef0 0x0805fef0 0x0805fef0 0x00110 0x00110 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn 
          .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .ctors .dtors .jcr .dynamic .got .got.plt .data .bss 
   04     .dynamic 
   05     .note.ABI-tag 
   06     .eh_frame_hdr 
   07     
   08     .ctors .dtors .jcr .dynamic .got 

typedef struct
{
  Elf32_Word    sh_name;        /* Section name (string tbl index) */
  Elf32_Word    sh_type;        /* Section type */
  Elf32_Word    sh_flags;        /* Section flags */
  Elf32_Addr    sh_addr;        /* Section virtual addr at execution */
  Elf32_Off    sh_offset;        /* Section file offset */
  Elf32_Word    sh_size;        /* Section size in bytes */
  Elf32_Word    sh_link;        /* Link to another section */
  Elf32_Word    sh_info;        /* Additional section information */
  Elf32_Word    sh_addralign;        /* Section alignment */
  Elf32_Word    sh_entsize;        /* Entry size if section holds table */
} Elf32_Shdr;

• sh_name: the name of the section, this is an index inside a string table. A string table is a colletion of null terminated strings delimited by null bytes, e.g. "\0name1\0name2\0name3\0\0", the next paragraph will be about them.
• sh_type: section type, there can be more than one section of the same type with a few exceptions (e.g. there can be only one SHT_SYMTAB and only one SHT_DYNSYM). Sections with type SHT_PROGBITS contain actual initialized code/data, the ones with type SHT_NOBITS contains uninitialized data (that does not requires file storage, e.g. the .bss section).
• sh_flags: section flags, a bit-mask with the usual memory protection attributes (read,write,execute).
• sh_addr: virtual address of the section, once the image has been mapped in memory, it will be a virtual address inside a segment.
• sh_offset: the offset from the start of the file at which the section is located, this field is a physical offset.
• sh_size: the physical size of the section in bytes. This might either be the storage space requuired or the actual size once the section is mapped for NOBITS sections.
• sh_link: this is a special field, its contents depends on the section type. For SHT_SYMTAB and SHT_DYNSYM this fields holds a section table index, which gives the section containing the string table with the names of the symbols, take a look at the manual for every other types.
• sh_info: the content of this field depdends on the section type.
• sh_entsize: if a table is contained within the section, then this field gives the size, in bytes, of one entry in the table.

quake2@quake2-desktop:~$ readelf -S /bin/ls
There are 28 section headers, starting at offset 0x17378:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        08048154 000154 000013 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            08048168 000168 000020 00   A  0   0  4
  [ 3] .hash             HASH            08048188 000188 000330 04   A  5   0  4
  [ 4] .gnu.hash         GNU_HASH        080484b8 0004b8 00005c 04   A  5   0  4
  [ 5] .dynsym           DYNSYM          08048514 000514 000690 10   A  6   1  4
  [ 6] .dynstr           STRTAB          08048ba4 000ba4 0004af 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          08049054 001054 0000d2 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         08049128 001128 0000d0 00   A  6   3  4
  [ 9] .rel.dyn          REL             080491f8 0011f8 000028 08   A  5   0  4
  [10] .rel.plt          REL             08049220 001220 0002e8 08   A  5  12  4
  [11] .init             PROGBITS        08049508 001508 000030 00  AX  0   0  4
  [12] .plt              PROGBITS        08049538 001538 0005e0 04  AX  0   0  4
  [13] .text             PROGBITS        08049b20 001b20 01145c 00  AX  0   0 16
  [14] .fini             PROGBITS        0805af7c 012f7c 00001c 00  AX  0   0  4
  [15] .rodata           PROGBITS        0805afa0 012fa0 003e4c 00   A  0   0 32
  [16] .eh_frame_hdr     PROGBITS        0805edec 016dec 00002c 00   A  0   0  4
  [17] .eh_frame         PROGBITS        0805ee18 016e18 00009c 00   A  0   0  4
  [18] .ctors            PROGBITS        0805fef0 016ef0 000008 00  WA  0   0  4
  [19] .dtors            PROGBITS        0805fef8 016ef8 000008 00  WA  0   0  4
  [20] .jcr              PROGBITS        0805ff00 016f00 000004 00  WA  0   0  4
  [21] .dynamic          DYNAMIC         0805ff04 016f04 0000e8 08  WA  6   0  4
  [22] .got              PROGBITS        0805ffec 016fec 000008 04  WA  0   0  4
  [23] .got.plt          PROGBITS        0805fff4 016ff4 000180 04  WA  0   0  4
  [24] .data             PROGBITS        08060180 017180 000110 00  WA  0   0 32
  [25] .bss              NOBITS          080602a0 017290 00046c 00  WA  0   0 32
  [26] .gnu_debuglink    PROGBITS        00000000 017290 000008 00      0   0  1
  [27] .shstrtab         STRTAB          00000000 017298 0000df 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

quake2@quake2-desktop:~$ readelf -x 27 /bin/ls

Hex dump of section '.shstrtab':
  0x00000000 002e7368 73747274 6162002e 696e7465 ..shstrtab..inte
  0x00000010 7270002e 6e6f7465 2e414249 2d746167 rp..note.ABI-tag
  0x00000020 002e676e 752e6861 7368002e 64796e73 ..gnu.hash..dyns
  0x00000030 796d002e 64796e73 7472002e 676e752e ym..dynstr..gnu.
  0x00000040 76657273 696f6e00 2e676e75 2e766572 version..gnu.ver
  0x00000050 73696f6e 5f72002e 72656c2e 64796e00 sion_r..rel.dyn.
  0x00000060 2e72656c 2e706c74 002e696e 6974002e .rel.plt..init..
  0x00000070 74657874 002e6669 6e69002e 726f6461 text..fini..roda
  0x00000080 7461002e 65685f66 72616d65 5f686472 ta..eh_frame_hdr
  0x00000090 002e6568 5f667261 6d65002e 63746f72 ..eh_frame..ctor
  0x000000a0 73002e64 746f7273 002e6a63 72002e64 s..dtors..jcr..d
  0x000000b0 796e616d 6963002e 676f7400 2e676f74 ynamic..got..got
  0x000000c0 2e706c74 002e6461 7461002e 62737300 .plt..data..bss.
  0x000000d0 2e676e75 5f646562 75676c69 6e6b00   .gnu_debuglink.

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <elf.h>

int elf_is_valid(Elf32_Ehdr *elf_hdr)
{
    if( (elf_hdr->e_ident[EI_MAG0] != 0x7F) || 
        (elf_hdr->e_ident[EI_MAG1] != 'E') ||
        (elf_hdr->e_ident[EI_MAG2] != 'L') ||
        (elf_hdr->e_ident[EI_MAG3] != 'F') )
    {
         return 0;
    }

    if(elf_hdr->e_ident[EI_CLASS] != ELFCLASS32)
        return 0;

    if(elf_hdr->e_ident[EI_DATA] != ELFDATA2LSB)
        return 0;

    return 1;
}

static char *elf_types[] = {
    "ET_NONE",
    "ET_REL",
    "ET_EXEC",
    "ET_DYN",
    "ET_CORE",
    "ET_NUM"
};

char *get_elf_type(Elf32_Ehdr *elf_hdr)
{
    if(elf_hdr->e_type > 5)
        return NULL;

    return elf_types[elf_hdr->e_type];
}

int print_elf_header(Elf32_Ehdr *elf_hdr)
{
    char *sz_elf_type = NULL;

    if(!elf_hdr)
        return 0;

    printf("ELF header information\n");

    sz_elf_type = get_elf_type(elf_hdr);
    if(sz_elf_type)
        printf("- Type: %s\n", sz_elf_type);
    else
        printf("- Type: %04x\n", elf_hdr->e_type);

    printf("- Version: %d\n", elf_hdr->e_version);
    printf("- Entrypoint: 0x%08x\n", elf_hdr->e_entry);
    printf("- Program header table offset: 0x%08x\n", elf_hdr->e_phoff);
    printf("- Section header table offset: 0x%08x\n", elf_hdr->e_shoff);
    printf("- Flags: 0x%08x\n", elf_hdr->e_flags);
    printf("- ELF header size: %d\n", elf_hdr->e_ehsize);
    printf("- Program header size: %d\n", elf_hdr->e_phentsize);
    printf("- Program header entries: %d\n", elf_hdr->e_phnum);
    printf("- Section header size: %d\n", elf_hdr->e_shentsize);
    printf("- Section header entries: %d\n", elf_hdr->e_shnum);
    printf("- Section string table index: %d\n", elf_hdr->e_shstrndx);

    return 1;
}

int main(int argc, char *argv[])
{
    int fd_elf = -1;
    u_char *p_base = NULL;
    struct stat elf_stat;
    Elf32_Ehdr *p_ehdr = NULL;

    if(argc < 2)
    {
        printf("Usage: %s \n", argv[0]);
        return 1;
    }

    fd_elf = open(argv[1], O_RDONLY);
    if(fd_elf == -1)
    {
        fprintf(stderr, "Could not open %s: %s\n", argv[1], strerror(errno));
        return 1;
    }

    if(fstat(fd_elf, &elf_stat) == -1)
    {
        fprintf(stderr, "Could not stat %s: %s\n", argv[1], strerror(errno));
        close(fd_elf);
        return 1;
    }

    p_base = (u_char *)calloc(sizeof(u_char), elf_stat.st_size);
    if(!p_base)
    {
        fprintf(stderr, "Not enough memory\n");
        close(fd_elf);
        return 1;
    }

    if(read(fd_elf, p_base, elf_stat.st_size) != elf_stat.st_size)
    {
        fprintf(stderr, "Error while reading file: %s\n", strerror(errno));
        free(p_base);
        close(fd_elf);
        return 1;
    }
    
    close(fd_elf);

    p_ehdr = (Elf32_Ehdr *)p_base;
    if(elf_is_valid(p_ehdr))
        print_elf_header(p_ehdr);
    else
        fprintf(stderr, "Invalid ELF file\n");

    free(p_base);
    return 0;
}

Let's see another source, which this time will show also the section header table and the program header table:

static char *ptypes[] = {
        "PT_NULL",
        "PT_LOAD",
        "PT_DYNAMIC",
        "PT_INTERP",
        "PT_NOTE",
        "PT_SHLIB",
        "PT_PHDR"
};

int print_program_header(Elf32_Phdr *phdr, uint index)
{
    if(!phdr)
        return 0;

    printf("Program header %d\n", index);
    if(phdr->p_type <= 6)
        printf("- Type: %s\n", ptypes[phdr->p_type]);
    else
        printf("- Type: %08x\n", phdr->p_type);

    printf("- Offset: %08x\n", phdr->p_offset);
    printf("- Virtual Address: %08x\n", phdr->p_vaddr);
    printf("- Physical Address: %08x\n", phdr->p_paddr);
    printf("- File size: %d\n", phdr->p_filesz);
    printf("- Memory size: %d\n", phdr->p_memsz);
    printf("- Flags: %08x\n", phdr->p_flags);
    printf("- Alignment: %08x\n", phdr->p_align);
}

static char *stypes[] = {
        "SHT_NULL",
        "SHT_PROGBITS",
        "SHT_SYMTAB",
        "SHT_STRTAB",
        "SHT_RELA",
        "SHT_HASH",
        "SHT_DYNAMIC",
        "SHT_NOTE",
        "SHT_NOBITS",
        "SHT_REL",
        "SHT_SHLIB",
        "SHT_DYNSYM"
};

int print_section_header(Elf32_Shdr *shdr, uint index, char *strtable)
{
    if(!shdr)
        return 0;

    printf("Section header: %d\n", index);
    printf("- Name index: %d\n", shdr->sh_name);
    
    //as you can see, we're using sh_name as an index into the string table
    printf("- Name: %s\n", strtable + shdr->sh_name);
    if(shdr->sh_type <= 11)
        printf("- Type: %s\n", stypes[shdr->sh_type]);
    else
        printf("- Type: %04x\n", shdr->sh_type);
    printf("- Flags: %08x\n", shdr->sh_flags);
    printf("- Address: %08x\n", shdr->sh_addr);
    printf("- Offset: %08x\n", shdr->sh_offset);
    printf("- Size: %08x\n", shdr->sh_size);
    printf("- Link %08x\n", shdr->sh_link);
    printf("- Info: %08x\n", shdr->sh_info);
    printf("- Address alignment: %08x\n", shdr->sh_addralign);
    printf("- Entry size: %08x\n", shdr->sh_entsize);

}

int main(int argc, char *argv[])
{
    int fd_elf = -1;
    u_char *p_base = NULL;
    char *p_strtable = NULL;
    struct stat elf_stat;
    Elf32_Ehdr *p_ehdr = NULL;
    Elf32_Phdr *p_phdr = NULL;
    Elf32_Shdr *p_shdr = NULL;
    int i;

    if(argc < 2)
    {
        printf("Usage: %s </path/to/file>\n", argv[0]);
        return 1;
    }

    fd_elf = open(argv[1], O_RDONLY);
    if(fd_elf == -1)
    {
        fprintf(stderr, "Could not open %s: %s\n", argv[1], strerror(errno));
        return 1;
    }

    if(fstat(fd_elf, &elf_stat) == -1)
    {
        fprintf(stderr, "Could not stat %s: %s\n", argv[1], strerror(errno));
        close(fd_elf);
        return 1;
    }

    p_base = (u_char *)calloc(sizeof(u_char), elf_stat.st_size);
    if(!p_base)
    {
        fprintf(stderr, "Not enough memory\n");
        close(fd_elf);
        return 1;
    }

    if(read(fd_elf, p_base, elf_stat.st_size) != elf_stat.st_size)
    {
        fprintf(stderr, "Error while reading file: %s\n", strerror(errno));
        free(p_base);
        close(fd_elf);
        return 1;
    }
    
    close(fd_elf);

    p_ehdr = (Elf32_Ehdr *)p_base;
    if(elf_is_valid(p_ehdr))
    {
        print_elf_header(p_ehdr);

        printf("\n");
        
        //to reach the section header table and the program header table
        //we simply add the offset of these table to the base address
        p_phdr = (Elf32_Phdr *)(p_base + p_ehdr->e_phoff);
        p_shdr = (Elf32_Shdr *)(p_base + p_ehdr->e_shoff);
        
        //this is the first example of string table usage: the e_shstrndx field
        //holds an index into the section header table, which is address by p_shdr. The section's
        //sh_offset field will hold the offset of the string table, to get the actual pointer
        //we have just to sum it to the base address
        p_strtable = (char *)(p_base + p_shdr[p_ehdr->e_shstrndx].sh_offset);

        for(i = 0; i < p_ehdr->e_phnum; i++)
        {
            print_program_header(&p_phdr[i], i);
        }

        for(i = 0; i < p_ehdr->e_shnum; i++)
        {
            print_section_header(&p_shdr[i], i, p_strtable);
        }
    }
    else
        printf("Invalid ELF file\n");

    free(p_base);
    return 0;
}

typedef struct
{
  Elf32_Word    st_name;        /* Symbol name (string tbl index) */
  Elf32_Addr    st_value;        /* Symbol value */
  Elf32_Word    st_size;        /* Symbol size */
  unsigned char    st_info;        /* Symbol type and binding */
  unsigned char    st_other;        /* Symbol visibility */
  Elf32_Section    st_shndx;        /* Section index */
} Elf32_Sym;

• st_name: the name of the symbol, of course it's an index into a string table. The string table to use depends, as usual, on the context.
• st_value: the value of the symbol, it may be an address, an offset, an index, etc... it depends on the symbol type.
• st_size: size of the symbol, it is meaningful only for some kind of symbols: e.g. for a symbol of type OBJECT, it will hold the object's size in bytes.
• st_info: actually this is a byte-packed type. It's made up of two nibble, one contains the type of the symbols, the other contains its binding (local,global,weak). The file elf.h defines some useful macros to manipulate this field:
  • ELF32_ST_BIND(i): returns the bind of the symbol.
  • ELF32_ST_TYPE(i): returns the type of the symbol.
  • ELF32_ST_INFO(b,t): packs b and t into a single byte, b is the binding type and t is the symbol type.
• st_other: according to ELF specification, the value of this field in undefined. On linux systems, it holds the symbol visibility (defined values: DEFAULT, HIDDEN).
• st_shndx: the index of the section which holds the symbol described by this entry.

quake2@quake2-desktop:~$ readelf -W -s /bin/ls

Symbol table '.dynsym' contains 105 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
[...]
    23: 00000000   198 FUNC    GLOBAL DEFAULT  UND strncpy@GLIBC_2.0 (2)
    24: 00000000    35 FUNC    GLOBAL DEFAULT  UND freecon
    25: 00000000    88 FUNC    GLOBAL DEFAULT  UND memset@GLIBC_2.0 (2)
    26: 00000000   441 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.0 (2)
    27: 00000000    68 FUNC    GLOBAL DEFAULT  UND mempcpy@GLIBC_2.1 (5)
    28: 00000000    80 FUNC    GLOBAL DEFAULT  UND __memcpy_chk@GLIBC_2.3.4 (6)
    29: 00000000   186 FUNC    GLOBAL DEFAULT  UND _obstack_begin@GLIBC_2.0 (2)
    30: 00000000    19 FUNC    GLOBAL DEFAULT  UND _exit@GLIBC_2.0 (2)
    31: 00000000   441 FUNC    GLOBAL DEFAULT  UND strrchr@GLIBC_2.0 (2)
    32: 00000000   336 FUNC    GLOBAL DEFAULT  UND __assert_fail@GLIBC_2.0 (2)
    33: 00000000    29 FUNC    GLOBAL DEFAULT  UND bindtextdomain@GLIBC_2.0 (2)
    34: 00000000   597 FUNC    GLOBAL DEFAULT  UND mbrtowc@GLIBC_2.0 (2)
    35: 00000000    62 FUNC    GLOBAL DEFAULT  UND gettimeofday@GLIBC_2.0 (2)
    36: 00000000    64 FUNC    GLOBAL DEFAULT  UND __ctype_toupper_loc@GLIBC_2.3 (7)
    37: 00000000    69 FUNC    GLOBAL DEFAULT  UND __lxstat64@GLIBC_2.2 (3)
    38: 00000000   446 FUNC    GLOBAL DEFAULT  UND _obstack_newchunk@GLIBC_2.0 (2)
    39: 00000000   102 FUNC    GLOBAL DEFAULT  UND __overflow@GLIBC_2.0 (2)
    40: 00000000    73 FUNC    GLOBAL DEFAULT  UND dcgettext@GLIBC_2.0 (2)
    41: 00000000   100 FUNC    GLOBAL DEFAULT  UND sigaction@GLIBC_2.0 (2)
    42: 00000000   351 FUNC    GLOBAL DEFAULT  UND strverscmp@GLIBC_2.1 (5)
    43: 00000000   152 FUNC    GLOBAL DEFAULT  UND opendir@GLIBC_2.0 (2)
    44: 00000000    71 FUNC    GLOBAL DEFAULT  UND getopt_long@GLIBC_2.0 (2)
    45: 00000000    64 FUNC    GLOBAL DEFAULT  UND ioctl@GLIBC_2.0 (2)
    46: 00000000    64 FUNC    GLOBAL DEFAULT  UND __ctype_b_loc@GLIBC_2.3 (7)
    47: 00000000   226 FUNC    GLOBAL DEFAULT  UND iswcntrl@GLIBC_2.0 (2)
    48: 00000000    50 FUNC    GLOBAL DEFAULT  UND isatty@GLIBC_2.0 (2)
    49: 00000000   539 FUNC    GLOBAL DEFAULT  UND fclose@GLIBC_2.1 (5)
    50: 00000000    25 FUNC    GLOBAL DEFAULT  UND mbsinit@GLIBC_2.0 (2)
    51: 00000000    54 FUNC    GLOBAL DEFAULT  UND _setjmp@GLIBC_2.0 (2)
    52: 00000000    56 FUNC    GLOBAL DEFAULT  UND tcgetpgrp@GLIBC_2.0 (2)
    53: 00000000    60 FUNC    GLOBAL DEFAULT  UND mktime@GLIBC_2.0 (2)
    54: 00000000   222 FUNC    GLOBAL DEFAULT  UND readdir64@GLIBC_2.2 (3)
    55: 00000000    70 FUNC    GLOBAL DEFAULT  UND memcpy@GLIBC_2.0 (2)
    56: 00000000    76 FUNC    GLOBAL DEFAULT  UND strtoul@GLIBC_2.0 (2)
    57: 00000000   175 FUNC    GLOBAL DEFAULT  UND strlen@GLIBC_2.0 (2)
    58: 00000000   299 FUNC    GLOBAL DEFAULT  UND getpwuid@GLIBC_2.0 (2)
    59: 00000000   186 FUNC    GLOBAL DEFAULT  UND acl_extended_file@ACL_1.0 (8)
    60: 00000000  1931 FUNC    GLOBAL DEFAULT  UND setlocale@GLIBC_2.0 (2)
    61: 00000000    37 FUNC    GLOBAL DEFAULT  UND strcpy@GLIBC_2.0 (2)
    62: 00000000   148 FUNC    GLOBAL DEFAULT  UND raise@GLIBC_2.0 (2)
    63: 00000000   178 FUNC    GLOBAL DEFAULT  UND fwrite_unlocked@GLIBC_2.1 (5)
    64: 00000000   293 FUNC    GLOBAL DEFAULT  UND clock_gettime@GLIBC_2.2 (9)
    65: 00000000   123 FUNC    GLOBAL DEFAULT  UND getfilecon
    66: 00000000    98 FUNC    GLOBAL DEFAULT  UND closedir@GLIBC_2.0 (2)
    67: 00000000   403 FUNC    GLOBAL DEFAULT  UND fwrite@GLIBC_2.0 (2)
    68: 00000000   174 FUNC    GLOBAL DEFAULT  UND sigprocmask@GLIBC_2.0 (2)
    69: 00000000    32 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (10)
    70: 00000000    42 FUNC    GLOBAL DEFAULT  UND __fpending@GLIBC_2.2 (3)
    71: 00000000   123 FUNC    GLOBAL DEFAULT  UND lgetfilecon
    72: 00000000   223 FUNC    GLOBAL DEFAULT  UND error@GLIBC_2.0 (2)
    73: 00000000   299 FUNC    GLOBAL DEFAULT  UND getgrgid@GLIBC_2.0 (2)
    74: 00000000    75 FUNC    GLOBAL DEFAULT  UND __strtoull_internal@GLIBC_2.0 (2)
    75: 00000000   115 FUNC    GLOBAL DEFAULT  UND sigaddset@GLIBC_2.0 (2)
[...]

typedef struct
{
  Elf32_Addr    r_offset;        /* Address */
  Elf32_Word    r_info;            /* Relocation type and symbol index */
} Elf32_Rel;

• r_offset: offset to which the relocation must be applied.
• r_info: a word which contains the relocation type and if the relocation is associated with a symbol, it will contain the symbol index into the symbol table being used.

quake2@quake2-desktop:~/elfinj$ readelf -r libhook.so

Relocation section '.rel.dyn' at offset 0x3b4 contains 49 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000679  00000008 R_386_RELATIVE   
0000069d  00000008 R_386_RELATIVE   
000006b8  00000008 R_386_RELATIVE   
000006c5  00000008 R_386_RELATIVE   
000006ca  00000008 R_386_RELATIVE

R_386_RELATIVE The link editor creates this relocation type for dynamic link-
               ing. Its offset member gives a location within a shared object
               that contains a value representing a relative address. The
               dynamic linker computes the corresponding virtual address
               by adding the virtual address at which the shared object was
               loaded to the relative address. Relocation entries for this type
               must specify 0 for the symbol table index.

 6b5:    c7 04 24 81 0a 00 00     movl   $0xa81,(%esp)
 6bc:    e8 fc ff ff ff           call   6bd 

typedef struct
{
  Elf32_Sword    d_tag;            /* Dynamic entry type */
  union
    {
      Elf32_Word d_val;            /* Integer value */
      Elf32_Addr d_ptr;            /* Address value */
    } d_un;
} Elf32_Dyn;

• d_tag: the type of the entry, the interting ones for this article are DT_PLTRELSZ, DT_SYMTAB, DT_STRTAB, DT_REL and DT_JMPREL, so be sure to check them on the ELF manual and to understand how they work. The entry of type DT_SYMTAB gives the symbol table which holds dynamic symbols and the one of type DT_STRTAB gives the string table which holds the names of the dynamic symbols. So as mentioned before, there is no ambiguity on which symbol table/string table to use.
• d_ptr: the virtual address of the entry identified by the symbol. If we're dealing with an executable, this will be a virtual address, otherwise it will be a relative virtual address (needs to be added to the image base).

quake2@quake2-desktop:~$ readelf -d /bin/ls

Dynamic section at offset 0x16f04 contains 24 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libselinux.so.1]
 0x00000001 (NEEDED)                     Shared library: [libacl.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000c (INIT)                       0x8049508
 0x0000000d (FINI)                       0x805af7c
 0x00000004 (HASH)                       0x8048188
 0x6ffffef5 (GNU_HASH)                   0x80484b8
 0x00000005 (STRTAB)                     0x8048ba4
 0x00000006 (SYMTAB)                     0x8048514
 0x0000000a (STRSZ)                      1199 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x805fff4
 0x00000002 (PLTRELSZ)                   744 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x8049220
 0x00000011 (REL)                        0x80491f8
 0x00000012 (RELSZ)                      40 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x8049128
 0x6fffffff (VERNEEDNUM)                 3
 0x6ffffff0 (VERSYM)                     0x8049054
 0x00000000 (NULL)                       0x0

static char *btypes[] = {
        "STB_LOCAL",
        "STB_GLOBAL",
        "STB_WEAK"
};

static char *symtypes[] = {
        "STT_NOTYPE",
        "STT_OBJECT",
        "STT_FUNC",
        "STT_SECTION",
        "STT_FILE"
};

void print_bind_type(u_char info)
{
    u_char bind = ELF32_ST_BIND(info);
    if(bind <= 2)
        printf("- Bind type: %s\n", btypes[bind]);
    else
        printf("- Bind type: %d\n", bind);
}

void print_sym_type(u_char info)
{
    u_char type = ELF32_ST_TYPE(info);

    if(type <= 4)
        printf("- Symbol type: %s\n", symtypes[type]);
    else
        printf("- Symbol type: %d\n", type);
}

int print_sym_table(u_char *filebase, Elf32_Shdr *section, char *strtable)
{
    Elf32_Sym *symbols;
    size_t sym_size = section->sh_entsize;
    size_t cur_size = 0;

    if(section->sh_type == SHT_SYMTAB)
        printf("Symbol table\n");
    else
        printf("Dynamic symbol table\n");

    if(sym_size != sizeof(Elf32_Sym))
    {
        printf("There's something evil with symbol table...\n");
        return 0;
    }

    symbols = (Elf32_Sym *)(filebase + section->sh_offset);
    symbols++;
    cur_size += sym_size;
    do
    {
        printf("- Name index: %d\n", symbols->st_name);
        printf("- Name: %s\n", strtable + symbols->st_name);
        printf("- Value: 0x%08x\n", symbols->st_value);
        printf("- Size: 0x%08x\n", symbols->st_size);

        print_bind_type(symbols->st_info);
        print_sym_type(symbols->st_info);

        printf("- Section index: %d\n", symbols->st_shndx);
        cur_size += sym_size;
        symbols++;
    } while(cur_size < section->sh_size);

    return 1;
}

int main(int argc, char *argv[])
{
    int fd_elf = -1;
    u_char *p_base = NULL;
    char *p_strtable = NULL;
    struct stat elf_stat;
    Elf32_Ehdr *p_ehdr = NULL;
    Elf32_Phdr *p_phdr = NULL;
    Elf32_Shdr *p_shdr = NULL;
    int i;

    if(argc < 2)
    {
        printf("Usage: %s \n", argv[0]);
        return 1;
    }

    fd_elf = open(argv[1], O_RDONLY);
    if(fd_elf == -1)
    {
        fprintf(stderr, "Could not open %s: %s\n", argv[1], strerror(errno));
        return 1;
    }

    if(fstat(fd_elf, &elf_stat) == -1)
    {
        fprintf(stderr, "Could not stat %s: %s\n", argv[1], strerror(errno));
        close(fd_elf);
        return 1;
    }

    p_base = (u_char *)calloc(sizeof(u_char), elf_stat.st_size);
    if(!p_base)
    {
        fprintf(stderr, "Not enough memory\n");
        close(fd_elf);
        return 1;
    }

    if(read(fd_elf, p_base, elf_stat.st_size) != elf_stat.st_size)
    {
        fprintf(stderr, "Error while reading file: %s\n", strerror(errno));
        free(p_base);
        close(fd_elf);
        return 1;
    }
    
    close(fd_elf);

    p_ehdr = (Elf32_Ehdr *)p_base;
    if(elf_is_valid(p_ehdr))
    {
        print_elf_header(p_ehdr);

        printf("\n");
        p_phdr = (Elf32_Phdr *)(p_base + p_ehdr->e_phoff);
        p_shdr = (Elf32_Shdr *)(p_base + p_ehdr->e_shoff);
        p_strtable = (char *)(p_base + p_shdr[p_ehdr->e_shstrndx].sh_offset);

        for(i = 0; i < p_ehdr->e_phnum; i++)
        {
            print_program_header(&p_phdr[i], i);
        }

        for(i = 0; i < p_ehdr->e_shnum; i++)
        {
            print_section_header(&p_shdr[i], i, p_strtable);
            if(p_shdr[i].sh_type == SHT_SYMTAB || p_shdr[i].sh_type == SHT_DYNSYM)
            {
                printf("This section holds a symbol table...\n");

                //being a symbol table, the field sh_link of the section header
                //will hold an index into the section table which gives the
                //section containing the string table
                print_sym_table(p_base, &p_shdr[i], (char *)(p_base + p_shdr[p_shdr[i].sh_link].sh_offset));
            }
        }
    }
    else
        printf("Invalid ELF file\n");

    free(p_base);
    return 0;
}

• PT_INTERP: this segment describes a memory area which holds a string. This string is an absolute path to a file, which is a program/library that works in conjuction with the system loader to actually load the ELF. On ELF built for linux, this program header holds:

  quake2@quake2-desktop:~$ readelf -l /bin/ls
  [...]
    INTERP         0x000154 0x08048154 0x08048154 0x00013 0x00013 R   0x1
        [Requesting program interpreter: /lib/ld-linux.so.2]
  [...]
  

  so the program header is requesting the collaboration of /lib/ld-linux.so.2, which is the ELF loader on linux:

  quake2@quake2-desktop:~$ /lib/ld-linux.so.2
  Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
  You have invoked `ld.so', the helper program for shared library executables.
  This program usually lives in the file `/lib/ld.so', and special directives
  in executable files using ELF shared libraries tell the system's program
  loader to load the helper program from this file.  This helper program loads
  the shared libraries needed by the program executable, prepares the program
  to run, and runs it.  You may invoke this helper program directly from the
  command line to load and run an ELF executable file; this is like executing
  that file itself, but always uses this helper program from the file you
  specified, instead of the helper program file specified in the executable
  file you run.  This is mostly of use for maintainers to test new versions
  of this helper program; chances are you did not intend to run this program.
  
    --list                list all dependencies and how they are resolved
    --verify              verify that given object really is a dynamically linked
                          object we can handle
    --library-path PATH   use given PATH instead of content of the environment
                          variable LD_LIBRARY_PATH
    --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names
                          in LIST
  

• PT_LOAD: this segment type holds information on how to map sections which usually contains data and/or code.
• PT_DYNAMIC: this segment holds informations for the linker on where to find symbols, string tables, relocations, etc... . Usually its contents is the same as the dynamic section.

• DT_JMPREL: this field holds the address of a table containing an array of relocation entries related only to the PLT. This way if lazy binding in enabled, the linker will ignore this relocations during loading.
• DT_PLTREL: this field holds the type of the PLT relocations. For an x86 architecture there can be only REL relocations.
• DT_PLTRELSZ: the total size, in bytes, of the table addressed by DT_JMPREL.
• DT_NEEDED: a string which holds the name of a library that is required to load the image. As usual, this field is an index into a string table, the one addressed by the DT_STRTAB dynamic entry.
• DT_INIT: this field holds the address of a function to call on initialization: it is executed before the "main" if the image is an executable, otherwise it is executed before the control goes back to the main executable if the image is a library.
• DT_FINI: this field holds the address of a fucntion to be called on finalization. The order in which the finalization functions are called is the inverse order of the initialization ones.

int main()
{
    int res = external_function(3,4);
    return 0;
}

push 0x04
push 0x03
call external_function@plt
add esp, 8

[,..]

; this is a PLT entry
external_function@plt (address 0xXXXXXX00):
  external_function@plt+0x00: jmp dword ptr [reloc_address] ; reloc_address is just a memory location
  external_function@plt+0x06: push reloc_offset ; reloc_offset is a byte offset (not an index) into the relocation table
  external_function@plt+0x0B: jmp resolve_function ; resolve_function is a function that will resolve the external symbol
  
; this is what you find at reloc_address, data is displayed using dwords
reloc_address: XXXXXX06 ........

push 0x04
push 0x03
call external_function@plt
add esp, 8

[...]

external_function@plt:
    external_function@plt+0x00:  jmp dword ptr [reloc_address]
    external_function@plt+0x06:  push reloc_index
    external_function@plt+0x0B:  jmp  resolve_function
    
reloc_address: BFF31337 ........

#include "libdummy.h"

int dummy_add(int a, int b)
{
	return a+b;
}

gcc -fPIC -c libdummy.c
ld -shared -soname libdummy.so.1 -o libdummy.so.1.0 -lc libdummy.o

ldconfig -v -n .

ln -sf libdummy.so.1 libdummy.so

#include 
#include "libdummy.h"

int main()
{
	int a,b;
	int res = 0;

	printf("Enter the first number: ");
	scanf("%d", &a);
	printf("Enter the second number: ");
	scanf("%d", &b);
	res = dummy_add(a,b);
	printf("Result is: %d\n", res);
	return 0;
}

gcc -o dummyelf dummyelf.c -L. -ldummy

That's all for now, in the next chapter we will explore the PLT. We will build the second library in the next part of this article.

quake2@quake2-desktop:~/elfinj$ gdb dummyelf
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) disassemble main
Dump of assembler code for function main:
[...]
0x08048507 <main+99>:	call   0x80483cc <dummy_add@plt>
[...]
End of assembler dump.
(gdb) break *0x08048507
Breakpoint 1 at 0x8048507
(gdb) 

(gdb) display/i $pc
(gdb) run
Starting program: /home/quake2/elfinj/dummyelf 
Enter the first number: 23
Enter the second number: 23

Breakpoint 1, 0x08048507 in main ()
1: x/i $pc
0x8048507 <main+99>:	call   0x80483cc <dummy_add@plt>
Current language:  auto; currently asm
(gdb) stepi
0x080483cc in dummy_add@plt ()
1: x/i $pc
0x80483cc <dummy_add@plt>:	jmp    *0x804a00c
(gdb)

(gdb) print /x *0x804a00c
$1 = 0x80483d2
(gdb)

(gdb) disassemble
Dump of assembler code for function dummy_add@plt:
0x080483cc :	jmp    *0x804a00c
0x080483d2 :	push   $0x18
0x080483d7 :	jmp    0x804838c <_init+48>
End of assembler dump.
(gdb) 

(gdb) print /x *(0x8048334+0x18)
$4 = 0x804a00c
(gdb)

0x80483d7 <dummy_add@plt+11>:	jmp    0x804838c <_init+48>
(gdb) step
Single stepping until exit from function dummy_add@plt, 
which has no line number information.
0xb8095168 in dummy_add () from ./libdummy.so.1
1: x/i $pc
0xb8095168 <dummy_add>:	push   %ebp
(gdb) print /x *0x804a00c
$1 = 0xb8095168
(gdb)

This tutorial should have introduced the reader to the basics of the ELF format and how the system (in this case Linux) loads it. This part by no means is intended to replace the ELF manuals, which are a required reading for the next part, where things will get far more complicated. I've decided to split the article so if you're familiar with the ELF format, you can just skip to the second part. Also since there's a lot of code and other space consuming sections, making a big single article would have made a REALLY long html file, which is quite unpleasant. Things should be simple and straight.

The next part will deal with the actual injection and hooking. The arguments covered will be: the ptrace interface with examples, code injection (general view), shared object injection and limitations of the technique, PLT hooking (which will use all the concepts learned so far). The next part is expected to come out in the next few weeks (I hope not more than 2 weeks), depending on my time schedule (I'm an university student with a full-time job, it's quite difficult to find free-time :) ). I hope you enjoyed this first part...see you on the next one!

Here you will find all the tools/books used during this article:

History

10/11/2008: first version

Introduction

You must Sign In to use this message board.

Per page 102550

FirstPrevNext

can you email me the source code. karthik.sharma 12:23 7 Oct '09   please send it to karthik.sharma@gmail.com Sign In·View Thread·PermaLink part two? rob508 8:44 2 Aug '09   Thanks for the article. Well written and informative. Is the second part of the article published also? Would love to read it also. Anyone has any pointers to it? Sign In·View Thread·PermaLink Help xingcai 2:58 16 May '09   Could you send me source code? Email:xingcai_0521@163.com Sign In·View Thread·PermaLink E-mail me you source code incorrect.user 8:26 24 Apr '09   please, if it's possible! Sign In·View Thread·PermaLink 1.80/5 Download file missing Smitha Vijayan 6:56 14 Dec '08   Could you please upload the file in Zip format? Thanks Smitha Are you an aspiring author? Read how to submit articles to CodeProject: Article Submission Guidelines[^] More questions? Ask an editor here... Sign In·View Thread·PermaLink Re: Download file missing Quake2th 10:05 14 Dec '08   Hi, I tried but there's no way to do it...File upload for the Linux/Unix section is filled with bugs, each time I try to upload a file, my whole article gets deleted and there's an error abount some sharing issues. I contacted the web master but he didn't answered my mail, there's not much I can do. Anyway, if you're interested I might send the file to you by email, let me know... Sign In·View Thread·PermaLink

Last Visit: 14:33 23 Nov '09     Last Update: 14:33 23 Nov '09 1