What is special about SEC_IMAGE in CreateFileMapping

I noticed that when I map a PE file by specifying SEC_IMAGE in CFM the data mapped is different with the mapping done without sec_image flag. Any specific reasons, why?

details:

I wrote some code to parse on disk PE files. I noticed a difference when i map the file specifying SEC_IMAGE in CFM and without SEC_IMAGE in CFM. The difference was in the data which is mapped. following code works fine when sec_image is specified and raise exception when not. I checked the exception and found that the members of descriptor pointer are all coming junk and hence accessing them results in an exception.

dosHeader = mapped file address;

PIMAGE_NT_HEADERS ntHeader = (PIMAGE_NT_HEADERS)((BYTE*)dosHeader+dosHeader->e_lfanew);

IMAGE_IMPORT_DESCRIPTOR *descriptor = (IMAGE_IMPORT_DESCRIPTOR*)((BYTE*)dosHeader + ntHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);

In fact if i try reading data through ReadFile the data returned is identical to the data returned when SEC_IMAGE is not specified in mapping. What is so special in SEC_COMMIT.

Thanks
Aditya

IIRC SEC_IMAGE is for mapping it as as executable image just in a way it
would be mapped by loader itself for execution.

That means each sections of the PE image are occupy integral number of
pages.
And no two sections of PE image share a common page.

SEC_COMMIT – As MSDN says commits (and not reserve) from memory or
pagefile.

Regards
Deepak

On Thu, May 14, 2009 at 2:01 PM, wrote:

> I noticed that when I map a PE file by specifying SEC_IMAGE in CFM the data
> mapped is different with the mapping done without sec_image flag. Any
> specific reasons, why?
>
> details:
> ===============
> I wrote some code to parse on disk PE files. I noticed a difference when i
> map the file specifying SEC_IMAGE in CFM and without SEC_IMAGE in CFM. The
> difference was in the data which is mapped. following code works fine when
> sec_image is specified and raise exception when not. I checked the exception
> and found that the members of descriptor pointer are all coming junk and
> hence accessing them results in an exception.
>
> dosHeader = mapped file address;
>
> PIMAGE_NT_HEADERS ntHeader =
> (PIMAGE_NT_HEADERS)((BYTE*)dosHeader+dosHeader->e_lfanew);
>
> IMAGE_IMPORT_DESCRIPTOR descriptor =
> (IMAGE_IMPORT_DESCRIPTOR
)((BYTE*)dosHeader +
> ntHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);
> ======================
>
> In fact if i try reading data through ReadFile the data returned is
> identical to the data returned when SEC_IMAGE is not specified in mapping.
> What is so special in SEC_COMMIT.
>
> Thanks
> Aditya
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Thanks Deepak,

>IIRC SEC_IMAGE is for mapping it as as executable image just in a way it would be mapped by loader itself for execution.

I was also thinking in this direction, is there some alternative to achieve same effect, i mean retrieving data as loader loads without using CFM. I am looking for an alternative because of some specific malwares.

SEC_COMMIT- Please ignore this, I never meant to write sec_commit, was just re-writing the question on sec_image. This probably happens as now days my mind is floating in too many directions at same time, :frowning:

Aditya

I was also thinking in this direction, is there some alternative to achieve

same effect, i mean retrieving data as loader loads without using CFM. I am
looking for an alternative because of some specific malwares.

Yes there is an alternative.
Read the whole file using ReadFile
Now write a PE parser.
You will have to write a code which will read the section headers which
follows just after OPTIONAL_HEADER (if I am correct).
Using the information from section headers, local system page size , Section
Alignment (from OPTIONAL_HEADER) and File Alignment (from OPTIONAL_HEADER)
you can determine how many pages each section is going to occupy.
Also you can determine each section’s RVA (relative virtual address) with
the help of these values.

Well I assume you already had a look at an age old article (but still a
informative one) from Matt Pietrek
http://msdn.microsoft.com/en-us/magazine/ms809762.aspx

Regards
Deepak

>I noticed that when I map a PE file by specifying SEC_IMAGE in CFM the data mapped is different

SEC_IMAGE:

  • reads the PE header and validates it, it will fail if PE header is not valid
  • extracts the section table from the PE header
  • maps the binary according to the section table.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com