Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how to analyze the executable file format of UNIX or LINUX platform. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

This paper discusses three main executable file formats under the UNIX/LINUX platform: a.out (output of assembler and link editor output assembler and link editor), COFF (Common Object File Format common object file format), and ELF (Executable and Linking Format executable and link format). The first is an overview of the executable file format, and by describing the ELF file loading process to reveal the relationship between the executable file content and the load run operation. Then, according to this, the three file formats are discussed, with emphasis on the dynamic linking mechanism of ELF files, with the evaluation of the advantages and disadvantages of various file formats. Finally, there is a simple summary of the three executable file formats, and the author puts forward some thoughts on the evaluation of the executable file format.

Summary of executable file format

Executable files are probably the most important file types in an operating system relative to other file types, because they are the real executors who complete the operation. The size, running speed, resource consumption, scalability and portability of executable files are closely related to the definition of file format and file loading process. The research on the format of executable files is very meaningful for writing high-performance programs and the application of some hacker technologies.

Regardless of the executable file format, some basic elements are necessary, and it is obvious that the file should contain code and data. Because files may refer to symbols (variables and functions) defined by external files, relocation information and symbol information are also required. Some auxiliary information is optional, such as debugging information, hardware information and so on. Basically any executable file format stores the above information in intervals, called Segment or Section. There may be slight differences in the meaning of sections and sections in different file formats, but it can be clearly understood according to the context, which is not the key issue. Finally, executables usually have a file header to describe the overall structure of the file.

There are three important concepts for relative executables: compilation (compile), link (also known as link, join), and loading (load). The source program file is compiled into an object file, multiple object files are connected into a final executable file, and the executable file is loaded and run in memory. Because this article focuses on the executable file format, the loading process is also relatively focused. The following is a brief description of the loading process of ELF files on the LINUX platform.

1: the kernel first reads the header of the ELF file, then reads into various data structures according to the data instructions in the header, finds the segment marked as loadable, and calls the function mmap () to load the segment contents into memory. Before loading, the kernel passes the tag of the segment directly to mmap (), and the tag of the segment indicates whether the segment is readable, writable, and executable in memory. Obviously, the text segment is read-only and executable, while the data segment is readable and writable. This approach takes advantage of the memory protection functions of modern operating systems and processors. The writing technique of the famous Shellcode (Ref. 17) is a practical example of breaking through this protection function.

2: the kernel parses the corresponding dynamic connector name in the segment marked 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, which is described in more detail later.

3: the kernel sets some flag-value pairs in the stack of the new process to indicate the operation of the dynamic connector.

4: the kernel passes control to the dynamic connector.

5: dynamic connectors check the program's dependence on external files (shared libraries) and load them as needed.

6: the dynamic connector relocates the external reference of the program, which, in popular terms, tells the program the address of the external variable / function it refers to, which is located in the area where the shared library is loaded in memory. Dynamic connections also have the feature of Lazy positioning, which is relocated only when "real" reference symbols are needed, which is of great help to improve the efficiency of the program.

7: the dynamic connector initializes the running of the program by executing the code of the section marked .init in the ELF file. In early systems, the initialization code corresponds to the function _ init (void) (the function name is forced to be fixed). In modern systems, the corresponding form is

Void

_ _ attribute ((constructor))

Init_function (void)

{

……

}

Where the name of the function is arbitrary.

8: the dynamic connector passes control to the program and executes from the program entry point defined in the header of the ELF file. In a.out format and ELF format, the value of program entry point exists explicitly, while in COFF format, it is implicitly defined by the specification.

As you can see from the above description, the most important thing to load a file is to do two things: load program segments and data segments into memory, and relocate external definition symbols. Relocation is an important concept in program connection. We know that an executable program usually consists of a main program file containing main (), several object files, and several shared libraries (Shared Libraries). (note: using some special techniques, you can also write programs without main functions, see reference 2.) A C program may refer to variables or functions defined by a shared library, in other words, the address of these variables / functions must be known when the program runs. In a static connection, all external definitions that the program needs to use are fully included in the executable, while dynamic connections only set some reference information about the external definition in the executable file, and the real relocation is when the program is running. There are two big problems with static connections: if there are any changes in variables or functions in the library, the linker must be recompiled; if multiple programs reference the same variable / function, the variable / function will appear multiple times in the file / memory, wasting hard disk / memory space. Comparing the size of the executable files generated by the two connection methods, we can see that there is a significant difference.

Analysis of a.out file format

