PE file format-section and section table

17.1.4 section tables and sections

In terms of the arrangement position, PE files are separated from the DOS part and the PE File Header part by the Section Table and multiple different sections (3 and 4 in 17.1 ). To understand what is a section table, what is a section, and the relationship between them, you must first understand how Windows maps PE files to memory.

1. PE file-to-memory ing

When executing a PE file, Windows does not read the entire file into the memory at the beginning, but uses a mechanism similar to the memory ing file, that is, during loading, the Windows loader only establishes the ing between the virtual address and the PE file. Only when commands on a memory page are actually executed or data on a page is accessed, this page will be submitted from the disk to the physical memory. This mechanism does not affect the speed of file loading and the file size.

Figure 17.2 PE file-to-memory ing

However, the method by which the system loads executable files is not exactly equivalent to the memory ing file. When memory ing files are used, the system is very loyal to "original". If you compare disk files with memory images, it can be found that both the data itself and the relative positions between the data are identical. When an executable file is loaded, some data will be pre-processed before it is loaded (for example, the code to be relocated). After it is loaded, the relative positions between the data may also change, as shown in figure 17.2, the offset and size of a section may be completely different before and after the memory is loaded.

The Windows loader does not perform any processing when loading the DOS part, PE File Header part, and Section Table part. During loading the section, it will perform different processing according to the Section attributes, generally, you need to deal with the following aspects.

● Memory Page attributes

For disk ing files, all pages are set according to the attribute specified by the disk ing file function, but when loading executable files, the attributes of the Memory Page corresponding to the section must be set according to the Section attributes. Therefore, in the memory page of the same module, the attributes of the Memory Page mapped from different sections are different.

● Section offset address

The starting address of the section is aligned according to the value of the filealignment field in the image_optional_header32 structure in the disk file. When loaded into the memory, it is aligned according to the value of the sectionalignment field in the same structure, the values of the two may be different, so the offset relative to the file header after a node is loaded into the memory may be different from the offset in the disk file.

A section is a combination of data with the same attributes. When a section is loaded into the memory, the Memory Page corresponding to the same section will be assigned the same page property, in Windows, the Memory attribute is set in pages. Therefore, the alignment unit of a section in the memory must be at least one page. for Win32, this value is 4 kb (1000 h), and for win64, this value is 8 KB (2000 h ).

