PE Loader Questions

[gigaman]

Why isn't it a gap? I suppose we should define what a "gap" actually is first...

As the ntdll.dll example shows, when the virtual size of a section is considered rounded up to the section size (0x10000 in this case), then there really isn't any gap between the addresses. But since the PE loader actually rounds the virtual size up to the page size only (0x1000) when mapping the image, then there are unallocated/inaccessble blocks of memory between the sections (and it has nothing to do with the physical size, SizeOfRawData, it's all about virtual addresses and sizes). I would probably call it a gap, but yes, it's a bit special

[pp2]

Originally Posted by gigaman

But since the PE loader actually rounds the virtual size up to the page size only (0x1000) when mapping the image...

PE Loader rounds virtual size to "Section Alignment" value, which is specified in header. On NT even user-space programs can have virtual alignment not only on 4096 bytes, but on 4 bytes, for example. Whole page is reserved in this case by loader, and sections with different access rights must be aligned on physical page boundaries, cause you cannot make 32 first bytes just read/write, and other 32 bytes only read/executable

[gigaman]

No, it doesn't - check the example given above in debugger or vmmap.
Note that we're talking about a case when section alignment, as specified in PE header, is actually bigger than one page.

[Killboy]

I don't understand why they designed such a loose and bug-ridden format in the first place.
What's the point of having weird undocumented behaviour that dramatically affects compatibility and even worse, changes across OS versions.

Give this a read, if you haven't seen it already: http://reversinglabs.com/advisory/pecoff.php

If that doesn't make you curl up on the floor and weep like a 5 year-old, kudos to you good sir