Process name (again...)

NTFSD
1

Hi guys,

I would like to fire up the discussion again about the process name
(there was a thread on this back in May I believe). One method of
getting the process name is the FileMon method (get the offset by
looking at the EPROCESS structure during driver initialization for
“SYSTEM”. Then use this offset to get the base name of the executable
which you can match to the full pathname you saved during the
IRP_MJ_CREATE that opened the executable.)

I have looked at this FileMon method, but it seems that this method does
not retrieve the name of the *original* process. If I’m opening a
document in Word, the process that I detect in my file filter driver is
my virus scanner rather than winword.exe…

Is there any way to solve this. Do other implementations exist that
behave correctly ?

–
Bartjan.

2

How do you get the PID or the KPROCESS pointer in your filter driver ?
IoGetRequestorProcess() or you
blinly check the current process ?

----- Original Message -----
From: “Bartjan Wattel”
To: “File Systems Developers”
Sent: Tuesday, July 02, 2002 5:29 PM
Subject: [ntfsd] Process name (again…)

> Hi guys,
>
> I would like to fire up the discussion again about the process name
> (there was a thread on this back in May I believe). One method of
> getting the process name is the FileMon method (get the offset by
> looking at the EPROCESS structure during driver initialization for
> “SYSTEM”. Then use this offset to get the base name of the executable
> which you can match to the full pathname you saved during the
> IRP_MJ_CREATE that opened the executable.)
>
> I have looked at this FileMon method, but it seems that this method does
> not retrieve the name of the original process. If I’m opening a
> document in Word, the process that I detect in my file filter driver is
> my virus scanner rather than winword.exe…
>
> Is there any way to solve this. Do other implementations exist that
> behave correctly ?
>
> –
> Bartjan.
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

3

As Dan suggested, use IoGetRequestorProcess instead of
PsGetCurrentProcess.

Bartjan Wattel wrote:

Hi guys,

I would like to fire up the discussion again about the process name
(there was a thread on this back in May I believe). One method of
getting the process name is the FileMon method (get the offset by
looking at the EPROCESS structure during driver initialization for
“SYSTEM”. Then use this offset to get the base name of the executable
which you can match to the full pathname you saved during the
IRP_MJ_CREATE that opened the executable.)

I have looked at this FileMon method, but it seems that this method does
not retrieve the name of the *original* process. If I’m opening a
document in Word, the process that I detect in my file filter driver is
my virus scanner rather than winword.exe…

Is there any way to solve this. Do other implementations exist that
behave correctly ?

–
Bartjan.

You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to %%email.unsub%%

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com ICQ#: 56570367
Alfa File Monitor - File monitoring library for Win32 developers.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa Registry Monitor - Registry monitoring library for Win32 developers.
Alfa Registry Protector - Registry protection library for Win32 developers.

4

Really, the correct way to solve this is to NOT use the process name for
identifying your application.
Neither is the process name in the EPROCESS structure correct, nor
complete,
and even if it is, it can be easily spoofed.
Register your scanner with your filter using secure IOCTLs.
Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Bartjan Wattel [mailto:xxxxx@zeelandnet.nl]
Sent: Tuesday, July 02, 2002 7:29 AM
To: File Systems Developers
Subject: [ntfsd] Process name (again…)

Hi guys,

I would like to fire up the discussion again about the process name
(there was a thread on this back in May I believe). One method of
getting the process name is the FileMon method (get the offset by
looking at the EPROCESS structure during driver initialization for
“SYSTEM”. Then use this offset to get the base name of the executable
which you can match to the full pathname you saved during the
IRP_MJ_CREATE that opened the executable.)

I have looked at this FileMon method, but it seems that this method does
not retrieve the name of the *original* process. If I’m opening a
document in Word, the process that I detect in my file filter driver is
my virus scanner rather than winword.exe…

Is there any way to solve this. Do other implementations exist that
behave correctly ?

–
Bartjan.

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

5

If I may speculate wildly here, what may be going on
is that the anti-virus filter is posting the create
requests for these files to a thread in the context of
its own service. Which EPROCESS are you checking? You
should be using the result of
IoGetRequestorProcess(pIrp), not
PsGetCurrentProcess().

