Analysis of executable file formats on Unix/Linux platforms-reprint

Formats of executable files on Unix/Linux platforms

Author: Shi Cong 17:24:31 from: ibm dw China

This article discusses three main executable file formats in Unix/Linux:. out (compiler and editor output editor and link editor output), coff (Common Object File Format), ELF (executable and ing format executable and link format ).

The first is a summary of the executable file format, and describes the ELF file loading process to reveal the relationship between the executable file content and the loading operation. Later, we discussed the three file formats and focused on the dynamic connection mechanism of ELF files. In the meantime, we also discussed the advantages and disadvantages of various file formats. Finally, I would like to give a brief summary of the three formats of executable files, and give some comments to the author on the formats of executable files.

Overview of executable file formats

Compared with other file types, executable files may be the most important file types in an operating system, because they are the real executors of operations. The size, speed, resource usage, scalability, and portability of executable files are closely related to the definition of file formats and file loading processes. Studying the formats of executable files is very meaningful for writing high-performance programs and using hacker technologies. Regardless of the executable file format, some basic elements are required. Obviously, the file should contain code and data. Because the file may reference the symbols (variables and functions) defined by the external file, the relocation information and symbol information are also required. Some auxiliary information is optional, such as debugging information and hardware information.

Basically, any executable file format stores the preceding information by intervals, which is called segments or sections ). The meaning of the middle section and section of different file formats may be slightly different, but it can be clearly understood Based on the context, which is not a key issue. Finally, an executable file usually has a file header to describe the overall structure of the file.

Compared with executable files, there are three important concepts: compile, link, or link, and load ). The source program file is compiled into the target file, multiple target files are connected into a final executable file, and the executable file is loaded into the memory for running. This article focuses on the formats of executable files, so the loading process is also focused on.

The following is a brief description of the ELF file loading process on Linux.

1: The kernel first reads the header of the ELF file, then reads various data structures according to the data instructions in the header, finds the segments marked as loadable, and calls the MMAP () function () load the segment content to the memory. Before loading, the kernel passes the segment mark directly to MMAP (). The segment mark indicates whether the segment is readable, writable, and executable in the memory. Obviously, the text segment is read-only and executable, while the data segment is readable and writable. This method utilizes the memory protection functions of modern operating systems and processors. The well-known shellcode (Reference 17) Compilation technique is a practical example of breaking through this protection function.

2: The kernel analyzes the dynamic connector name marked as pt_interp In the ELF File and loads the dynamic connector. The dynamic connector for modern Linux systems is usually/lib/ld-linux.so.2, detailed descriptions are provided later.

3: The kernel sets some tag-value pairs in the stack of the new process to indicate operations related to the dynamic connector.

4: The kernel passes the control to the dynamic connector.

5: The dynamic connector checks the program's dependence on external files (shared libraries) and loads them as needed.

6: The dynamic connector is used to relocate the external reference of the program. Generally speaking, it is used to tell the program the address of the external variable/function referenced by it, this address is located within the memory range where the shared library is loaded. Dynamic connection also has a latency (lazy) Positioning feature, that is, it is only relocated when the 'true' needs to reference the symbol, which is of great help to improve the program running efficiency.

7: The dynamic connector executes the Code marked as. init In the ELF File to initialize the program running. In early systems, the initialization Code corresponds to the function _ Init (void) (the function name is forcibly fixed). In modern systems, the corresponding form is void _ attribute (constructor )) init_function (void ){......} The function name is arbitrary.

8: The dynamic connector passes the control to the program, starting from the entry point of the Program defined in the ELF file header. In A. Out format and ELF format, the value of the program entry point exists explicitly, while in coff format, it is implicitly defined by the standard.

From the above description, we can see that the most important thing to load a file is to load the program segment and data segment to the memory, and relocate the external definition symbol. Relocation is an important concept in program connection. We know that an executable program is usually composed of a main program file, a number of target files, and several shared libraries. (Note: You can use some special skills or compile a program without the main function. For details, see references. 2) a c program may reference the variables or functions defined in the shared library, in other words, the address of these variables/functions must be known when the program is running.

In static connections, all external definitions to be used by the program are completely included in the executable program, while dynamic connections only set reference information for the relevant external definitions in the executable file, the real relocation is when the program is running. There are two major problems with the static connection method: if there are any changes to the variables or functions in the library, you must re-compile the connection program. If multiple programs reference the same variables/functions, this variable/function appears multiple times in the file/memory, wasting hard disk/memory space.

