PE File Format - What is between the section table and the first section?

Question

When looking at PE files in a hex editor, I often encountered some bytes between the section table and the first section, which doesn't really make sense to me. As far as I am concerned, there should be a 00-byte padding in order to fit the alignment. However, here is a screenshot which demonstrates the opposite:

As it turned out the highlighted block is pretty much the Bound Import Table. But I am still confused. Why is this table not located in a section? Is this always the case or is it just the specification of a certain compiler/linker? I did not find any documentation on this specific issue. Everything one can find on this topic basically says:

1. DOS MZ Header
2. DOS Stub
3. PE Header
4. Section Table
5. Section 1
6. Section 2
7. Section 3

... and so on

Before I encountered this issue I was not even aware of the fact, that there can be things outside of the sections (besides the ones i listed above, of course).

[EDIT]

Proof of concept (Since Mox did not believe me):

Answer 1

Data directories such as the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT can exist outside of sections. Another example of a data directory existing outside of any known section would be the IMAGE_DIRECTORY_ENTRY_CERTIFICATE data directory which is the data directory used to store the certificate information when an executable is signed.

Data directories can point to data outside of a section, with-in a section, or they can point to the entire section. The IMAGE_DIRECTORY_ENTRY_RESOURCE data directory points to the entire ".rsrc" section. Certain data directories point to known sections and these are documented in the PE format specification by Microsoft.

Answer 2

Items like the bound import table can be written wherever the linker wants to put them in the raw image. It just overwrites the zero bytes with the table and makes the pointer correct in the data directory. You could probably even overwrite the middle of the DOS header or stub with the import table and it would work as long as the pointer in the directory was correct.

Answer 3

As far as I can see with LordPe, the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entry of iexplore.exe is empty.

Answer 4

both 32bit and 64bit versions of IEXPLORE.EXE don't have IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entries.

Here a snaphot of LordPE, showing the 64bit version of IEXPLORE.EXE on a Windows 7 machine and (in green) the missing IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entry:

It looks like you don't look at the right directory entry.