— Bartjan Wattel wrote:
> Hi guys,
>
> I would like to fire up the discussion again about
> the process name
> (there was a thread on this back in May I believe).
> One method of
> getting the process name is the FileMon method (get
> the offset by
> looking at the EPROCESS structure during driver
> initialization for
> “SYSTEM”. Then use this offset to get the base name
> of the executable
> which you can match to the full pathname you saved
> during the
> IRP_MJ_CREATE that opened the executable.)
>
> I have looked at this FileMon method, but it seems
> that this method does
> not retrieve the name of the original process. If
> I’m opening a
> document in Word, the process that I detect in my
> file filter driver is
> my virus scanner rather than winword.exe…
>
> Is there any way to solve this. Do other
> implementations exist that
> behave correctly ?
>
> –
> Bartjan.
>
>
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@nryan.com
> To unsubscribe send a blank email to
%%email.unsub%%

=====
- Nicholas Ryan

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

6

I have used both IoGetRequestorProcess and PsGetCurrentProcess (in a
pre-create context), but there is no difference in the values that are
returned…

Any more clues ?

Subject: Re: Process name (again…)
From: Nicholas Ryan
> Date: Tue, 2 Jul 2002 17:21:30 -0700 (PDT)
> X-Message-Number: 19
>
> If I may speculate wildly here, what may be going on
> is that the anti-virus filter is posting the create
> requests for these files to a thread in the context of
> its own service. Which EPROCESS are you checking? You
> should be using the result of
> IoGetRequestorProcess(pIrp), not
> PsGetCurrentProcess().
>
> — Bartjan Wattel wrote:
> > Hi guys,
> >
> > I would like to fire up the discussion again about
> > the process name
> > (there was a thread on this back in May I believe).
> > One method of
> > getting the process name is the FileMon method (get
> > the offset by
> > looking at the EPROCESS structure during driver initialization for
> > “SYSTEM”. Then use this offset to get the base name
> > of the executable
> > which you can match to the full pathname you saved
> > during the
> > IRP_MJ_CREATE that opened the executable.)
> >
> > I have looked at this FileMon method, but it seems
> > that this method does
> > not retrieve the name of the original process. If
> > I’m opening a
> > document in Word, the process that I detect in my
> > file filter driver is
> > my virus scanner rather than winword.exe…
> >
> > Is there any way to solve this. Do other
> > implementations exist that
> > behave correctly ?
> >
> > –
> > Bartjan.
> >

7

Is your filter creating a new IRP?

Bartjan Wattel wrote:

I have used both IoGetRequestorProcess and PsGetCurrentProcess (in a
pre-create context), but there is no difference in the values that are
returned…

Any more clues ?

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com ICQ#: 56570367
Alfa File Monitor - File monitoring library for Win32 developers.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa Registry Monitor - Registry monitoring library for Win32 developers.
Alfa Registry Protector - Registry protection library for Win32
developers.

8

Create requests are always synchronous (tough you can post it , or return
STATUS_PENDING, but the IoManager will always block waiting for the request
to be completed). Also, normally , a create operation is processed into the
context of the requestor. Thus, it is very probale that both
PsGetCurrentProcess() and
IoGetRequestorProcess will return the same value. However those routines are
very different. One simply lookups the current process pointer, while the
other one get’s the thread pointer stored in IRP , and based on this will
return the requestor process.

In the event a create operation is posted to thread, those two functions
will give different processes most likely.
It is because the IRP will still have recorded the IO request originator
thread, but current processing context can be different, usually System
process, if its posted to a worker thread.

The original requestor process can be lost for ever in some cases. Imagine
the folowing scenarion. A filter above you into the device stack chooses to
complete an IO operation by rolling it’s own IRP down, and complete the
original IRP at it’s will. When it builds the IRP, it stores the current
thread pointer, and sends down the IRP. Your filter driver will receive this
IRP, but even IoGetRequestorProcess() can give you back an arbitray process
and not the origianl one, since the filter driver above you could decide to
process the request in a worker thread ,and in this case the requestor
process will be the System process. I think you got the ideea.

Anyway, at what exactly fo you want to use this ?