PE detailed block table (section table) and block (section) (PE detailed 04)

So far, the turtle and everyone has learned a lot about the DOS header and PE header. Next it is the turn of the sectiontable (block table, also a section table). (Video tutorial: http://fishc.com/a/shipin/jiemixilie/)

The more you learn more structure, we may feel that PE is quite miscellaneous ha, so here is a bit of the necessary knowledge of the detailed comments, we can see as needed.

PE file-to-memory mapping

When executing a PE file, Windows does not read the entire file into memory at the beginning, and 20 uses a mechanism similar to the memory-mapped file. In other words, the Windows loader simply establishes a mapping between the virtual address and the PE file when it is loaded.
This page is submitted from disk to physical memory only if it is actually executed to an instruction in a memory page or access to data on a page, which makes the file mount speed and file size not much related.

Note, however, that the way the system loads the executable is not exactly the same as the memory-mapped file.
When using the memory-mapped file, the system is quite faithful to the "original", if the disk file and memory image comparison, you can find whether the data itself or the relative position between the data it is all the same ya ya are identical.
And we know that when loading an executable file, some data will be preprocessed before loading, such as relocation, and so, the relative position of the data may change subtly after loading.

The Windows loader does not perform any special processing in the Mount DOS section, the PE file header section, and the section table (block table), while the loading section (chunk) automatically handles the different processing of the section (chunk) properties.
In general, it handles the following aspects:

• The properties of the memory page;
• The offset address of the section;
• The size of the section;
• A section that is not mapped.

Properties of Memory Pages:

For disk mapping files, all pages are set according to the properties specified by the disk mapping file function. However, when loading the executable file, the memory page properties corresponding to the section are set according to the section's properties. Therefore, in memory pages that belong to a module, the properties of the memory pages mapped from different sections are different.

Offset address of the section:

The start address of the section is aligned in the disk file according to the value of the FileAlignment field of the IMAGE_OPTIONAL_HEADER32 structure, and when loaded into memory, is based on the value of the Sectionalignment field in the same structure, The value of the two may be different, so the offset from the file header and the offset in the disk file may be different when a section is loaded into memory.

Notice that the section is actually a combination of the same attribute data! When a section is loaded into memory, the memory pages for the same section are given the same page properties, in fact, the Windows system's settings for memory properties are in pages, so the snap units in memory for a section must be at least one page in size. (Small turtle Warm tip: for 32-bit operating system, this value is generally 4kb==1000h; This value is typically 8kb==2000h for 64-bit operating systems)

There is no such thing on disk, because what is the primary cause of emissions on disk? It must be space-driven, where the disk is simply stored, not used, so no detailed properties are set. Just imagine, if the disk is in 4KB for the size of the alignment, not enough to fill with the zero, then a only 20 bytes of data will consume 4KB of space to store, is not a waste? Is there any wood??

The size of the section:

The size of the section of the treatment is divided into two main aspects:

The first aspect, as we have just said, is that the length extension is different due to the difference of the section-aligned storage units in the disk image and memory image (the number of 0 fills varies);

The second aspect is the handling of a section that contains uninitialized data. Since it is uninitialized, it is not necessary for it to waste space resources on disk, but in memory different, because the program is running, the previously uninitialized data is likely to be assigned to initialize, then you must leave space for them.

Sections that are not mapped:

Some sections do not need to be mapped into memory, such as the. reloc section, where relocation data is transparent to the execution code of the file, is not useful, it simply provides the Windows loader with which the execution code simply does not access them, so it is not necessary to map them to physical memory.

Well, some of the above knowledge is believed to be a supplement and extension of our previous studies. We may feel familiar with the above knowledge, but also feel a bit strange. That is of course, the small turtle teaching follows the idea is today's knowledge to learn it today, tomorrow's things to learn tomorrow! Suddenly you can not accept so deep things, like the above things if the first to explain, then I am afraid a lot of friends will not continue to look down (confused see only two fog, ha ~), so I learn to follow the cycle of gradual, some focus separate to repeat the explanation, although repeated, But every time it goes down a little bit to make it easier for everyone to accept.

We can go on, and then the section table, also known as the chunk table:

Section table (Block table):

The properties of all sections in the PE file are defined in the section table, which is arranged by a series of image_section_header structures, each of which describes a section, the order in which the structure is arranged, and the order in which the sections they describe are consistent in the file. All valid structures end with an empty image_section_header structure, so the total number of Image_section_header structures in the section table equals the number of nodes plus one. The section table is always stored in the location immediately following the PE file header.

In addition, the total number of Image_section_header structures in the section table is always specified by the Fileheader.numberofsections field in the PE file header image_nt_headers structure.

typedef struct _IMAGE_SECTION_HEADER

{

BYTE Name[image_sizeof_short_name]; Section table name, such as ". Text"

Image_sizeof_short_name=8

Union
{

DWORD physicaladdress; Physical Address

DWORD VirtualSize; True length, these two values are a joint structure that can be used by any one of them, a

It's like taking the latter one.

} Misc;

DWORD virtualaddress; RVA Address for section area

DWORD Sizeofrawdata; Dimensions after alignment in a file

DWORD Pointertorawdata; The offset in the file

DWORD pointertorelocations; Used in obj files, relocation offset

DWORD pointertolinenumbers; Offset of the row number table (for debugging purposes)

WORD numberofrelocations; Used in obj files, number of relocation items

WORD numberoflinenumbers; Number of row numbers in line number table

DWORD characteristics; Section properties such as readable, writable, executable, etc.} image_section_header, *pimage_section_header;

PE detailed block table (section table) and block (section) (PE detailed 04)