Official way to hook GetMappedFileNameW in kernel?

NTFSD
1

Hi,

I found an issue in my SFO driver. When an app calls GetMappedFileNameW, it gets the redirected name instead of the upper FO name.

Doing a research, I found:

A) The call to NtQueryVirtualMemory gets a MMVAD struct and then obtains a pointer to the CONTROL_AREA struct to get the associated FileObject. ZwCreateSection (and cache manager) creates that struct but it is undocumented.

B) Another approach was to hook the OB_QUERYNAME_METHOD by retrieving FileObject’s OBJECT_HEADER, OBJECT_TYPE and OBJECT_TYPE_INITIALIZER info. A file in latests Windows Kit (10.0.10586.0\um\minwin\ntosp.h) has the struct data but not sure it they are compatible with previous versions.

Both methods involves hooking and/or using undocumented (or poorly documented) data. Is there another way to accomplish this?

Thanks,
Mauro.

2

Forgot to mention:

C) To hook ZwQueryVirtualMemory.

But still think I’m playing with fire.

3

Are you saying you see the lower, redirected FO in the control_area
structure? Are you possibly initializing caching using the redirected
FO?

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: xxxxx@mauroleggieri.com.ar
To: “Windows File Systems Devs Interest List”
Sent: 4/18/2016 2:37:51 PM
Subject: [ntfsd] Official way to hook GetMappedFileNameW in kernel?

>Hi,
>
>I found an issue in my SFO driver. When an app calls
>GetMappedFileNameW, it gets the redirected name instead of the upper FO
>name.
>
>Doing a research, I found:
>
>A) The call to NtQueryVirtualMemory gets a MMVAD struct and then
>obtains a pointer to the CONTROL_AREA struct to get the associated
>FileObject. ZwCreateSection (and cache manager) creates that struct but
>it is undocumented.
>
>B) Another approach was to hook the OB_QUERYNAME_METHOD by retrieving
>FileObject’s OBJECT_HEADER, OBJECT_TYPE and OBJECT_TYPE_INITIALIZER
>info. A file in latests Windows Kit (10.0.10586.0\um\minwin\ntosp.h)
>has the struct data but not sure it they are compatible with previous
>versions.
>
>Both methods involves hooking and/or using undocumented (or poorly
>documented) data. Is there another way to accomplish this?
>
>Thanks,
>Mauro.
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>

4

Hi Peter,

I don’t do any call to “Cc”. The lower FO does. All seems working fine and fast (except for this).

I was afraid to generate a conflict if I call to CcInitializeCacheMap because, as I saw in fastfat sample, the lower driver makes calls to Cc with internal driver data.

Should also handle IRP_MJ_ACQUIRE_xxx/IRP_MJ_RELEASE_xxx myself instead of passing it down?

Regards,
Mauro.