Hi experts,
In my file system filter driver, in the HookCreateSection() I can get the path of the required file *.dll. How can I know which
exe file or which process is accessing the required file?
Thanks!
cxun
AFAIK, there is no way to know it…
Although section creation is a synchronous operation, pre-acquire and post-acquire callbacks don’t seem to be invoked in context of a thread that actually makes a call to ZwCreateSection(). To make things even worse, there does not seem to be one-to-one correspondence between a call to CreateSection() and callback invocation. No wonder that controlling process creation on pre-Vista OS versions had to be achieved via hooking - unfortunately, the existing callback model seems to be grossly inadequate for actually controlling section creation in FS filter driver…
Anton Bassov
Hi Anton!
You are correct in saying that controlling process creation & DLL mapping is not straight forward pre-Vista.
However, if you really want to get away from hooking, you do (comment on the word “do” later) have a technique. Just check for FILE_EXECUTE flag in Create Options in your pre-create callback.
The word do : Most of the times, you see this flag in your pre-create when a file execution or image-mapping has been requested. However, on some SP of some Windows OS (don’t remember exactly, but I once saw it in Windows 2003 SP2 for Itanium processor) you may also see this flag even when you see the properties of a file in explorer. 
To the OP:
You may use the above technique. And as far as the seeing the properties is concerned, even if you deny the pre-create with FILE_EXECUTE flag, explorer.exe re-tries the operation without this flag.
Regards,
Ayush Gupta
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, June 26, 2008 3:16 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] How can I know who is calling the DLL files?
AFAIK, there is no way to know it…
Although section creation is a synchronous operation, pre-acquire and post-acquire callbacks don’t seem to be invoked in context of a thread that actually makes a call to ZwCreateSection(). To make things even worse, there does not seem to be one-to-one correspondence between a call to CreateSection() and callback invocation. No wonder that controlling process creation on pre-Vista OS versions had to be achieved via hooking - unfortunately, the existing callback model seems to be grossly inadequate for actually controlling section creation in FS filter driver…
Anton Bassov
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com
>Just check for FILE_EXECUTE flag
Are you sure you understand what we are speaking about??? When you control process creation normally you want to know WHO attempts to launch it, because different users may have different permissions. Therefore, you normally would want to get an ID of a process that calls ZwCreateSection(). Please read the OP’s question carefully -he is not asking us about making a distinction between mapping the target DLL as either a data section or an image one. Instead, he asks us how to discover the requestor’s PID, and, unfortunately, you cannot any info about it in pre-create callback…
Anton Bassov
Hi Anton!
Are you sure you understand what we are speaking about???
When you control process creation normally you want to know WHO attempts to
launch it, because different users may have different permissions.
If I got it correctly, the OP wants to find out who launched the process or mapped the DLL
Therefore, you normally would want to get an ID of a process that calls
ZwCreateSection().
Before ZwCreateSection is called to map the executable in the address space, a create will be sent for that executable. There, you will see FILE_EXECUTE flag.
Please read the OP’s question carefully -he is not
asking us about making a distinction between mapping the target DLL as
either a data section or an image one.
I never mentioned anything about data section or image section. But ya, the executable needs to be opened with FILE_EXECUTE flag (as an image section) to create a process from it.
Instead, he asks us how to
discover the requestor’s PID, and, unfortunately, you cannot any info
about it in pre-create callback…
And I thought the BEST place to get the requestor’s PID was PRE-CREATE callback…
Also, if the sole aim is to know the PID of the process that is mapping the DLL, you can register a load image notification routine using PsSetLoadImageNotifyRoutine.
Regards,
Ayush Gupta
> And I thought the BEST place to get the requestor’s PID was PRE-CREATE callback…
Well, I used to think this way as well - after all, this is the very first ithing that gets into one’s head.
However, after a bit of experimentation you may discover that. in actuality, things are not necessarily that simple, because the callback does not seem to get always invoked in context of the thread that calls ZwCreateSection() as one would normally expect to happen. After all, if things were so straightforward the OP would not ask his question, in the firt place…
Also, if the sole aim is to know the PID of the process that is mapping the DLL, you can
register a load image notification routine using PsSetLoadImageNotifyRoutine.
However, at this point you cannot already do anything - this is nothing more than notification.
In other words, pre-create section callback allows you to block section creation but does not allow you to discover requestor’s PID, while notification callback informs you about PID but does not allow to block creation (on pre-Vista OSes, of course). However, controlling process creation normally requires both features…
Anton Bassov
Oops… A lot of confusion…
When I said Pre-Create, I meant “Pre-Create” callback (the one that is the result of ZwCreateFile/ NtCreateFile) and not Pre callback for acquire-for-section-synchronization.
And hence, I was telling all the stuff about getting requestor PID and FILE_EXECUTE flag, in context of the “PRE callback for IRP_MJ_CREATE”…
True, that Load image notification is “JUST” a notification and you can’t do anything to control the process creation/ image mapping from that notification routine.
However, since you can’t possibly do anything from that notification routine AND if you want to get away from HOOKING, a way out could be doing stuff in Pre-callback for IRP_MJ_CREATE.
I hope I put it in a much better way this time… 
Regards,
Ayush Gupta
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-328210-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, June 26, 2008 8:39 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] How can I know who is calling the DLL files?> And I thought the BEST place to get the requestor’s PID was PRE-
CREATE callback…Well, I used to think this way as well - after all, this is the very
first ithing that gets into one’s head.However, after a bit of experimentation you may discover that. in
actuality, things are not necessarily that simple, because the callback
does not seem to get always invoked in context of the thread that calls
ZwCreateSection() as one would normally expect to happen. After all, if
things were so straightforward the OP would not ask his question, in
the firt place…> Also, if the sole aim is to know the PID of the process that is
mapping the DLL, you can
> register a load image notification routine using
PsSetLoadImageNotifyRoutine.However, at this point you cannot already do anything - this is nothing
more than notification.In other words, pre-create section callback allows you to block
section creation but does not allow you to discover requestor’s PID,
while notification callback informs you about PID but does not allow to
block creation (on pre-Vista OSes, of course). However, controlling
process creation normally requires both features…Anton Bassov
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsYou are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com
> When I said Pre-Create, I meant “Pre-Create” callback (the one that is the result of ZwCreateFile/ >NtCreateFile) and not Pre callback for acquire-for-section-synchronization.
Well, from the very beginning this thread was speaking about section synchronization callback, so that if you were speaking about IRP_MJ_CREATE your posts are a bit off-topic…
However, since you can’t possibly do anything from that notification routine AND if you want to get away >from HOOKING, a way out could be doing stuff in Pre-callback for IRP_MJ_CREATE.
There is no guarantee that a user who opens an executable file for whatever access is about to launch a process, so that any conclusions are still premature at this stage. In order to be sure you have to wait at least until the caller wants to create an image section with PAGE_EXECUTE protection. Otherwise, you can easily make a fool out of yourself…
Anton Bassov
Thank you all very much.
I tried it in PsSetLoadImageNotifyRoutine. Now I can easily get the Process Id who is calling the requested dll file. But I need to
get the file path matching the process Id. I’ve looked for the functions in ifs but failed. Do you know how to achieve this?
Thank you all~
cxun
From:
Sent: Thursday, June 26, 2008 11:08 AM
To: “Windows File Systems Devs Interest List”
Subject: RE:[ntfsd] How can I know who is calling the DLL files?
>
>> And I thought the BEST place to get the requestor’s PID was PRE-CREATE callback…
>
> Well, I used to think this way as well - after all, this is the very first ithing that gets into one’s head.
>
> However, after a bit of experimentation you may discover that. in actuality, things are not necessarily that simple, because the
> callback does not seem to get always invoked in context of the thread that calls ZwCreateSection() as one would normally expect to
> happen. After all, if things were so straightforward the OP would not ask his question, in the firt place…
>
>
>> Also, if the sole aim is to know the PID of the process that is mapping the DLL, you can
>> register a load image notification routine using PsSetLoadImageNotifyRoutine.
>
>
> However, at this point you cannot already do anything - this is nothing more than notification.
>
> In other words, pre-create section callback allows you to block section creation but does not allow you to discover requestor’s
> PID, while notification callback informs you about PID but does not allow to block creation (on pre-Vista OSes, of course).
> However, controlling process creation normally requires both features…
>
>
>
> Anton Bassov
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@live.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
You can track the process name from the same image notification routine.
The first notification in context of a particular process is that for the image which is used to launch it.
Regards,
Ayush Gupta
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-328225-
xxxxx@lists.osr.com] On Behalf Of cxun
Sent: Thursday, June 26, 2008 10:31 AM
To: Windows File Systems Devs Interest List
Subject: Re: RE:[ntfsd] How can I know who is calling the DLL files?Thank you all very much.
I tried it in PsSetLoadImageNotifyRoutine. Now I can easily get the
Process Id who is calling the requested dll file. But I need to
get the file path matching the process Id. I’ve looked for the
functions in ifs but failed. Do you know how to achieve this?Thank you all~
cxun
From:
> Sent: Thursday, June 26, 2008 11:08 AM
> To: “Windows File Systems Devs Interest List”
> Subject: RE:[ntfsd] How can I know who is calling the DLL files?
>
> >
> >> And I thought the BEST place to get the requestor’s PID was PRE-
> CREATE callback…
> >
> > Well, I used to think this way as well - after all, this is the very
> first ithing that gets into one’s head.
> >
> > However, after a bit of experimentation you may discover that. in
> actuality, things are not necessarily that simple, because the
> > callback does not seem to get always invoked in context of the thread
> that calls ZwCreateSection() as one would normally expect to
> > happen. After all, if things were so straightforward the OP would not
> ask his question, in the firt place…
> >
> >
> >> Also, if the sole aim is to know the PID of the process that is
> mapping the DLL, you can
> >> register a load image notification routine using
> PsSetLoadImageNotifyRoutine.
> >
> >
> > However, at this point you cannot already do anything - this is
> nothing more than notification.
> >
> > In other words, pre-create section callback allows you to block
> section creation but does not allow you to discover requestor’s
> > PID, while notification callback informs you about PID but does not
> allow to block creation (on pre-Vista OSes, of course).
> > However, controlling process creation normally requires both
> features…
> >
> >
> >
> > Anton Bassov
> >
> > —
> > NTFSD is sponsored by OSR
> >
> > For our schedule debugging and file system seminars
> > (including our new fs mini-filter seminar) visit:
> > http://www.osr.com/seminars
> >
> > You are currently subscribed to ntfsd as: xxxxx@live.com
> > To unsubscribe send a blank email to leave-328210-
> xxxxx@lists.osr.com
> >
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
> To unsubscribe send a blank email to xxxxx@lists.osr.com
I have been told by someone who knows that when the IRP_MJ_CREATE is send to
the FSD and has the execute bit set it is for execution. It may be that
some program could try and open a file with that bit set, but if they do and
you treat it as an execute it should not hurt anything. If you don’t see
the same file’s notification in your Ps*** callback, you don’t need to care.
This was oriented to the virus detection world so you need to understand
that limitation to my post.
wrote in message news:xxxxx@ntfsd…
>> When I said Pre-Create, I meant “Pre-Create” callback (the one that is
>> the result of ZwCreateFile/ >NtCreateFile) and not Pre callback for
>> acquire-for-section-synchronization.
>
> Well, from the very beginning this thread was speaking about section
> synchronization callback, so that if you were speaking about IRP_MJ_CREATE
> your posts are a bit off-topic…
>
>> However, since you can’t possibly do anything from that notification
>> routine AND if you want to get away >from HOOKING, a way out could be
>> doing stuff in Pre-callback for IRP_MJ_CREATE.
>
> There is no guarantee that a user who opens an executable file for
> whatever access is about to launch a process, so that any conclusions are
> still premature at this stage. In order to be sure you have to wait at
> least until the caller wants to create an image section with PAGE_EXECUTE
> protection. Otherwise, you can easily make a fool out of yourself…
>
>
> Anton Bassov
>
Thank you~
So in the load image notification routine:
ImageCreateMon(IN PUNICODE_STRING FullImageName,
IN HANDLE ProcessId,
IN PIMAGE_INFO ImageInfo)
The process(ProcessId) is calling the image file(FullImageName).
Is that correct? If yes, the process(maybe an exe file) is calling the image file(maybe a dll file). How can I get the full file
path of the process?
Thank you~
cxun
From: “Ayush Gupta”
Sent: Thursday, June 26, 2008 1:25 PM
To: “Windows File Systems Devs Interest List”
Subject: RE: RE:[ntfsd] How can I know who is calling the DLL files?
> You can track the process name from the same image notification routine.
> The first notification in context of a particular process is that for the image which is used to launch it.
>
> Regards,
> Ayush Gupta
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-328225-
>> xxxxx@lists.osr.com] On Behalf Of cxun
>> Sent: Thursday, June 26, 2008 10:31 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re: RE:[ntfsd] How can I know who is calling the DLL files?
>>
>> Thank you all very much.
>>
>> I tried it in PsSetLoadImageNotifyRoutine. Now I can easily get the
>> Process Id who is calling the requested dll file. But I need to
>> get the file path matching the process Id. I’ve looked for the
>> functions in ifs but failed. Do you know how to achieve this?
>>
>> Thank you all~
>>
>> cxun
>>
>> --------------------------------------------------
>> From:
>> Sent: Thursday, June 26, 2008 11:08 AM
>> To: “Windows File Systems Devs Interest List”
>> Subject: RE:[ntfsd] How can I know who is calling the DLL files?
>>
>> >
>> >> And I thought the BEST place to get the requestor’s PID was PRE-
>> CREATE callback…
>> >
>> > Well, I used to think this way as well - after all, this is the very
>> first ithing that gets into one’s head.
>> >
>> > However, after a bit of experimentation you may discover that. in
>> actuality, things are not necessarily that simple, because the
>> > callback does not seem to get always invoked in context of the thread
>> that calls ZwCreateSection() as one would normally expect to
>> > happen. After all, if things were so straightforward the OP would not
>> ask his question, in the firt place…
>> >
>> >
>> >> Also, if the sole aim is to know the PID of the process that is
>> mapping the DLL, you can
>> >> register a load image notification routine using
>> PsSetLoadImageNotifyRoutine.
>> >
>> >
>> > However, at this point you cannot already do anything - this is
>> nothing more than notification.
>> >
>> > In other words, pre-create section callback allows you to block
>> section creation but does not allow you to discover requestor’s
>> > PID, while notification callback informs you about PID but does not
>> allow to block creation (on pre-Vista OSes, of course).
>> > However, controlling process creation normally requires both
>> features…
>> >
>> >
>> >
>> > Anton Bassov
>> >
>> > —
>> > NTFSD is sponsored by OSR
>> >
>> > For our schedule debugging and file system seminars
>> > (including our new fs mini-filter seminar) visit:
>> > http://www.osr.com/seminars
>> >
>> > You are currently subscribed to ntfsd as: xxxxx@live.com
>> > To unsubscribe send a blank email to leave-328210-
>> xxxxx@lists.osr.com
>> >
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Since you have the ProcessId, the name of the executable that started the
process was seen before with the same PID. Looking for process termination
lets you know a PID has ended. This is really simple to design though
getting the code correct and efficient will take time.
“cxun” wrote in message news:xxxxx@ntfsd…
> Thank you~
>
> So in the load image notification routine:
> ImageCreateMon(IN PUNICODE_STRING FullImageName,
> IN HANDLE ProcessId,
> IN PIMAGE_INFO ImageInfo)
> The process(ProcessId) is calling the image file(FullImageName).
> Is that correct? If yes, the process(maybe an exe file) is calling the
> image file(maybe a dll file). How can I get the full file path of the
> process?
>
> Thank you~
>
> cxun
>
> --------------------------------------------------
> From: “Ayush Gupta”
> Sent: Thursday, June 26, 2008 1:25 PM
> To: “Windows File Systems Devs Interest List”
> Subject: RE: RE:[ntfsd] How can I know who is calling the DLL files?
>
>> You can track the process name from the same image notification routine.
>> The first notification in context of a particular process is that for the
>> image which is used to launch it.
>>
>> Regards,
>> Ayush Gupta
>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com [mailto:bounce-328225-
>>> xxxxx@lists.osr.com] On Behalf Of cxun
>>> Sent: Thursday, June 26, 2008 10:31 AM
>>> To: Windows File Systems Devs Interest List
>>> Subject: Re: RE:[ntfsd] How can I know who is calling the DLL files?
>>>
>>> Thank you all very much.
>>>
>>> I tried it in PsSetLoadImageNotifyRoutine. Now I can easily get the
>>> Process Id who is calling the requested dll file. But I need to
>>> get the file path matching the process Id. I’ve looked for the
>>> functions in ifs but failed. Do you know how to achieve this?
>>>
>>> Thank you all~
>>>
>>> cxun
>>>
>>> --------------------------------------------------
>>> From:
>>> Sent: Thursday, June 26, 2008 11:08 AM
>>> To: “Windows File Systems Devs Interest List”
>>> Subject: RE:[ntfsd] How can I know who is calling the DLL files?
>>>
>>> >
>>> >> And I thought the BEST place to get the requestor’s PID was PRE-
>>> CREATE callback…
>>> >
>>> > Well, I used to think this way as well - after all, this is the very
>>> first ithing that gets into one’s head.
>>> >
>>> > However, after a bit of experimentation you may discover that. in
>>> actuality, things are not necessarily that simple, because the
>>> > callback does not seem to get always invoked in context of the thread
>>> that calls ZwCreateSection() as one would normally expect to
>>> > happen. After all, if things were so straightforward the OP would not
>>> ask his question, in the firt place…
>>> >
>>> >
>>> >> Also, if the sole aim is to know the PID of the process that is
>>> mapping the DLL, you can
>>> >> register a load image notification routine using
>>> PsSetLoadImageNotifyRoutine.
>>> >
>>> >
>>> > However, at this point you cannot already do anything - this is
>>> nothing more than notification.
>>> >
>>> > In other words, pre-create section callback allows you to block
>>> section creation but does not allow you to discover requestor’s
>>> > PID, while notification callback informs you about PID but does not
>>> allow to block creation (on pre-Vista OSes, of course).
>>> > However, controlling process creation normally requires both
>>> features…
>>> >
>>> >
>>> >
>>> > Anton Bassov
>>> >
>>> > —
>>> > NTFSD is sponsored by OSR
>>> >
>>> > For our schedule debugging and file system seminars
>>> > (including our new fs mini-filter seminar) visit:
>>> > http://www.osr.com/seminars
>>> >
>>> > You are currently subscribed to ntfsd as: xxxxx@live.com
>>> > To unsubscribe send a blank email to leave-328210-
>>> xxxxx@lists.osr.com
>>> >
>>>
>>> —
>>> NTFSD is sponsored by OSR
>>>
>>> For our schedule debugging and file system seminars
>>> (including our new fs mini-filter seminar) visit:
>>> http://www.osr.com/seminars
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
>> ‘’
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>