Loading PE Executable - Empty Space Before First Section

[yasar11732]

Hi,

I am studying how PE executables are loaded to memory and executed. I am using

Code: Select all

dumpbin.exe /ALL <simple_program.exe>

output, along with online resources. This part of dumpbin output struck me as odd;

SECTION HEADER #1
.text name
F23 virtual size
1000 virtual address (00401000 to 00401F22)
1000 size of raw data
400 file pointer to raw data (00000400 to 000013FF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
Code
Execute Read

According to this, first section to load is .text section, and it is put 4KB after the image base. Does that mean, when this exe is loaded to memory, first 4KB of the image is empty? Is it used for something?

Best Regards,

[BenLunt]

As for the file, it has no concern.

However, if your loader marks the first 4k page as non-existent, any NULL pointers in your code will trigger a GPF. Therefore, you can't place any code or data in the first 4k of your app.

This is to keep NULL pointers from writing to wrong memory areas.

Ben
- https://www.fysnet.net/osdesign_book_series.htm

[zaval]

nothing odd, it's for headers, you forgot about them? if you don't want to map them, you may skip this and not map that page. nothing inside of your executable itself references that part of the image. if, say, the base is A, then the 1st mapped page would be A + 0x1000 (.text, that is). if you want (need) to keep headers in memory, you place them exactly there, at the page A. the headers mainly are needed for loading, but maybe, depending on the application, you'll need info stored there later. if so, map headers at the image base.

[yasar11732]

Thanks for the replies.

I took memory dump of a running program and inspected it in a debugger. First page is indeed filled with headers.

I had assumed headers wouldn't be loaded because executable don't need it. But as you hinted, maybe OS needs it to be there.

Best Regards,

[alexfru]

I took memory dump of a running program and inspected it in a debugger. First page is indeed filled with headers.

I had assumed headers wouldn't be loaded because executable don't need it. But as you hinted, maybe OS needs it to be there.

There may be embedded resources within the file (e.g. icons/images) and they can be located through the information contained in the headers.

[nexos]

There may be embedded resources within the file (e.g. icons/images) and they can be located through the information contained in the headers.

True, but resources, export tables, import tables and so on can all be accessed through sections as well. Resources are in ".rsrc", imports in ".idata", and exports in ".edata". You don't need the data directories per se.

In reality, the first page isn't mapped to a section because of null pointer accesses.

nothing odd, it's for headers, you forgot about them? if you don't want to map them, you may skip this and not map that page. nothing inside of your executable itself references that part of the image. if, say, the base is A, then the 1st mapped page would be A + 0x1000 (.text, that is). if you want (need) to keep headers in memory, you place them exactly there, at the page A. the headers mainly are needed for loading, but maybe, depending on the application, you'll need info stored there later. if so, map headers at the image base.

There isn't anything in the headers strictly needed after load time. As I said above, data directories can be accessed through sections. All the other things are only relevant to the loader.

[zaval]

True, but resources, export tables, import tables and so on can all be accessed through sections as well. Resources are in ".rsrc", imports in ".idata", and exports in ".edata". You don't need the data directories per se.

okay, then explain, how you are going to find where that .rsrc section resides? for example, for FindResourceEx()/LoadResource()/LockResource() API functions. anything like this, that will be processed at the runtime, would need to look into the headers. delayed loading as well.

In reality, the first page isn't mapped to a section because of null pointer accesses.

this is purely theoretical, since image base (neither prefered nor resulting) for the main .exe files of user mode programs never is 0. let alone - the kernel image.

[linguofreak]

In reality, the first page isn't mapped to a section because of null pointer accesses.

this is purely theoretical, since image base (neither prefered nor resulting) for the main .exe files of user mode programs never is 0. let alone - the kernel image.[/quote]

Indeed: I think NT by policy keeps the entire first 64k unmapped as protection against null pointer accesses, so if the first page after the headers were at 0x1000, it would be in the unmapped region. And even then, the first section of an executable is generally well above whatever null pointer trap the OS has set up.