Compare the sizes of executable files generated by the two connection methods. The obvious difference is displayed. A. Out file format analysis a. Out formats vary slightly on different machine platforms and UNIX operating systems. For example, there are 6 sections on mc680x0.

The most 'standard' format is discussed below. The A. out file contains seven sections in the following format:

Exec header (Execution header, which can also be understood as the file header)

Text Segment)

Data Segment)

Text relocations (text relocation segment)

Data relocations (Data relocation segment)

Symbol table)

String table (string table)

Data Structure of the execution header:

Struct exec {

Unsigned long a_midmag;/* magic number and other information */

Unsigned long a_text;/* length of the text segment */

Unsigned long a_data;/* data segment length */

Unsigned long a_bss;/* length of the BSS segment */

Unsigned long a_syms;/* symbol table length */

Unsigned long a_entry;/* program entry point */

Unsigned long a_trsize;/* length of the text relocation table */

Unsigned long a_drsize;/* length of the Data relocation table */};

The file header mainly describes the length of each section. The most important field is a_entry (program entry point ), it represents the entry for the system to start executing program code after loading the program and testing various environments. This field also appears in the header of the ELF File discussed later.

By. we can see from the output format and the header data structure that. the out format is very compact and only contains the information (text, data, and BSS) required for running the program, and the order of each section is fixed. This structure lacks scalability. For example, it cannot contain common debugging information in 'hyundai 'executable files. the tool used for debugging out files is ADB, and ADB is a machine language debugger! The A. out file contains the symbol table and two relocation tables. The content of these three tables takes effect when connecting the target file to generate an executable file. In the final executable A. out file, the length of the three tables is 0. A. the out file includes all external definitions in executable programs during connection. From the perspective of program design, this is a hard encoding method, or it can be called strong coupling between modules.

In the subsequent discussions, we will see how the ELF format and dynamic connection mechanism are improved. A. Out is an executable file format used by early Unix systems. It was designed by at&t and is now basically replaced by the ELF file format. The Design of A. Out is relatively simple, but its design concept is obviously inherited and carried forward by the subsequent executable file format. You can refer to reference 16 and read reference 15 source code to learn more about the. Out format. Reference 12 discusses how to run a. Out file in 'modern 'Red Hat Linux.

Coff file format Analysis

Coff format than. the out format must be more complex. The most important thing is to include a section table. text ,. data, and. in addition to the BSS segment, it can also contain other segments. An optional Header is also added. Different Operating Systems can define a specific header.

The coff file format is as follows:

File Header)

Optional Header (optional file header)

Section 1 header (segment header ).........

Section N header (section header)

Raw data for section 1 (section data)

Raw data for section N (section data)

Relocation info for sect. 1 (segment relocation data)

Relocation info for sect. N (segment relocation data)

Line numbers for sect. 1 (row number data)

Line numbers for sect. N (row number data)

Symbol table)

String table (string table)

Data Structure of the file header:

Struct filehdr {

Unsigned short f_magic;/* Magic Number */

Unsigned short f_nscns;/* number of nodes */

Long f_timdat;/* file creation time */

Long f_symptr;/* offset of the symbol table to the file */

Long f_nsyms;/* Number of symbol table entries */

Unsigned short f_opthdr;/* optional Header Length */

Unsigned short f_flags;/* flag */};

The magic number in the coff file header is of different significance from the other two formats. It indicates the target machine type, for example, 0x014c is relative to the i386 platform, and 0x268 is relative to the Motorola 68000 series. When the coff file is an executable file, the value of the field f_flags is f_exec (0x00002). It also indicates that the file has no unparsed symbols. In other words, that is, the relocation has been completed during the connection. We can also see that the original coff format does not support dynamic connections. To solve this problem and add some new features, some operating systems have extended the coff format. Microsoft has designed a file format named Pe (portable executable). The main extension is to add some specialized headers to the coff file header. For details, see reference 18, some UNIX systems have also extended the coff format, such as the xcoff (extended Common Object File Format) format. Dynamic connections are supported. For more information, see reference 5. The header next to the file is an optional Header. The coff file format specification specifies that the length of the optional Header can be 0, but the optional Header must exist in Linux.

The data structure of the optional headers in Linux is as follows:

