Dissecting the PE File Format - 4

THE SECTION TABLE

After the PE header, we have an array of IMAGE_SECTION_HEADER structures, each containing information about one section in the PE file, such as its attribute and virtual offset. The structures are 40 bytes each and there is no padding between them.

Name1 - (8 bytes). Just a label and can be blank.

VirtualSize - The actual size of the section's data in bytes. This may be less than the size of the section on disk (SizeOfRawData) and will be what the loader allocates in memory for this section.

VirtualAddress - The RVA of the section. The PE loader examines and uses this value in this field when it's mapping the section into memory. Thus, if this is 1000h and the PE file is loaded at 400000h, the section is loaded at 401000h

SizeOfRawData - The size of the section's data in the file on disk, rounded up to the next multiple of file alignment by the compiler.

PointerToRawData (raw offset) very useful as its the offset from the file's beginning to the section data. If 0, the sections data are not contained in the file.
Characteristics - Contains flag to indicate if it contains executable code, initialized data, can it be written or read from etc.

You can bypass the PE header and search for the section name in the hex editor. After the section headers we find the section themselves. In the file on disk, each section starts as an offset that is multiple of the FileAlignment value found in the OptionalHeader. Between each header you'll find a 00 byte padding.
When loaded in RAM, the sections always start at page boundaries so that the first byte of each section corresponds to a page. On x86 CPUs are 4kB aligned, whilst on IA-64 they are 8kB aligned. This alignment value is stored in SectionAlignment in OptionalHeader.
You can find the sections with PointerToRawData or VirtualAddress, and you need not bother with alignments.

In the next post, we talk about the various PE file sections.