The alignment unit in the disk file does not have the limit of 4 kb. To reduce the size of the disk file, the file alignment unit is generally smaller than the memory alignment unit (the filealignment value is generally 200 h, in the disk, the size of 4 kb is not required for the Zero-header data at the end of each section.

● Section size

There are two ways to process the section size: first, the length expansion is caused by the difference of the section alignment units in the disk image and memory image; the second step is to process the section containing uninitialized data (in section 17.2. data Section ).

For uninitialized data (such as. Data defined in source code? Segment), there is no need to reserve space for them in the disk files, as long as the executable files are loaded into the memory to allocate space for them, therefore, the length of the section containing uninitialized data in the disk file is defined as 0, but the address and size loaded into the memory are explicitly specified.

For such a section, the memory pages it contains do not correspond to the disk file content. These memory pages are extended by the Windows loader according to the definition in the Section.

● Sections without ing

Data contained in some sections is only used during loading. When files are loaded, they are not submitted to the physical memory page. The most typical example is the section that contains the relocated data (in section 17.2. reloc Section). The relocated data is transparent to the Execution Code of the file. It is only used by the Windows loader, and the Execution Code will not access them at all. Once the load is complete, it is a waste to continue submitting memory pages for them. Therefore, these nodes are stored in disk files but are not mapped to memory.

2. Section Table

All the section attributes in the PE file are defined in the section table. The Section Table is arranged by a series of image_section_header structures. Each structure is used to describe a section, the order of the structure is the same as the order of the sections they describe in the file. The end of all valid structures is an empty image_section_header structure. Therefore, the total number of image_section_header structures in the section table is equal to the number of sections plus one. The Section Table is always stored in the place next to the PE File Header, that is, the offset starting from the PE File Header (Note: it is not the header of the file itself) is 00f8h.

The image_section_header structure is defined as follows:

Image_section_header struct

Name1 dB image_sizeof_short_name DUP (?) ; 8-byte partition name

Union Misc

Physicaladdress dd?

Virtualsize dd? ; Section size

Ends

Virtualaddress dd? ; Section RVA address

Sizeofrawdata dd? Size after alignment in the file

Pointertorawdata dd? ; Offset in the file

Pointertorelocations dd? In the OBJ file

Pointertolinenumbers dd? ; The location of the row number table (for trial use)

Numberofrelocations DW? In the OBJ file

Numberoflinenumbers DW? ; Number of row numbers in the row number table

Characteristics dd? ; Section attributes

Image_section_header ends

Some fields in the structure are used by the coff format OBJ file, which does not represent any meaning for the executable file. You can ignore them during analysis. The following describes the actually useful fields.

● Name1 Field

The field name of this field should have been "name", but this name conflicts with the keyword in MASM. Therefore, when defining this field, change it to "name1". The name1 field defines the section name, the field length is 8 bytes.

The section name in the PE file is an ANSI character string, but it is not specified to end with 0. If the name string of the section is less than 8 bytes in length, it is followed by 0, however, if the length of a string reaches 8 bytes, there will be no 0 characters after it. Therefore, you must pay attention to the end mode of the string during processing.

The name of each section is unique and cannot have two sections with the same name. However, the name of a section does not represent any meaning. It is just a tag set for ease of viewing, you can select any name or even leave it empty. it is legal to name the section containing code as "data" or the section containing data as "code.

Various compilers name the section in their own way. Therefore, you can see a variety of section names in the PE file, for example, in the executable file generated by masm32, the Code section is named ". text. the section containing read-only data, imported tables, and exported tables is named ". RDATA, and the resource section is named ". rsrc. However, in other compilers, the import table is separately placed in ". idata", and the code section may be named ". Code ".

When reading the required section from the PE file, the section name cannot be used as the positioning standard. The correct method is to locate the section according to the data directory Field in the image_optional_header32 structure.

I have read an article about how to access PE file resources. rsrc "section to obtain resources. Although this method can be used in most cases to find resources correctly, strictly speaking, only the image_directory_entry_resource item in the data directory always points to the resource data correctly.

● Virtualsize Field

Indicates the size of a section. This is the actual size of the data before the section is aligned.

● Virtualaddress Field

Specifies the offset address after the section is loaded into the memory. This is an RVA address. The address is aligned according to the Memory Page, and its value is always an integer multiple of the value of sectionalignment.

● Pointertorawdata Field

Specifies the location of the Section in the disk file. This value is the offset from the beginning of the file header.

● Sizeofrawdata Field

The space occupied by the Section in the disk file. This value is equal to the size after the virtualsize field value is aligned according to the filealignment value.

Based on the values of these four fields, the loader can find the data of a section (the sizeofrawdata byte starting from the pointertorawdata offset) from the PE file, map it To the memory (map it to the place where the base address of the module begins to offset virtualaddress, and occupy the size of the space after the virtualsize value is aligned by page size ).

● Characteristics Field

This is the attribute flag field of the section. Different data bits represent different attributes. The specific definitions are shown in Table 17.5. These data bits are combined to describe the attributes of the Section.

Description of attribute flag in section 17.5

 

Bit	The predefined value of the data bit in windows. INC and its meaning when it is 1
5	(Image_scn_cnt_code or 00000020 h) contains code
6	(Image_scn_cnt_initialized_data or 00000040 h) contains initialized data.
7	(Image_scn_cnt_uninitialized_data or 00000080 h) contains uninitialized data.
25	(Image_scn_mem_discardable or 02000000 h) data in the section will be discarded after the process starts. The. reloc section containing the relocated table in the preceding example is an example.
26	(Image_scn_mem_not_cached or 04000000 h) the data in section is not cached.
27	(Image_scn_mem_not_paged or 08000000 h) the data in section is not exchanged to the disk.
28	(Image_scn_mem_shared or 10000000 h) indicates that the data in the section will be shared by different processes. This attribute flag is set in the section sharing data in the hook example in Chapter 11th.
29	(Image_scn_mem_execute or 20000000 h) the page mapped to the memory contains executable attributes.
30	(Image_scn_mem_read or 40000000 h) pages mapped to memory contain readable attributes
31	(Image_scn_mem_write or 80000000 h) the page mapped to the memory contains writable attributes.

The attributes of a code section are generally 60000020 H, that is, executable, readable, and "code contained in the section". The attributes of a data section are generally c0000040h, that is, it is readable, writable, and "contains initialized data", while the constant section (corresponding to. const segment) is 40000040 H, that is, readable and "contains initialized Data". The attributes of the resource section are generally the same as those of the constant section.

Of course, the definition of section attributes is not necessarily these values. For example, when a PE file is compressed by a compression tool, sections containing code are usually set with executable, readable, and writable attributes at the same time, because the decompressed part needs to write the decompressed code back to the code segment. Readers can make an experiment: writing data to the code segment in a program. After the compilation link is complete, an exception will be thrown. However, compression using UPX and other compression software will be executed again, the file can be executed normally. This is because the compression software sets the attribute of the section to writable for decompression purposes.

PE file format-section and section table