Typedef struct {

Char magic [2];/* Magic Number */

Char vstamp [2];/* version */

Char tsize [4];/* Text Segment Length */

Char dsize [4];/* initialized data segment length */

Char bsize [4];/* uninitialized data segment length */

Char entry [4];/* program entry point */

Char text_start [4];/* base address of the text segment */

Char data_start [4];/* Data Segment Base Address */}

Coff_aouthdr; when the field magic is 0413, it indicates that the coff file is executable. Note that the program entry point is explicitly defined in the optional Header. The standard coff file does not explicitly define the value of the program entry point, usually from. the text section is executed, but this design is not good.

As we mentioned above, the coff format is better than that of. the out format has an extra segment table, and a segment header entry describes the details of a section data. Therefore, the coff format can contain more sections, or you can add specific sections as needed, it is embodied in the definition of the coff format and the coff format extension mentioned earlier.

In my opinion, the appearance of a segment table may be the greatest improvement in coff format compared to A. Out format. Next we will briefly describe the data structure of the Section in the coff file. Because the significance of the section is more reflected in the compilation and connection of the program, this article will not describe it more. In addition, the ELF format and coff format have very similar definitions of sections. In the subsequent ELF format analysis, we will omit the relevant discussions.

Struct coff_scnhdr {

Char s_name [8];/* section name */

Char s_paddr [4];/* physical address */

Char s_vaddr [4];/* virtual address */

Char s_size [4];/* segment length */

Char s_scnptr [4];/* offset of the section data to the file */

Char s_relptr [4];/* segment relocation information offset */

Char s_lnnoptr [4];/* offset of the row information */

Char s_nreloc [2];/* Number of relocated entries */

Char s_nlnno [2];/* Number of Information entries in the row */

Char s_flags [4];/* field mark */};

Note: In the Linux system, the comment on the s_paddr field in the header file coff. H is 'physical address', but it seems to be understood as 'the length of space occupied by the Section loaded into memory '. Field s_flags indicates the type of the Section, such as text segment, data segment, and BSS segment. The line information also appears in the coff section. The line information describes the ing relationship between the binary code and the source code line number, which is useful for debugging. Reference 19 is a Chinese document that describes the coff format in detail. For more information, see reference 20.

ELF File Format analysis elf files can be divided into three types: relocable files, which are commonly referred to as target files and suffixed with. O. Shared File: the Library file, which is usually referred to as. So.

Executable file:

The file format discussed in this article. In general, the difference between the formats of executable files and the formats of the above two files mainly lies in the observation angle: one is called the linking view and the other is called the execution view ).

First, let's take a look at the overall layout of the ELF file:

Elf header (ELF header)

Program header table (Program header table)

Segment1 (segment 1)

Segment2 (Segment 2 ).........

Sengmentn (segment N)

Setion header table (optional)

Segments are composed of several sections. The section header table describes the information of each section. The header table is optional for executable programs. In reference 1, the author talked about setting all the data in the header table to 0, and the program can run correctly! The elf header is a road map of this document, which describes the structure of the file in general.

The data structure of the elf header is as follows:

Typedef struct {

Unsigned char e_ident [ei_nident];/* magic number and related information */

Elf32_half e_type;/* target file type */

Elf32_half e_machine;/* hardware system */

Elf32_word e_version;/* target file version */

Elf32_addr e_entry;/* program entry point */

Elf32_off e_phoff;/* program header offset */

Elf32_off e_shoff;/* segment header offset */

Elf32_word e_flags;/* processor-specific flag */

Elf32_half e_ehsize;/* elf header length */

Elf32_half e_phentsize;/* the length of one entry in the program header */

Elf32_half e_phnum;/* number of entries in the program header */

Elf32_half e_shentsize;/* the length of one entry in the header of the Section */

Elf32_half e_shnum;/* number of entries in the header */

Elf32_half e_shstrndx;/* segment header comment table Index */}

Elf32_ehdr;

The following describes some important fields in the elf header table. For the complete elf definition, see references 6 and References 7.

E_ident [0]-e_ident [3] contains the magic number of ELF files, which are 0x7f, 'E', 'l', and 'F' in sequence '. Note that any ELF file must contain this magic number. Reference 3 describes how to view elf magic numbers using programs, tools,/proc file systems, and other methods.

E_ident [4] indicates the number of digits in the hardware system. 1 indicates 32 bits, and 2 indicates 64 bits.