The a.out format varies slightly on different machine platforms and different UNIX operating systems, such as six section on the MC680x0 platform. What we discuss below is the most "standard" format.

The a.out file contains 7 section in the following format:

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

Text segment (text segment)

Data segment (data segment)

Text relocations (text relocation segment)

Data relocations (data relocation segment)

Symbol table (symbol table)

String table (character string table)

Execute the data structure of the header:

Struct exec {

Unsigned long aura midmagy; / * number of demons and other information * /

Unsigned long aversion text; / * length of text segment * /

Unsigned long data; / * length of data segment * /

Unsigned long axibsss; / * length of BSS segment * /

Unsigned long symbols; / * the length of the symbol table * /

Unsigned long aisle entry; / * Program entry point * /

Unsigned long: length of text relocation table * /

Unsigned long aheaddrsize; / * length of data relocation table * /

}

The file header mainly describes the length of each section, and the more important field is a_entry (program entry point), which represents the entrance for the system to execute the program code after loading the program and trying out various environments. This field also appears in the ELF file header discussed later. From the a.out format and header data structure, we can see that the format of a.out is very compact, containing only the information necessary for the program to run (text, data, BSS), and the order of each section is fixed. This structure lacks extensibility, such as not containing the debugging information common in "modern" executable files. The original UNIX hacker used adb to debug a.out files, and adb is a machine language debugger!

The a.out file contains symbol tables and two relocation tables, and the contents of these three tables play a role when connecting the target file to generate an executable. In the final executable a.out file, the length of all three tables is 0. The a.out file includes all external definitions in the executable program when it is connected, which is a hard coding method from a programming point of view, or it can be called a strong sum between modules. In a later discussion, we will see in detail how this has been improved by the ELF format and dynamic linking mechanism.

A.out is the executable file format used by early UNIX systems, designed by AT&T, and has now been basically replaced by the ELF file format. The design of a.out is relatively simple, but its design idea is obviously inherited and carried forward by the subsequent executable file format. You can refer to Ref. 16 and read Ref. 15 source code to deepen your understanding of the a.out format. Reference 12 discusses how to run a.out files in the "modern" Red Hat LINUX.

Analysis of COFF file format

The COFF format is a little more complex than the a.out format, and the most important thing is to include a section table (section table), so it can contain other sections in addition to .text, .data, and .bss sections. In addition, there is an optional header, which can be defined by different operating systems.

The COFF file format is as follows:

File Header (file header)

Optional Header (optional file header)

Section 1 Header (section 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 (node repositioning data)

Relocation Info for Sect. N (node relocation data)

Line Numbers for Sect. 1 (section number data)

Line Numbers for Sect. N (section number data)

Symbol table (symbol table)

String table (character string table)

The data structure of the file header:

Struct filehdr

{

Unsigned short favored magic; / * number of demons * /

Unsigned short fancinscns; / * number of nodes * /

Long fancitimdata; / * time when the file was created * /

Long fallow symptre; / * offset of symbol table from file * /

Long fancinsymbols; / * number of symbol table entries * /

Unsigned short frankopthr; / * optional head length * /

Unsigned short fanciers; / * Mark * /

}

The meaning of the magic number in the header of the COFF file is not quite the same as that of the other two formats. It represents the type of machine targeted, for example, 0x014c versus the I386 platform, and 0x268 versus the Motorola 68000 series, etc. When the COFF file is executable, the value of the field f_flags is F_EXEC (0X00002), which also means that the file has no unparsed symbols, in other words, the relocation is completed at the time of the connection. It can also be seen that the original COFF format does not support dynamic linking. In order to solve this problem and add some new features, some operating systems have extended the COFF format. Microsoft designed a file format called PE (Portable Executable). The main extension is to add some special headers on top of the COFF file header. For details, please see reference 18. Some UNIX systems also extend the COFF format, such as XCOFF (extended common object file format) format, which supports dynamic connections, see reference 5.

Immediately after the file header is the optional header. The COFF file format specification stipulates that the length of the optional header can be 0, but the optional header must exist in the LINUX system. The following is the data structure of the optional header under LINUX:

Typedef struct

{

Char magic [2]; / * number of demons * /

Char vstamp [2]; / * version number * /

Char tsize [4]; / * length of text segment * /

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

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

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

Char text_start [4]; / * text field base address * /

Char data_start [4]; / * Base address of data segment * /

}

COFF_AOUTHDR

A field magic of 0413 indicates that the COFF file is executable, and notice that the program entry point is explicitly defined in the optional header. The standard COFF file does not clearly define the value of the program entry point, usually starting from the .text section, but this design is not good.

As we mentioned earlier, the COFF format has one more section table than the a.out format, and a section header entry describes the details of a section data, so the COFF format can contain more sections, or you can add specific sections according to your actual needs, as reflected in the definition of the COFF format itself and the COFF format extension mentioned earlier. Personally, I think the emergence of section tables is probably the biggest improvement over the a.out format in COFF format. Below we will briefly describe the data structure of the section in the COFF file, because the meaning of the section is more reflected in the compilation and connection of the program, so this article will not describe it any more. In addition, the definitions of sections in the ELF format and the COFF format are very similar, and we will omit the discussion in the subsequent analysis of the ELF format.

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]; / * Section length * /

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

