Lately I've been working on the PE file format and I noticed this weird thing.

According to Microsoft's PE documentation, the object table entry field PHYSICAL SIZE is:

PHYSICAL SIZE = DD Physical file size of initialized data. The size
of the initialized data in the file for the object. The physical
size must be a multiple of the File Align field in the PE Header, and
must be less than or equal to the Virtual Size.

Notice the last sentence. Now, let's take a Visual C++ generated executable and check its fields:

SECTION HEADER #1
.text name
5A35 virtual size
1000 virtual address
6000 size of raw data

(I used DumpBin to dump the PE information)
In this case, the Physical Size field was GREATER than the Virtual Size.

Can anyone explain?

PS. If you are wondering "How can this file be loaded then", it's because the bytes after the Virtual Size position are the alignment bytes and are not important.

Hi death,

Why the Physical file size is Greater then the Virtual Size?
Dunno, because VC++ wants that...? hehe

Anyway, i know that the Virtual Size gets rounded up to the multiple of the Section Alignment when allocated, so then it becomes the same as the Physical file size

VC++ could maybe do 2 things:

1. It thought that the Virtual Size is the Physical Size and Vice Versa... (As in most programs it's in reverse, Virtual Size nicely rounded up and the Physical Size is the exact Size )

2. Or maybe it thought let's do it in reverse and put the exact Size in the Virtual Size field (Who cares, gets rounded anyway) and the Physical Size just aligns to the next Section (Maybe to make full advantage of the Section? )

Hehe, I hope this helps a bit...(Or did i confuse you?)

Cya...

CoDe_InSiDe

death...


as in ... [EXECUTION] ????

...Have Phun, Always.

Hi code_inside,
anyway if i remember right if pe has physical size greater than virtual size wont be opened by procdump telling u the file is corrupted
That means its not normal having such a thing
anyway phys size < virtual size
phys size should be the exact lenght of the data/code
virtual size should be the mem to allcate to contain all the data/code in the section and thats of coz rounded up
If virtual size < phys size it should mean not all the data/code in the section will be loaded

See ya
NikDH

Microsoft has a vague format I must say. So read in between the lines. If the virtual size is larger, then there is uninitialized data. If the virtual size is smaller, not all the initialized data will be loaded. Microsoft likes to break its own rules. I would doubt that the sizes actually have to be multiples. If I wrote the format and wanted to enforce that easily without even having checks be necessary, I would just have physical size entered in multiples not in bytes (0x1000 means 0x1000 blocks not 0x1000 bytes). But thats just me.

Snatch

To clarify, the physical size is aligned to the file alignment field and the virtual size is aligned to the section alignment field once loaded (like CoDe_InSiDe said). The padded bytes are not always part of the section, which produces garbage bytes between the sections. Also, I just posted this message to point out Microsoft's quirks. There are alot more PE obscurities

aimless: Yep.