E_ident [5] indicates the data encoding method. 1 indicates the small Indian sorting (the largest meaningful byte occupies the lowest address ), 2 represents the largest Indian Order (the largest meaningful byte occupies the highest address ).

E_ident [6] specifies the elf header version, which must be 1 currently.

E_ident [7] To e_ident [14] is a fill character, usually 0.

ELF format standards define these bytes to be ignored, but these bytes are actually fully usable. For example, if the virus Lin/glaurung.676/666 (reference 1) is set to e_ident [7] to 0x21, the file is infected, or the executable code is stored (Reference 2 ).

Most fields in the elf header describe the data in the Child header, which has a relatively simple meaning. It is worth noting that some viruses may modify the value of field e_entry (program entry point) to point to the virus code, such as the above mentioned virus Lin/glaurung.676/666.

The file header of an actual executable file is as follows: (use the readelf command)

Elf header:

Magic: 7f 45 4C 46 01 01 00 00 00 00 00 00 00 00 00 00

Class: elf32data: 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: 0x80483cc

Start of program headers: 52 (bytes into file)

Start of section headers: 14936 (bytes into file)

Flags: 0x0

Size of this header: 52 (bytes)

Size of program headers: 32 (bytes)

Number of program headers: 6

Size of section headers: 40 (bytes)

Number of section headers: 34

Section header string table index: 31

Next to the elf header is the program header table, which is a structure array that contains the entry defined by the field e_phnum In the elf header table, structure describes the information required for a segment or other systems to execute the program.

Typedef struct {

Elf32_word p_type;/* segment type */

Elf32_off p_offset;/* offset of the segment position relative to the start of the file */

Elf32_addr p_vaddr;/* address of the segment in the memory */

Elf32_addr p_paddr;/* physical address of the segment */

Elf32_word p_filesz;/* length of the segment in the file */

Elf32_word p_memsz;/* length of the segment in memory */

Elf32_word p_flags;/* segment mark */

Elf32_word p_align;/* segment alignment mark in memory */

} Elf32_phdr;

Before discussing the executable file program header table in detail, first view the output of an actual file:

Program headers:

Type offset incluaddr physaddr filesiz memsiz flg align

Phdr 0x000034 0x08048034 0x08048034 0x000c0 0x000c0 r e 0x4

Interp 0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R 0x1

[Requesting program Interpreter:/lib/ld-linux.so.2]

Load 0x000000 0x08048000 0x08048000 0x00684 0x00684 r e 0x1000

Load 0x000684 0x08049684 0x08049684 0x00118 0x00130 RW 0x1000

Dynamic 0x000690 0x08049690 0x08049690 0x000c8 0x000c8 RW 0x4

Note 0x000108 0x08048108 0x08048108 0x00020 0x00020 R 0x4

Section to segment mapping:

Segment sections...

00

01. interp

02. interp. note. abi-tag. hash. dynsym. dynstr. GNU. version. GNU. version_r. rel. dyn. rel. PLT. init. PLT. text. fini. rodata. eh _

03. Data. Dynamic. ctors. dtors. JCR. Got. BSS

04. Dynamic

05. Note. Abi-tag

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 080480f4 0000f4 000013 00 A 0 0 1

[2]. Note. Abi-tag note 08048108 000108 000020 00 A 0 0 4

[3]. Hash hash 08048128 000128 000040 04 a 4 0 4

[4]. dynsym 08048168 000168 running B0 10 A 5 1 4

[5]. dynstr strtab 08048218 000218 1277b 00 A 0 0 1

[6]. GNU. Version versym 08048294 000294 000016 02 a 4 0 2

[7]. GNU. version_r verneed 080482ac 0002ac 000030 00 A 5 1 4

[8]. Rel. Dyn rel 080482dc 0002dc 000008 08 A 4 0 4

[9]. Rel. PLT rel 080482e4 0002e4 000040 08 A 4 B 4

[10]. init progbits 08048324 000324 000017 00 ax 0 0 4

[11]. PLT progbits 0804833c 00033c 000090 04 ax 0 0 4

[12]. Text progbits 080483cc 0003cc 0001f8 00 ax 0 0 4

[13]. Fini progbits 080485c4 0005c4 00001b 00 ax 0 0 4

[14]. rodata progbits 080485e0 0005e0 00009f 00 A 0 0 32