Char s_relptr [4]; / * offset of weight location information * /

Char s_lnnoptr [4]; / * Section information offset * /

Char s_nreloc [2]; / * number of repositioning entries * /

Char s_nlnno [2]; / * number of section information items * /

Char s_flags [4]; / * paragraph marking * /

}

One thing to note: the comment on the field s_paddr in the header file coff.h in the LINUX system is "physical address", but it seems to be understood as "the length of space taken up by the section being loaded into memory." The field s_flags marks the type of the section, such as text segment, data segment, BSS segment, and so on. Line information also appears in the section of COFF, which describes the mapping relationship between the binary and the line number of the source code, which is useful when debugging.

Analysis of ELF file format

There are three types of ELF files: relocatable files: commonly known as target files, with the suffix .o. Shared files: commonly known as library files, with the suffix .so. Executable file: this article mainly discusses the file format, generally speaking, the difference between the executable file format and the above two file formats mainly lies in the perspective of observation: one is called join view (Linking View), the other is called execution view (Execution View).

First take a look at the overall layout of the ELF file:

ELF header (ELF header)

Program header table (program header table)

Segment1 (paragraph 1)

Segment2 (paragraph 2)

.

Sengmentn (paragraph n)

Setion header table (section header table, optional)

The section consists of several sections (Section), and the section header table describes the information of each section. For executable programs, the section header table is optional. In reference 1, the author talks about setting all the data in the node table to 0, and the program will run correctly! the ELF header is a road map of this document, describing the structure of the file as a whole. The following is the data structure of the ELF header:

Typedef struct

{

Unsigned char e _ id [ei _ NIDENT]; / * number of demons and related information * /

Elf32_Half eBay type; / * Target file type * /

Elf32_Half eBay machine; / * hardware architecture * /

Elf32_Word eBay version; / * target file version * /

Elf32_Addr eBay entry; / * Program entry point * /

Elf32_Off eBay phoff; / * Program header offset * /

Elf32_Off estrangshoff; / * Section head offset * /

Elf32_Word eBay tags; / * processor-specific flags * /

Elf32_Half esigehsize; / * ELF header length * /

Elf32_Half estrangphentsize; / * length of an entry in the program header * /

Elf32_Half eStemphnums; / * number of entries in the program header * /

Elf32_Half estrangshentsize; / * length of an entry in section header * /

Elf32_Half estrangshnumb; / * number of section header entries * /

Elf32_Half estrangshstrndx; / * Section header character table index * /

} Elf32_Ehdr

E_ident [0]-e_ident [3] contains the magic number of ELF files, followed by 0x7f,'E','L', and'F'. Note that any ELF file must contain this magic number. Reference 3 discusses a variety of ways to view ELF magic numbers using programs, tools, / Proc file systems, and so on. E_ident [4] represents the number of bits of the hardware system, with 1 representing 32 bits and 2 representing 64 bits. E_ident [5] represents data encoding, 1 for small Indian sorting (the largest meaningful byte has the lowest address) and 2 for large Indian sorting (the largest meaningful byte has the highest address). E_ident [6] specifies the version of the ELF header, which must currently be 1. E_ident [7] to e_ident [14] are fillers, usually 0. These bytes defined in the ELF format specification are ignored, but in fact they are fully available. If the virus Lin/Glaurung.676/666 (Ref. 1) sets e_ident [7] to 0x21, it indicates that the file has been infected or stores executable code (Ref. 2). Most of the fields in the ELF header are descriptions of the sub-header data, and their meaning is relatively simple. It is worth noting that some viruses may modify the value of the field e_entry (program entry point) to point to virus code, such as the virus Lin/Glaurung.676/666 mentioned above.

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

ELF Header:

Magic: 7f 45 4c 46 01 01 01 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: 34

