UNIX / Linux platform executable file format analysis
Senior Programmer, Network Designer December 2004, MeMncmp@yahoo.com.cn
This article discusses three main executable file formats under the UNIX / Linux platform: A.out (Assembler and Link Editor Output assembler and link editor), Coff (Common Object File Format Universal Object File Format), ELF ( Executable and linking Format executable and link formats. The first is a review of the executable file format and to disclose the relationship between the executable content and the load operation operation by describing the ELF file. Subsequently, this three file formats are discussed, and the dynamic connection mechanism of the ELF file is also focused, and there is also an evaluation of various file format advantages and disadvantages. Finally, there is a simple summary of three executable file formats, and the author's sense of thinking is proposed.
Executable File Format Overview relative to other file types, executables may be the most important file type in an operating system because they are the true executors who complete the operation. The size, running speed, resource occupancy and scalability, portability, etc. of the executable file are closely related to the definition of file format and the file loading process. The format of studying executables is very meaningful for writing high performance programs and some hacker technology. Regardless of the executable file format, some basic elements are necessary, obvious, and the code should contain code and data. Since the file may reference the symbol (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, hardware information, and the like. Basically, any of the executable file formats are all saved in the interval, called segment or segment. The meaning of different file formats and the meanings of the festival may be fine, but according to the contextual relationship can be understood very well, this is not a key issue. Finally, executable usually has a file header to describe the overall structure of this document. There are three important concepts: compile, connection (LINK, can also be called Link, join), load (LOAD). The source program file is compiled into a target file, and multiple target files are connected to a final executable, and the executable is loaded into memory. Because this paper focuses on discussing the executable file format, so the loading process is relatively discussed. Below is a brief description of the ELF file load process under the Linux platform. 1: The core first reads the head of the ELF file, and then reads the various data structures according to the data indication of the header, and finds a segment marked as loadable, and calls the function mmap () to load the segment to memory. . Before loading, the kernel directs the tag of the segment to the MMAP (), indicating whether the segment is readable and writable in memory. Obviously, the text segment is read-only, and the data segment is readable. This approach is to utilize modern operating systems and processors to protect the memory. The famous shellcode preparation skill is a practical example of breaking through this protection. 2: The kernel analyzes the dynamic connector name corresponding to the ELF file marked as the PT_INTERP, and loads the dynamic connector. Modern Linux system dynamic connector is usually /LIB/ld-Linux.SO.2, and the details are described in detail later. 3: The kernel sets some tag-value pairs in the stack of the new process to indicate the related operations of the dynamic connector. 4: The kernel handle is transmitted to the dynamic connector. 5: Dynamic connector checks the dependence of external files (shared libraries) and load it when needed. 6: The dynamic connector is relocated, and popular, it is to tell the procedure to the address of the external variable / function of its reference, this address is located in the interval of the shared library. Dynamic connection has a latency (Lazy) positioning, that is, only repositioning when "real" needs to reference symbols, which is greatly helpful to improve program operation efficiency. 7: The dynamic connector performs the code of the section marked as .init in the ELF file and initializes the program run. In the early system, the initialization code corresponds to the function _init (void) (the function name is forced), in the modern system, 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 program entry point defined in the ELF file header. In a.out format and ELF format, the value of the program entry point is explicitly present, and the specification is implicitly defined in the COFF format. As can be seen from the above description, the most important thing to load files is to complete two things: load blocks and data segments to memory; carry out external definition symbols. Relocation is an important concept in the program connection. We know that an executable is usually composed of a main program file containing Main (), several target files, several shared libraries. (Note: Use some special skills, you can also write programs without Main functions, see References 2) A C program may reference the variables or functions defined by the shared library, in other words, these variables / functions must be found when the program is running the address of. 1. In the static connection, all external definitions that need to be used are fully included in the executable program. 2, and dynamically connect only some reference information of the relevant external definition only in the executable, the real relocation is in the operation of the program. There are two big problems in static connection: If there is any changes in the variable or function in the library, you must recompile the connection program; if multiple programs reference the same variable / function, this variable / function will appear multiple times in file / memory. Wash hard disk / memory space. Comparing the size of the executable of two connection-generated, it can be seen that there is a significant difference. A.out file format Analysis A.out format has a slight difference in different machine platforms and different UNIX operating systems, such as 6 section on the MC680x0 platform. Let's discuss the most "standard" format. The a.out file contains 7 sections, the format is as follows: Exec Header (executive header, you can also understand the file header) Text segment Data Segment Segment Segment Text Relocations Data Relocations Data Reling Segment) Symbol Table (Symbol Table) String Table Data Structure:
Struct exec {
Unsigned long a_midmag; / * Magic and other information * /
Unsigned long a_text; / * The length of the text segment * /
Unsigned long a_data; / * The length of the data segment * /
Unsigned long a_bss; / * The length of the BSS segment * /
Unsigned long a_syms; / * Symbol table length * /
Unsigned long a_entry; / * Program entry point * /
Unsigned long a_trsize; / * Text relocation table length * /
Unsigned long a_drsize; / * Data relocation table length * /
}
The file header mainly describes the length of each section, and the more important field is A_ENTRY (program entry point), which represents the entry of the system code after the system is loaded and initially tried various environments. This field also appears in the heads of the ELF file discussed later. From a.out format and head data structure, we can see that A.out's format is very compact, only the information necessary for the program run (text, data, BSS), and the order of each section is fixed. This structure lacks scalability, such as the common debugging information in the "modern" executable, the initial UNIX hacker debugging the tool for A.out file is ADB, and ADB is a machine language debugger! The A.out file contains the symbol table and two relocation tables, and the contents of the three tables functions in the connection target file to generate executable files. In the eventually executable A.out file, the length of these three tables is 0. A.out file When connected to the executable, if you look at the perspective of program design, it is a hard coding method, or can be called a strong root between the modules. In the discussion later, we will specifically see how the ELF format and dynamic connection mechanism improve this. A.out is the executable file format used by the early UNIX system, designed by the AT & T, now substantially replaced by the ELF file format. A.out's design is relatively simple, but its design ideas are obviously inherited and carried forward by subsequent executable formats. You can refer to the reference 16 and the reading reference 15 source code deepens the understanding of the A.out format. References 12 Discuss how to run a.out format file in "modern" red cap Linux. Coff file format Analysis Coff format is complex than A.out format, and most importantly, it includes a section table, so that other districts can be included in addition to .Text, .data, and .bss segments. segment. Also, an optional head is also possible, and different operating systems can be a specific definition on this head. The Coff file format is as follows: File Header Optional Header Section 1 Header ......... section section N Header Raw Data for Section 1 (Skumbeat) RAW Data for Section N (Data) RELOCATION INFO for SECT. 1 (Heavy Resistance Data) RELOCATION INFO for SECT. N (Headrest Location Data) LINE NUMBERS for SECT. 1 (Section Data) Line NumBers for SECT. N (Section Data) Symbol Table (Symbol Table) String Table Data Structure of the File Header:
Struct Filehdr
{
Unsigned short f_magic; / * Magic * /
Unsigned short f_nscns; / * Section number * /
Long f_timdat; / * File establishment time * /
Long f_symptr; / * Symbol table Offset * /
Long f_nsyms; / * Symbol table entry number * /
Unsigned short f_opthdr; / * Optional head length * /
UNSIGNED short f_flags; / * logo * /
}
The number of magic numbers in the head of the COFF file is not much, which is a machine type, such as the 0x014c 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 field f_flags is f_exec (0x00002), and it is also said that this file does not have unresolved symbols, in other words, it is to be completed when the relocation is connected. It can also be seen that the original COFF format does not support dynamic connections. In order to solve this problem and add some new features, some operating systems have expanded the COFF format. Microsoft designed a file format called PE (Portable Executable), the main extension is to add some special heads above the COFF file header. For details, please refer to Reference 18, some UNIX systems have also expanded the COFF format. For XCoff (Extended Common Object File Format), you support dynamic connections, see Resources 5. The header of the file is the optional header. In the COFF file format specification, the length of the optional header may be 0, but the header is optional in the Linux system. Below is a data structure of optional head under Linux: TypeDef Struct
{
Char Magic [2]; / * Magic * /
Char vStamp [2]; / * version number * /
Char Tsize [4]; / * Text section length * /
Char dsize [4]; / * has been initialized data segment length * /
Char Bsize [4]; / * Not initialized data segment length * /
Char entry [4]; / * Program entry point * /
Char text_start [4]; / * Text section base address * /
Char data_start [4]; / * Data segment base address * /
}
Coff_AOUTHDR;
When the field MAGIC is 0413, the COFF file is executable, notice that the optional header defines the program entry point, the standard COFF file does not have a clear definition of the value of the program entry point, usually from the .Text section start execution. But this design is not good. As mentioned earlier, the Coff format is more than a segment table than the A.out format, and a section header describes the details of a section data, so the COFF format can contain more sections, or can add specific to the actual needs. Section, specifically manifested in the definition of the COFF format itself and the COFF format extension mentioned earlier. I personally think that the appearance of the segment table may be the biggest progress in the Coff format relative to A.out format. Below we will briefly describe the data structure of the COFF file, because the meaning of the section is more embodied in the compilation and connection of the program, so this article does not describe it. In addition, the ELF format and COFF format are very similar to the definition of the section, and we will omit the discussion in subsequent ELF format analysis.
Struct coff_scnhdr
{
Char s_name [8]; / * Name * /
Char s_paddr [4]; / * Physical address * /
Char s_vaddr [4]; / * Virtual Address * /
CHAR S_SIZE [4]; / * Section length * /
CHAR S_SCNPTR [4]; / * Section data relative to file offset * /
Char S_Relptr [4]; / * Heavy grading information offset * /
Char s_lnnoptr [4]; / * Pavement Offset * /
Char s_nreloc [2]; / * Heavy grading entries * /
Char s_nlnno [2]; / * 80/0/2016 * /
Char s_flags [4]; / * segment mark * /
}
One thing to note: The comment in the header file Coff.h in the Linux system is "Physical Address", but it seems to be understood as "the space length occupied by the section to the memory". Fields S_Flags tag the type of this section, such as text segment, data segment, BSS segment, etc. The row information has also occurred in the COFF section, and the line information describes the cross-relationship between the binary code and the source code line number, which is useful in debugging. Reference 19 is a Chinese information detailed in the COFF format, please refer to References 20 more detailed. ELF file format analysis ELF file has three types: relocation file: is also the usual target file, suffix is .o. Shared files: that is, usually called library files, suffix is .so. Executive file: The file format of this article is mainly discussed, in general, the difference between the format of the executable file and the format of the above two files is primarily different from the perspective of observation: a linking view, An Execution View. First look at the overall layout of the ELF file:
Elf Header (ELF Head) Program Header Table Segment1 (Segment 1) Segment2 (Segment 2) ......... Sengmentn (Segment n) setion header Table (section header, optional) Segment by several sections ( Section) Composition, the section header has a description of the information of each section. For executable, the section table is optional. References 1 The author talks about all the data of the section header to 0, and the program can run correctly! The ELF head is a roadmap (Road Map) on this document and describes the structure of the file in general. Below is the data structure of the ELF header:
Typedef struct
{
Unsigned char e_ident [ei_nident]; / * Magic 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 head offset * /
ELF32_OFF E_SHOFF; / * 1.Front offset * /
ELF32_WORD E_FLAGS; / * Processor Specific Sign * /
ELF32_HALF E_EHSIZE; / * ELF Head Length * /
ELF32_HALF E_PHENTSIZE; / * One entry in the program head * /
ELF32_HALF E_PHNUM; / * Program head entry number * /
ELF32_HALF E_SHENTSIZE; / * The length of one entry in the section * /
ELF32_HALF E_SHNUM; / * Section head entry number * /
ELF32_HALF E_SHSTRNDX; / * Section head character table index * /} ELF32_EHDR;
Below we make related instructions for some important fields in the ELF header, see References 6 and References 7 for complete ELF definitions. E_IDENT [0] -e_ident [3] contains the magic number of the ELF file, which is 0x7f, 'e', 'l', 'f'. Note that any ELF file must contain this magnet. Reference 3 discusses a number of ways to view ELF magic numbers such as programs, tools, / proc file systems. e_ident [4] shows the number of hardware systems, 1 represents 32 bits, 2 represents 64 bits. E_IDENT [5] indicates data coding mode, 1 means small Indian sequence (the most meaningful byte occupies the lowest address), 2 represents the large Indian sequence (the most meaningful byte occupies the highest address). E_IDENT [6] Specifies the version of the ELF header, and must be 1. E_IDENT [7] to E_IDENT [14] is filled, usually 0. These bytes defined in the ELF format specification are ignored, but it is actually that these characters can be fully utilized. If the virus Lin / Glaurung.676 / 666 (Reference 1) Set E_IDENT [7] is 0x21, indicating that this file has been infected; or stores an executable code (reference data 2). Most of the segments in the ELF head are a description of the subhead data, and its meaning is relatively simple. It is worth noting that certain viruses may modify the value of the field E_ENTRY to point to the virus code, such as the virus Lin / Glaurung.676 / 666 mentioned above. The head form of a practical executable file is as follows: (Using command readelf)
Elf header:
MAGIC: 7F 45 4C 46 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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: 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: 34section header string Table Index: 31
The ELF header is the program header, which is an array of structures that contain the entry defined in the field E_phnum in the ELF header.
Typedef struct {
ELF32_WORD P_TYPE; / * Segment Type * /
ELF32_OFF P_OFFSET; / * Segment position relative to the offset at the beginning of the file * /
ELF32_ADDR P_VADDR; / * Address in memory * /
ELF32_ADDR P_PADDR; / * Physical address * /
ELF32_WORD P_FILESZ; / * Segment in the length of the file * /
ELF32_WORD P_MEMSZ; / * Segment in the length of the memory * /
ELF32_WORD P_FLAGS; / * Tag * /
ELF32_WORD P_ALIGN; / * Segment Aligns in memory * /
ELF32_PHDR;
First check out the output of an actual file before detailed in detail:
Program Headers:
Type Offset Virtdr Physaddr FileSiz Memsiz Fdfdlgg 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 .netu.version_r .rel.dyn .rel.plt .init .plt .text .fini.rodata .e_frame
03 .data .dynamic .ctors .dtors .jcr .got .bss.
04. Dynamic
05.note.abi-tag
Section headers:
[NR] Name Type Addr Off Size ES FFDFDFDLG LK INF AL
[0] null 00000000 000000000000 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 DYNSYM 08048168 000168 0000B0 10 A 5 1 4
[5] .dynstr startab 08048218 000218 00007B 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] .e_frame 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 0000c8 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 @Aranges progbits 000000 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 propits 00000000 0026E 0002cc 00 0 0 1
[28] .debug_line progbits 00000000 00293A 0003DC 00 0 0 1
[29] .debug_frame propits 00000000 002d18 000048 00 0 0 4
[30] .debug_str propits 00000000 002d60 000BCD 01 MS 0 0 1
[31]. SHSTRTAB STRTAB 00000000 00392D 00012B 00 0 0 1
[32] .ssymtab SymTab 00000000 003fa8 000740 10 33 56 4
[33] .strtab stratab 00000000 0046E8 000467 00 0 0 1
For an ELF executable, a basic segment is a segment of the mark p_type is Pt_Interp, which indicates the program interpreter (/LIB/ld-linux.so.2) required to run this program, actually Dynamic Linker. The most important segment is to mark the P_TYPE as the PT_LOAD, which indicates the data that needs to be loaded into memory for the running program. View the actual input above, you can see two Load segments, the first one is read-only (FDFDFFSLG is R e), the second is readable (FLFG is RW). Segment 1 contains text festival .Text, note that the value of the program entry point in the ELF file header is 0x80483cc, just pointing to the address in the memory. Segment 2 contains the data section .DATA, this data section is readable, relative read-only data section.Rodata is included in Section 1. The ELF format can contain more debugging information than the COFF format, as described above as the .debug_xxx. Under the i386 platform Linux system, use the command file to view an ELF executable possible output: 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 kernel positioning "correct" dynamic connector in memory is "correct" to run the guarantee of executable files, and the reference information 13 discusses how to find the dynamic connector in memory. The address in the Subversiver dynamic connection mechanism is achieved. Finally we discuss the dynamic connection mechanism of the ELF file. Each external defined symbol has a corresponding entry in the global offset table got. If the symbol is a function, there is a corresponding entry in the process connection table, and a PLT entry corresponds to one. GOT entry. For external definitions function parsing may be the most complex in the entire ELF file specification, the following is a description of the function symbol parsing process. 1: The code is called the external function func. The statement is called Call 0xAabBCCDD. The address 0xAabbcccdd actually is the entry address of the symbol FUNC in the PLT table (assuming address is label .plt2). 2: The form of the PLT table is as follows. Plt0: Pushl 4 (% EBX) / * GOT table address Save in the register EBX * /
JMP * 8 (% EBX)
NOP; NOP
NOP; NOP
.Plt1: jmp * Name1 @ got (% EBX)
Pushl $ OFFSET
JMP .plt0 @ PC
.Plt2: jmp * Func @ got (% EBX)
Pushl $ OFFSET
JMP .plt0 @ PC
3: View the label .plt2 statement, actually jump to the corresponding entry in the GOT table. 4: Before the symbol is not relocated, the address corresponding to this symbol in the GOT table is the next statement of the label .plt2, that is, the PUSHL $ OFFSET, where $ OFFSET is the relocation offset of the symbol FUNC. Note that this is a secondary jump. 5: After the relocation offset stack of the symbol FUNC, control the first entry to the PLT table, put the contents of the GOT [1], and jump to the address corresponding to the GOT [2]. 6: Got [2] is actually the code of the dynamic symbol parsing function. After the address parsing of the symbol FUNC, the address in 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, and can be called directly without the need to use the PLT table to jump. Dynamic connections are more complicated, but in order to obtain flexibility, it is usually complexity. The ultimate goal is to modify the value of the entries in the GOT table to the true address of the symbol, which can also explain the section. Got is included in the readable scriptures. Dynamic connection is a very important progress, which means that the library file can be upgraded, moved to other directories, etc., without the need to recompilate the program (of course, this does not mean the number, such as the number of functions, data) Types should be compatible). To a large extent, the dynamic connection mechanism is the decisive reason for the ELF format instead of A.out format. If the programming nature of the object is the interface of the interface (Interface), the dynamic connection mechanism is a very typical application of this idea, specific, dynamic connection mechanism and bridge in design mode (Bridge The method is similar, and its Lazy feature is very similar to the proxy method. Detailed description of dynamic connection operation See References 8, 9, 10, 11. By reading the source code of Readelf, Objdump, as well as the relevant software source code mentioned in Reference 14, the format of the ELF file can be more thoroughly understood. Summary Different periods of executable format reflect the process of technological progress, technology progress is usually for solving problems and adaptation to new environments. Early Unix systems use A.out format, with the progress of the operating system and hardware system, the limitations of A.out format are getting more obvious. The new executable file format Coff appears in Unix System VR3, the Coff format is relative to the maximum change in the format, which is a section head table, which can include the base text, data segment, BSS section. There is more paragraphs, but Coff is still difficult to support dynamic connections and C programs. In order to solve the above problem, UNIX System Laboratories USL develops an ELF file format, which is part of the application binary interface (Application Binary Interface ABI), which is an alternative to traditional A.out formats. For example, the ELF file format is introduced into the initial segment .init and end segment. Fini (corresponding constructor, respectively, respectively) is mainly to support C programs. In June 1994, the ELF format appeared on the Linux system, and now the ELF format is the most important executable file format of UNIX / Linux. Of course, we have reason to believe that there will be new executable file formats in the future. The above three executable file formats reflect the concept of layers in design ideas. The basic elements of the files are portrayed by a total head, and then the number of details of the files are forth by several sub-heads / entries.
Compare the executable file format and in the Ethernet package, IP header, TCP head design, I think we can feel the important design idea of layering. References 21 discusses the format of various documents from a global perspective, and proposes a relatively exaggerated conclusion: Everything is byte! Last question: Most information is lower in A.out format, common words Dark Ages, ugly (ugly), etc. As we can evaluate the technology of Stone Age today is ugly, then people can also ridicule today's technology is very ugly. I think we may use a more peaceful mentality to have a fair evaluation of the once technology. References "LINUX VIRUSES - ELF FILE FORMAT" Marius Van Oers "A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux" breadbox "The Linux Virus Writing And Detection HOWTO" Alexander Bartolich "ELF look from the perspective of a programmer" Hongjiu Lu alert7 ( Translation) "XCoff Object File Format" "EXECUTABLE AND LINKLE FORMAT" "ELF file format - ELF Document" Alert7 (translated) "Alert7" How to modify dynamic library symbol table "WANGDB" analysis ELF loading process "Opera" Before Main () Analysis "Alert7" LINKERS & LOADERS "John R. Levine" Running a.out Executables on Modern Red Hat Linux "" CHEATING THE ELF "" DBXRead.c "" DBXRead.c "" DBXRead.c "" Pages - A.Out (5) "Principle and Countermeasures of Linux under the buffer overflow attack" "Microsoft Portable Executable and Common Object File Format Specification" "COFF file structure" Redleaves "Common Object File Format (Coff)" "Everything IS Byte "Mala"