[15]. Eh _ progbits 08048680 000680 000004 00 A 0 0 4

[16]. Data progbits 08049684 000684 00000c 00 wa 0 0 4

[17]. Dynamic dynamic 08049690 000690 running C8 08 wa 5 0 4

[18]. ctors progbits 08049758 000758 000008 00 wa 0 0 4

[19]. dtors progbits 08049760 000760 000008 00 wa 0 0 4

[20]. JCR progbits 08049768 000768 000004 00 wa 0 0 4

[21]. Got progbits 0804976c 00076c 000030 04 wa 0 0 4

[22]. BSS nobits 0804979c 00079c 000018 00 wa 0 0 4

[23]. Comment progbits 00000000 00079c 000132 00 0 0 1

[24]. debug_aranges progbits 00000000 0008d0 000098 00 0 0 8

[25]. debug_pubnames progbits 00000000 000968 000040 00 0 0 1

[26]. debug_info progbits 00000000 0009a8 001cc6 00 0 0 1

[27]. debug_abbrev progbits 00000000 00266e 0002cc 00 0 0 1

[28]. debug_line progbits 00000000 00293a 0003dc 00 0 0 1

[29]. debug_frame progbits 00000000 002d18 000048 00 0 0 4

[30]. debug_str progbits 00000000 002d60 000bcd 01 MS 0 0 1

[31]. shstrtab strtab 00000000 00392d 00012b 00 0 0 1

[32]. symtab 00000000 003fa8 000740 10 33 56 4

[33]. strtab 00000000 0046e8 000467 00 0 0 1

For an elf executable program, a basic segment is the segment marked with p_type as pt_interp, which indicates the program interpreter (/lib/LD-Linux) required to run the program. so.2), which is actually a dynamic connector (dynamic linker ).

The most important segment is the segment marked with p_type as pt_load, which indicates the data to be loaded to the memory for the running program.

Check the actual input above. We can see that there are two load-able segments. The first is read-only executable (flg is r e), and the second is readable and writable (flg is RW ). Segment 1 contains the text section. Text. Note that the value of the program entry point in the ELF File Header is 0x80483cc, which is exactly the address pointing to the section. Text in the memory. Section 2 contains the data section. data. The data in this section is readable and writable, and the relative read-only data section. rodata is included in section 1.

The ELF format can contain more debugging information than the coff format, such as the section in the form of. debug_xxx listed above.

On the i386 platform Linux system, run the command file to view the possible output of an elf executable program:

A. Out:

Elf 32-bit LSB executable, Intel 80386, Version 1 (sysv), for GNU/Linux 2.2.5, dynamically linked (uses SHARED libs), not stripped.

The ELF file contains the full path of the dynamic connector. The address in the memory of the dynamic connector with the kernel located in the correct state is the guarantee of running the executable file, reference 13 describes how to find the address in the memory of a dynamic connector to achieve a subversiver dynamic connection mechanism.

Finally, we will discuss the dynamic connection mechanism of ELF files. Each externally defined symbol has corresponding entries in the global offset table got. If the symbol is a function, there are also corresponding entries in the procedure linkage table PLT, a plt entry corresponds to a got entry.

Parsing external defined functions may be the most complex in the ELF File Specification. The following is a description of the function symbol parsing process.

1: Call the external function func in the Code. The statement format is call 0 xaabbccdd. The address 0xaabbccdd is actually the entry address of the symbol func In the PLT table (assuming the address is the number. plt2 ).

2: the form of the PLT table is as follows. plt0: the address of pushl 4 (% EBX)/* got table is saved in the register EBX */JMP * 8 (% EBX) NOP; nopnop; NOP. plt1: JMP * name1 @ Got (% EBX) pushl $ offsetjmp. PLT0@PC.PLT2: JMP * func @ Got (% EBX) pushl $ offsetjmp. plt0 @ PC

3: Check the statement of label. plt2. It is actually to jump to the entry corresponding to the symbol func in the got table.

4: Before the symbol is relocated, the next statement corresponding to the symbol in the got table is number. plt2, that is, pushl $ offset, where $ offset is the relocation offset of the symbol func. Note that this is a secondary jump.