Section header string table index: 31

Immediately after the ELF header is the program header table, which is a structured array that contains entries defined by the field e_phnum in the ELF header table, structurally describing a segment or other information that the system needs to prepare to execute the program.

Typedef struct {

Elf32_Word paired type; / * Segment type * /

Elf32_Off paired offset; / * offset of the segment location from the beginning of the file * /

Elf32_Addr pairvaddr; / * address of segment in memory * /

Elf32_Addr paddr; / * physical address of the segment * /

Elf32_Word paired filesz; / * length of the segment in the file * /

Elf32_Word paired memsz; / * length of segment in memory * /

Elf32_Word packs; / * Mark of the segment * /

Elf32_Word palletized; / * Segment aligns tags in memory * /

} Elf32_Phdr

Before discussing the executable program header table in detail, take a look at the output of an actual file:

Program Headers:

Type Offset VirtAddr 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 _ frame

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 00000000 000

[1] .interp PROGBITS 080480f4 0000f4 000013 00 A 001

[2]. Note.ABI-tag NOTE 08048108 000108 000020 00 A 00 4

[3] .hash HASH 08048128 000128 000040 04 A 40 4

[4] .dynsym DYNSYM 08048168 000168 0000b0 10 A 5 1 4

[5] .dynstr STRTAB 08048218 000218 00007b 00 A 00 1

[6] .gnu.version VERSYM 08048294 000294 000016 02 A 4 02

[7] .gnu.version _ r VERNEED 080482ac 0002ac 000030 00 A 5 1 4

[8] .rel.dyn REL 080482dc 0002dc 000008 08 A 4 04

[9] .rel.plt REL 080482e4 0002e4 000040 08 A 4 b 4

[10] .init PROGBITS 08048324 000324 000017 00 AX 00 4

[11] .plt PROGBITS 0804833c 00033c 000090 04 AX 00 4

[12] .text PROGBITS 080483cc 0003cc 0001f8 00 AX 00 4

[13] .fini PROGBITS 080485c4 0005c4 00001b 00 AX 00 4

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

[15] .eh _ frame PROGBITS 08048680 000680 000004 00 A 004

[16] .data PROGBITS 08049684 000684 00000c 00 WA 00 4

[17] .dynamic DYNAMIC 08049690 000690 0000c8 08 WA 5 04

[18] .ctors PROGBITS 08049758 000758 000008 00 WA 00 4

[19] .dtors PROGBITS 08049760 000760 000008 00 WA 00 4

[20] .jcr PROGBITS 08049768 000768 000004 00 WA 004

[21] .got PROGBITS 0804976c 00076c 000030 04 WA 00 4

[22] .bss NOBITS 0804979c 00079c 000018 00 WA 00 4

[23] .comment PROGBITS 00000000 00079c 000132 0000 1

[24] .debug _ aranges PROGBITS 00000000 0008d0 000098 0000 8

[25] .debug _ pubnames PROGBITS 00000000 000968 000040 0000 1

[26] .debug _ info PROGBITS 00000000 0009a8 001cc6 0000 1

[27] .debug _ abbrev PROGBITS 00000000 00266e 0002cc 0000 1

[28] .debug _ line PROGBITS 00000000 00293a 0003dc 0000 1

[29] .debug _ frame PROGBITS 00000000 002d18 000048 00004

[30] .debug _ str PROGBITS 00000000 002d60 000bcd 01 MS 00 1

[31] .shstrtab STRTAB 00000000 00392d 00012b 0000 1

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

[33] .strtab STRTAB 00000000 0046e8 000467 0000 1

For an ELF executable program, a basic segment is the segment marked p_type as PT_INTERP, which indicates the program interpreter (/ lib/ld- linux.so.2) needed to run the program, which is actually the dynamic connector (dynamic linker). The most important segment is the one marked p_type as PT_LOAD, which indicates the data that needs to be loaded into memory in order to run the program. Looking at the actual input above, you can see that there are two LOAD segments, the first is read-only executable (FLg is R E), and the second is readable and writable (Flg is RW). Paragraph 1 contains the text of this section. Note that the value of the program entry point in the header of the ELF file is 0x80483cc, which happens to be the pointer. The address of text in memory. Segment 2 contains the data section .data, in which the data is readable and writable, and the relative read-only data section .rodata is contained in segment 1. The ELF format can contain more debugging information than the COFF format, such as the section listed above in the form .debug _ xxx. Under the LINUX system of I386 platform, using the command file to view the possible output of an ELF executable program is: 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, and the kernel locates the "correct" address of the dynamic connector in memory is the guarantee to run the executable file "correctly". Reference 13 discusses how to Subversiver the dynamic connection mechanism by looking up the address of the dynamic connector in memory.

