[R00tKit]

hi

in shared section:

Code: Select all

#pragma comment(linker, "/SECTION:.shared,RWS")
#pragma data_seg(".shared")
int g_iShared = 0;
#pragma data_seg()

how windows know this section already is created so it must just re-map section in new program?

i run this code and after run i rename exe file name but again it just remap section ( program know g_iShared old value )
but new copy of exe just create new section and g_iShared start from zero

so i think it must be 2 layer to check if section just need remap : one for image file ( file pointer ? ) and second for section ( Prototype PTEs ? ) in that image
and it was possible ( force it and loader think it need remaping like shared section ) loader remap memory of other program in my exe ?

Code: Select all

#include<Windows.h>
#include<stdio.h>

#pragma comment(linker, "/SECTION:.shared,RWS")
#pragma data_seg(".shared")
int g_iShared = 0;
#pragma data_seg()

int main()
{
	g_iShared++;
	printf("number is %x",g_iShared);

	getchar();	
}

[r2nwcnydc]

how windows know this section already is created so it must just re-map section in new program?

It does this the same way it does for the windows DLLs.

0x10000000 This section is shareable. When used with a DLL, the data in this section will be shared among all processes using the DLL. The default is for data sections to be nonshared, meaning that each process using a DLL gets its own copy of this section's data. In more technical terms, a shared section tells the memory manager to set the page mappings for this section such that all processes using the DLL refer to the same physical page in memory. To make a section shareable, use the SHARED attribute at link time.

i run this code and after run i rename exe file name but again it just remap section ( program know g_iShared old value )
but new copy of exe just create new section and g_iShared start from zero

I would assume this mapping is based off of the file's object id, not it's name. So when you rename the file, the object id stays the same. However, when you make a copy of the exe, the copy has a new unique object id assigned to it. So the mapping must be created.

[R00tKit]

tnx
yes i check it file matching is base on file ID

It does this the same way it does for the windows DLLs.

can you give more info plz ?
for section it how it track
regard

[r2nwcnydc]

The best I could find is MiFindImageSectionObject is used to determine if the image is already mapped into memory.

Page 111. Moving on, MiFindImageSectionObject is now called to check if
the file has already been Memory Mapped into a Section Object

It looks like in the _FILE_OBJECT there is a member SectionObjectPointer which has a member DataSectionObject which points to the _CONTROL_AREA for the image. This gets set by MiFindImageSectionObject in NtCreateSection when the SEC_IMAGE attribute is specified.

I don't know how it manages the individual sections/pages though. Hopefully this helps; if for nothing else as a starting point for you.

[R00tKit]

tnx r2nwcnydc :)

[R00tKit]

I would assume this mapping is based off of the file's object id, not it's name

object id of file is optional and modifiable so i think it was file id

Code: Select all

FSCTL_CREATE_OR_GET_OBJECT_ID
FSCTL_SET_OBJECT_ID
FSCTL_DELETE_OBJECT_ID

but file id is uniq :

Code: Select all

BY_HANDLE_FILE_INFORMATION + GetFileInformationByHandle 

[GamingMasteR]

File ID is filesystem but not OS specific, and it's supported in NTFS only.

[R00tKit]

tnx GamingMasteR
object id of file is optional and File ID is filesystem but not OS specific, and it's supported in NTFS only.

rename and cut file dont affect of shared memory ( i.e after rename or cut file shared memory just get remap but copy file make new section )
so how windows make file unique ? maybe it was based on file manager cache Mechanism

[Vrtule]

I think that NTFS implements File ID as index of base MFT record of the file. Objrect ID is, on my opinion, represented by a MFT attribute in the MFT record.

When you rename a file (or directory), only name associated with the MFT record changes. When you copy a file, new MFT record(s) must be allocated hence File ID of the new copy is different from original.

[aionescu]

File ID is MFT-based, and exists on FAT too (not MFT based, obviously). Object ID is a special NTFS meta-data $O, I believe. Also exists on ReFS, but not FAT.

How the OS "knows" that a File Object already has a section object is through the SECTION_OBJECT_POINTERS and is Fs/Cc specific. Usually it's implemented through some internal FCB-like knowledge.

--
Best regards,
Alex Ionescu