5: after the relocation offset of the symbol func is pressed against the stack, control the stack to the first entry in the PLT table, press the content of got [1] on the stack, and jump to the address corresponding to got [2.

6: Got [2] corresponds to the code of the dynamic symbol parsing function. After the address of the symbol func is parsed, the func address in the memory is set to the entry corresponding to this symbol in the got table.

7: When this symbol is called for the second time, the corresponding entry in the got table already contains the address of this symbol, so you can directly call it without using the PLT table for redirection. Dynamic connections are complex, but the cost for flexibility is usually complexity. The ultimate goal is to change the value of entries in the got table to the actual address of the symbol. This can also be explained in section. Got is included in the readable and writable segment. Dynamic connection is an important step forward, which means that the library files can be upgraded and moved to other directories without re-compiling the program (of course, this does not mean that the Library can be modified at will, for example, the number and data type of function input parameters must be compatible ).

To a large extent, the dynamic connection mechanism is the decisive reason why the ELF format replaces the. Out format. If the essence of object-oriented programming is interface-oriented programming, the dynamic connection mechanism is a very typical application of this idea. Specifically, the dynamic connection mechanism is similar to the Bridge Method in the design mode, and its lazy feature is very similar to the proxy method. For details about the dynamic connection operation, see reference materials 8, 9, 10, 11. By reading the source code of the commands readelf and objdump and the software Source Code mentioned in reference 14, you can have a more thorough understanding of the ELF file format. Summary The formats of executable files in different periods deeply reflect the process of technological progress, which is usually aimed at solving existing problems and adapting to the new environment.

Early UNIX systems used the. Out format. With the improvement of the operating system and hardware system, the limitations of the. Out format became more and more obvious. The new executable file format coff appears in UNIX system vr3. The coff format is relative to. the biggest change in the out format is the addition of a section head table, which can contain more sections besides the basic text segment, data segment, and BSS segment, however, coff's support for dynamic connections and C ++ programs is still relatively difficult. To solve the preceding problem, UNIX System Laboratory (UNIX System laboratories USL) developed the ELF file format, which is used as part of the application binary interface Abi, the purpose is to replace the traditional. out format. For example, the introduction of the initialization segment. init and end segment. Fini (corresponding to the constructor and destructor respectively) in the ELF File Format mainly aims to support the C ++ program.

The ELF format appeared in Linux in June 1994. Now the ELF format is the most important executable file format in Unix/Linux. Of course, we have reason to believe that there will be a new executable file format in the future. The above three formats of executable files all reflect the concept of hierarchy in the design philosophy. A general header depicts the basic elements of the file, several sub-headers/entries are used to depict the details of the file. Compare the executable file format with the Ethernet header, IP header, and TCP header design in the Ethernet data packet. I think we can feel the important design idea of layering.

Reference 21 discusses the formats of various files from a global perspective and puts forward an exaggerated conclusion: Everything is byte! Last question: In most documents. the out format has a low rating, and common words include the Dark Ages and the ugly ones. Of course, from the modern point of view, it is indeed relatively simple, however, if there is no such thing as a simple one, how can we be more sophisticated today? As we can review today that the stone age technology is uugly, people in the future can also ridicule that today's technology is very uugly.

I think we should use a more peaceful attitude to give a fair comment on our previous technologies.

References

1. Linux viruses-ELF File Format Marius van oers

2. A whirlwind tutorial on creating really teensy elf executables for Linux breadbox

3. the Linux virus writing and detection howto Alexander bartolich

4. Elf from the programmer's perspective: hongjiu Lu alert7)

5. xcoff object file format

6. executable and linkable format (ELF)

7. ELF File Format-elf document in another text method alert7)

8. How to modify the dynamic library symbol table (wangdb)

9. Analyze the loading process of ELF Opera

10. Before main () analysis alert7

11. linkers & loaders John R. Levine

12. Running a. Out executables on modern Red Hat Linux

13. Cheating the elf

14. ELF binary analysis tools

15. dbxread. c

16. Manual reference pages-A. Out (5)

17. Principles and Countermeasures of buffer overflow attacks in Linux

18. Microsoft portable executable and common object file format specification

19. "coff file structure" redleaves

20. Common Object File Format (coff)

21. Everything is byte Mala

Shi Cong, Chengdu, Senior Programmer, and network designer. He has been engaged in C/C ++ programming and Database Modeling Based on Unix/Linux for a long time. You can contact him through a javer@163.com or memncmp@yahoo.com.cn.

Http://www.ibm.com/developerworks/cn/linux/l-excutff/