Finally, we discuss the dynamic linking mechanism of ELF files. Each externally defined symbol has a corresponding entry in the global offset table (Global Offset Table GOT), and if the symbol is a function, there is also a corresponding entry in the procedure join table (Procedure Linkage Table PLT), and a PLT entry corresponds to a GOT entry. Parsing externally defined functions is probably the most complex of the entire ELF file specification. Here is a description of the function symbol parsing process.

1: the external function func is called in the code, and the statement form is call 0xaabbccdd. The address 0xaabbccdd is actually the address of the entry corresponding to the symbol func in the PLT table (assuming the address is labeled .PLT2).

The form of 2:PLT table is as follows

.PLT0: pushl 4 (% ebx) / * the address of the GOT table is saved in 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: looking at the statement labeled .PLT2 is actually jumping to the corresponding entry of the symbol func in the GOT table.

4: before the symbol is not relocated, the next statement in the GOT table corresponding to the symbol is labeled .PLT2, that is, pushl $offset, where $offset is the relocation offset of the symbol func. Notice that this is a secondary jump.

After stacking the relocation offset of the symbol func, the control jumps to the first entry of the PLT table, stacks the contents of the GOT [1], and jumps to the address corresponding to the GOT [2].

6:GOT [2] actually corresponds to the code of the dynamic symbol resolution function. After parsing the address of the symbol func, the address of the func in memory will be 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 the symbol, so it can be called directly without using the PLT table to jump.

Dynamic connections are complex, but the price of flexibility is usually complexity. The ultimate goal is to change the value of the entry in the GOT table to the real address of the symbol, which can also explain the section. Got is included in the readable and writable section.

Dynamic linking is a very important step forward, which means that library files can be upgraded, moved to other directories, and so on without recompiling the program (of course, this does not mean that the library can be modified at will. For example, the number of function input parameters, data types should be compatible). To a large extent, the dynamic join mechanism is the decisive reason why ELF format replaces a.out format. If the essence of object programming is interface programming, then 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 pattern, and its LAZY feature is very similar to the PROXY method. For a detailed description of the dynamic connection operation, see reference 8, 9, 10, 11. You can have a more thorough understanding of the format of the ELF file by reading the source code of the command readelf, objdump, and the related software source code mentioned in Resources 14.

Summary

Executable file formats in different periods profoundly reflect the process of technological progress, which is usually aimed at solving existing problems and adapting to the new environment. The early UNIX system used a.out format. With the development of operating system and hardware system, the limitation of a.out format is becoming more and more obvious. The new executable file format COFF appears in UNIX System VR3, the biggest change of COFF format compared with a.out format is that there is a section header table (section head table), which can contain more segments in addition to the basic text segment, data segment, and BSS segment, but it is still difficult for COFF to support dynamic connections and C++ programs. In order to solve the above problems, UNIX Systems Lab (UNIX SYSTEM Laboratories USL) developed the ELF file format, which is used as part of the application binary interface (Application binary Interface ABI) to replace the traditional a.out format. For example, the initialization segment .init and the end segment .fini (corresponding to constructors and destructors, respectively) are introduced into the ELF file format mainly to support C++ programs. The ELF format appeared on LINUX systems in June 1994, and now ELF format is the main executable file format of UNIX/LINUX. Of course, we have every reason to believe that there will be new executable file formats in the future.

The above three executable file formats well reflect the concept of layering in the design idea, the basic elements of the file are described by a total header, and then some details of the file are described by several sub-headers / entries. Comparing the executable file format with the design of Ethernet header, IP header and TCP header in Ethernet packets, I think we can feel the important design idea of layering very well. Reference 21 discusses various file formats from a global point of view, and puts forward a rather exaggerated conclusion: Everything Is Byte!

The last digression: most materials have a low evaluation of the a.out format, and the common words are dark ages, ugly, etc., of course, from a modern point of view, it is relatively simple, but without the simplicity it used to be, how can it be as delicate as it is today? Just as we can evaluate the Stone Age technology as ugly today, people in the future can also ridicule that today's technology is very ugly. I think maybe we should use a more peaceful state of mind to have a fair evaluation of the technology we used to have.

The above is the editor for you to share how to analyze the UNIX or LINUX platform executable file format, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.