Getting process path from PID - NTFSD - OSR Developer Community

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

相关文章推荐

有腹肌的小熊猫 · Best Practices for ...· 2 周前 ·

踏实的洋葱 · Springmvc时间转换+全局异常捕获 ...· 2 周前 ·

爱看球的企鹅 · 我是自由撰稿人，如何参加医保？_ ...· 1 月前 ·

细心的仙人球 · 我的surface pro无法彻底重置删除 ...· 4 月前 ·

小胡子的针织衫 · N1 Openwrt ...· 4 月前 ·

Hello,

I am trying to get the path to the process from its PID in the kernel. I am following the example from OSR:

http://www.osronline.com/article.cfm?article=472

The reason I am doing this in the kernel is because I allow the user to filter on conditions that I compare in the kernel to decide if I should send it to the user mode. For example I would allow the user to specify C:.…\firefox.exe and I would compare this to the path of the PID to decide if I care about these events or not and whether or not to send it to the user mode. I have about 5 other filtering conditions the user can specify and I do all of these in the kernel to decide to send the information to user mode.

The problem I am having is that the returning buffer size of ZwQueryInformationProcess() is 8 which is just the sizeof(UNICODE_STRING) and when I cast this to the UNICODE_STRING structure the Buffer is NULL and the Lengths are 0. Does anyone see something wrong with my function below? Or is there another/better way to get the path to the PID? I guess I could move this to the user mode if it satisfies the other filtering conditions, but what would happen if the PID of firefox.exe doesnt exist anymore or has changed by the time I look up the PID?

Here is my function:
NTSTATUS GetProcessImagePath(HANDLE processId, PEVENT_LIST EventList)
// DbgBreakPoint();

NTSTATUS status = STATUS_SUCCESS;

// Import the ZwQueryInformationProcess() API
static ZW_QUERY_INFORMATION_PROCESS ZwQueryInformationProcess = NULL;
if(ZwQueryInformationProcess == NULL)
UNICODE_STRING functionName;
RtlInitUnicodeString(&functionName, L"ZwQueryInformationProcess");

ZwQueryInformationProcess = (ZW_QUERY_INFORMATION_PROCESS) MmGetSystemRoutineAddress(&functionName);

if(ZwQueryInformationProcess == NULL)
return STATUS_UNSUCCESSFUL;

// Obtain the size of the buffer needed to store the path name
ULONG bufferSize = 0;
status = ZwQueryInformationProcess(NtCurrentProcess(), ProcessImageFileName, NULL, 0, &bufferSize);
if(bufferSize == 0 || status != STATUS_INFO_LENGTH_MISMATCH)
return STATUS_UNSUCCESSFUL;

// A buffer of the size that was just found is now allocated
void* buffer = ExAllocatePoolWithTag(PagedPool, bufferSize, ‘corP’);
if(buffer == NULL)
return STATUS_INSUFFICIENT_RESOURCES;

// Obtain the NT device style path name
// NOTE: THIS IS NOT RETURNING A STRING. ITS RETURNING NULL PATH WITH THE BUFFER SIZE OF 8 WHICH IS SIZEOF(UNICODE_STRING)
status = ZwQueryInformationProcess(NtCurrentProcess(), ProcessImageFileName, buffer, bufferSize, &bufferSize);
if(!NT_SUCCESS(status))
goto freeBuffer;

// Cast the returned buffer to a UNICODE_STRING
// NOTE: path.Buffer is NULL and the Length is 0
PUNICODE_STRING path = (PUNICODE_STRING)buffer;

freeBuffer:
ExFreePool(buffer);

return status;

In which context are you trying to query the process path? And is this
problem limited to particular a OS?

wrote news:xxxxx@ntfsd…
> Hello,
>
> I am trying to get the path to the process from its PID in the kernel. I
> am following the example from OSR:
>
> http://www.osronline.com/article.cfm?article=472
>
> The reason I am doing this in the kernel is because I allow the user to
> filter on conditions that I compare in the kernel to decide if I should
> send it to the user mode. For example I would allow the user to specify
> C:.…\firefox.exe and I would compare this to the path of the PID to
> decide if I care about these events or not and whether or not to send it
> to the user mode. I have about 5 other filtering conditions the user can
> specify and I do all of these in the kernel to decide to send the
> information to user mode.
>
> The problem I am having is that the returning buffer size of
> ZwQueryInformationProcess() is 8 which is just the sizeof(UNICODE_STRING)
> and when I cast this to the UNICODE_STRING structure the Buffer is NULL
> and the Lengths are 0. Does anyone see something wrong with my function
> below? Or is there another/better way to get the path to the PID? I guess
> I could move this to the user mode if it satisfies the other filtering
> conditions, but what would happen if the PID of firefox.exe doesnt exist
> anymore or has changed by the time I look up the PID?
>
> Here is my function:
> NTSTATUS GetProcessImagePath(HANDLE processId, PEVENT_LIST EventList)
> {
> // DbgBreakPoint();
>
> NTSTATUS status = STATUS_SUCCESS;
>
> // Import the ZwQueryInformationProcess() API
> static ZW_QUERY_INFORMATION_PROCESS ZwQueryInformationProcess = NULL;
> if(ZwQueryInformationProcess == NULL)
> {
> UNICODE_STRING functionName;
> RtlInitUnicodeString(&functionName, L"ZwQueryInformationProcess");
>
> ZwQueryInformationProcess = (ZW_QUERY_INFORMATION_PROCESS)
> MmGetSystemRoutineAddress(&functionName);
>
> if(ZwQueryInformationProcess == NULL)
> return STATUS_UNSUCCESSFUL;
> }
>
> // Obtain the size of the buffer needed to store the path name
> ULONG bufferSize = 0;
> status = ZwQueryInformationProcess(NtCurrentProcess(),
> ProcessImageFileName, NULL, 0, &bufferSize);
> if(bufferSize == 0 || status != STATUS_INFO_LENGTH_MISMATCH)
> return STATUS_UNSUCCESSFUL;
>
> // A buffer of the size that was just found is now allocated
> void* buffer = ExAllocatePoolWithTag(PagedPool, bufferSize, ‘corP’);
> if(buffer == NULL)
> return STATUS_INSUFFICIENT_RESOURCES;
>
> // Obtain the NT device style path name
> // NOTE: THIS IS NOT RETURNING A STRING. ITS RETURNING NULL PATH WITH THE
> BUFFER SIZE OF 8 WHICH IS SIZEOF(UNICODE_STRING)
> status = ZwQueryInformationProcess(NtCurrentProcess(),
> ProcessImageFileName, buffer, bufferSize, &bufferSize);
> if(!NT_SUCCESS(status))
> goto freeBuffer;
>
> // Cast the returned buffer to a UNICODE_STRING
> // NOTE: path.Buffer is NULL and the Length is 0
> PUNICODE_STRING path = (PUNICODE_STRING)buffer;
>
> freeBuffer:
> ExFreePool(buffer);
>
> return status;
> }
>

What is the bufferSize you get from the original ZwQueryInformationProcess
call ? the one where you pass in a NULL buffer with a 0 size to get the
needed size… Is that also 8 ?

Thanks,
Alex.

“In which context are you trying to query the process path? And is this problem limited to particular a OS?”

I was using Windows 7 32 bit and I havent tested this on anything else so I dont know if this is an OS problem. And I was using this function in the Pre Operation callback for all operations that the minispy sample has registered as callbacks.

“What is the bufferSize you get from the original ZwQueryInformationProcess call ? the one where you pass in a NULL buffer with a 0 size to get the needed size… Is that also 8 ?”

Yes that is returning 8 as well.

See points below.
Obtain EPROCESS pointer
For NT 4.0 and 5.0 take section handle from EPROCESS->SectionHandle
and using ObReferenceObjectByHandle() we obtain PSECTION_OBJECT
SectionObject; for NT 5.1(XP) we can take PSECTION_OBJECT
SectionObject from EPROCESS directly.
From PSECTION_OBJECT SectionObject we obtain PSEGMENT_OBJECT SegmentObject.
From PSEGMENT_OBJECT SegmentObject we obtain PCONTROL_AREA ControlArea.
From PCONTROL_AREA ControlArea we obtain FilePointer (this is
FileObject pointer).
Using ObQueryNameString() on the FilePointer we obtain full process path.

i use this method and it work better than ZwQueryInformationProcess

On 8/25/11, [email protected] wrote:
> “In which context are you trying to query the process path? And is this
> problem limited to particular a OS?”
>
> I was using Windows 7 32 bit and I havent tested this on anything else so I
> dont know if this is an OS problem. And I was using this function in the Pre
> Operation callback for all operations that the minispy sample has registered
> as callbacks.
>
> “What is the bufferSize you get from the original ZwQueryInformationProcess
> call ? the one where you pass in a NULL buffer with a 0 size to get the
> needed size… Is that also 8 ?”
>
> Yes that is returning 8 as well.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system 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
>

Hey maysam firozi,

could you please explain these steps some more:

From PSECTION_OBJECT SectionObject we obtain PSEGMENT_OBJECT SegmentObject.
From PSEGMENT_OBJECT SegmentObject we obtain PCONTROL_AREA ControlArea.
From PCONTROL_AREA ControlArea we obtain FilePointer (this is FileObject pointer).

How do I obtain these from each other?

Thank you

you can add correct offset to EProcess and get next Struct until find
PFILE_OBJECT

//Windows XP Struct offset
PEPROCESS_TO_PSECTION_OBJECT = 0x138;
PSECTION_OBJECT_TO_PSEGMENT = 20;
PSEGMENT_TO_PCONTROL_AREA = 0;
PCONTROL_AREA_TO_PFILE_OBJECT = 36;

for example to get PSECTION_OBJECT

// process is PEPROCESS
PVOID temp = process;
__asm //PEPROCESS to PSECTION_OBJECT
mov EAX, temp
add EAX, PEPROCESS_TO_PSECTION_OBJECT
mov temp, EAX

and continue to get PFILE_OBJECT

so use ObQueryNameString and get path

use winDBG to parse EPROCESS

my code is property so i cant share it sorry

On 8/26/11, [email protected] wrote:
> Hey maysam firozi,
>
> could you please explain these steps some more:
>
> From PSECTION_OBJECT SectionObject we obtain PSEGMENT_OBJECT SegmentObject.
> From PSEGMENT_OBJECT SegmentObject we obtain PCONTROL_AREA ControlArea.
> From PCONTROL_AREA ControlArea we obtain FilePointer (this is FileObject
> pointer).
>
> How do I obtain these from each other?
>
> Thank you
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system 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
>

not my area but since i saw use windbg to parse i tried to parse

it seems the meysam is missing a SubSection

lkd> .foreach /pS 7 /ps 11 (place {!process 0 0 }) {dt nt!_EPROCESS
ImageFilename place;.foreach /pS 3 /ps 1 ( vlace { dt nt!_EPROCESS
SectionObject place}) { dt nt!_SECTION_OBJECT
Segment->SubSection->ControlArea->FilePointer->Filename vlace}}
+0x174 ImageFileName : [16] “System”
+0x014 Segment :
Cannot find specified field members.
+0x174 ImageFileName : [16] “smss.exe”
+0x014 Segment :
+0x01c Subsection :
+0x000 ControlArea :
+0x024 FilePointer :
+0x030 FileName
: _UNICODE_STRING “\WINDOWS\system32\smss.exe”
+0x174 ImageFileName : [16] “csrss.exe”
+0x014 Segment :
+0x01c Subsection :
+0x000 ControlArea :
+0x024 FilePointer :
+0x030 FileName
: _UNICODE_STRING “\WINDOWS\system32\csrss.exe”
+0x174 ImageFileName : [16] “winlogon.exe”
+0x014 Segment :
+0x01c Subsection :
+0x000 ControlArea :
+0x024 FilePointer :
+0x030 FileName
: _UNICODE_STRING “\WINDOWS\system32\winlogon.exe”
+0x174 ImageFileName : [16] “services.exe”
+0x014 Segment :
+0x01c Subsection :
+0x000 ControlArea :
+0x024 FilePointer :
+0x030 FileName
: _UNICODE_STRING “\WINDOWS\system32\services.exe”
+0x174 ImageFileName : [16] “lsass.exe”
+0x014 Segment :
+0x01c Subsection :
+0x000 ControlArea :
+0x024 FilePointer :
+0x030 FileName
: _UNICODE_STRING “\WINDOWS\system32\lsass.exe”

On 8/27/11, meysam firozi wrote:
> hi
> you can add correct offset to EProcess and get next Struct until find
> PFILE_OBJECT
>
> //Windows XP Struct offset
> PEPROCESS_TO_PSECTION_OBJECT = 0x138;
> PSECTION_OBJECT_TO_PSEGMENT = 20;
> PSEGMENT_TO_PCONTROL_AREA = 0;
> PCONTROL_AREA_TO_PFILE_OBJECT = 36;
>
>
> for example to get PSECTION_OBJECT
>
> // process is PEPROCESS
> PVOID temp = process;
> __asm //PEPROCESS to PSECTION_OBJECT
> {
> mov EAX, temp
> add EAX, PEPROCESS_TO_PSECTION_OBJECT
> mov temp, EAX
> }
>
>
> and continue to get PFILE_OBJECT
>
> so use ObQueryNameString and get path
>
> use winDBG to parse EPROCESS
>
> my code is property so i cant share it sorry
>
>
> On 8/26/11, [email protected] wrote:
>> Hey maysam firozi,
>>
>> could you please explain these steps some more:
>>
>> From PSECTION_OBJECT SectionObject we obtain PSEGMENT_OBJECT
>> SegmentObject.
>> From PSEGMENT_OBJECT SegmentObject we obtain PCONTROL_AREA ControlArea.
>> From PCONTROL_AREA ControlArea we obtain FilePointer (this is FileObject
>> pointer).
>>
>> How do I obtain these from each other?
>>
>> Thank you
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system 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
>>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system 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 and regards

raj_r

This is a REALLY bad idea. These structure offsets can and do change and
you’re not properly serializing yourself here with the components in the O/S
that maintain these fields.

So, please don’t do this. It’s a terrible hack and not suitable for
production use.

-scott

Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“meysam firozi” wrote in message news:xxxxx@ntfsd…

you can add correct offset to EProcess and get next Struct until find
PFILE_OBJECT

//Windows XP Struct offset
PEPROCESS_TO_PSECTION_OBJECT = 0x138;
PSECTION_OBJECT_TO_PSEGMENT = 20;
PSEGMENT_TO_PCONTROL_AREA = 0;
PCONTROL_AREA_TO_PFILE_OBJECT = 36;

for example to get PSECTION_OBJECT

// process is PEPROCESS
PVOID temp = process;
__asm //PEPROCESS to PSECTION_OBJECT
mov EAX, temp
add EAX, PEPROCESS_TO_PSECTION_OBJECT
mov temp, EAX

and continue to get PFILE_OBJECT

so use ObQueryNameString and get path

use winDBG to parse EPROCESS

my code is property so i cant share it sorry

On 8/26/11, [email protected] wrote:
> Hey maysam firozi,
>
> could you please explain these steps some more:
>
> From PSECTION_OBJECT SectionObject we obtain PSEGMENT_OBJECT
> SegmentObject.
> From PSEGMENT_OBJECT SegmentObject we obtain PCONTROL_AREA ControlArea.
> From PCONTROL_AREA ControlArea we obtain FilePointer (this is FileObject
> pointer).
>
> How do I obtain these from each other?
>
> Thank you
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system 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
>

> I am trying to get the path to the process from its PID in the kernel. I am following the example from OSR:

For Vista+, there is a PsXxx call which does this.

For pre-Vista, you can get the PEB (user-mode) address by ZwQueryInformationProcess, then read the PEB and its child RTL_USER_PROCESS_PARAMETERS in user memory of the process, the full pathname is there.

This is what psapi!GetModuleFileNameEx does. BTW - this is the recommended function to solve the same task in user mode, things like ipnatsvc (Windows Firewall) use it to implement the pathname-based rules.

Maxim S. Shatskih

Windows DDK MVP

[email protected]

http://www.storagecraft.com

What is the PsXxx call? I don’t see it in the documentation.

Bill Wandel

-----Original Message-----
From: [email protected]
[ mailto:[email protected] ] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, August 30, 2011 3:36 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Getting process path from PID

I am trying to get the path to the process from its PID in the kernel. I
am following the example from OSR:

For Vista+, there is a PsXxx call which does this.

For pre-Vista, you can get the PEB (user-mode) address by
ZwQueryInformationProcess, then read the PEB and its child
RTL_USER_PROCESS_PARAMETERS in user memory of the process, the full pathname
is there.

This is what psapi!GetModuleFileNameEx does. BTW - this is the recommended
function to solve the same task in user mode, things like ipnatsvc (Windows
Firewall) use it to implement the pathname-based rules.

Maxim S. Shatskih

Windows DDK MVP

[email protected]

http://www.storagecraft.com

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

Of course an app can rewrite the contents of that structure at will as it resides within the user mode address space.

-----Original Message-----
From: Maxim S. Shatskih
Sent: Tuesday, August 30, 2011 0:36
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Getting process path from PID

I am trying to get the path to the process from its PID in the kernel. I am following the example from OSR:

For Vista+, there is a PsXxx call which does this.

Maxim S. Shatskih

Windows DDK MVP

[email protected]

http://www.storagecraft.com

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

PsGetProcessImageFileName

Undocumented

You can also look at disassembly of user-mode GetProcessImageFileName, probably it is a single ZwQueryInformationProcess call, and you can do the same call.

Also, you can use Ps notify callbacks.

Maxim S. Shatskih
Windows DDK MVP
[email protected]
http://www.storagecraft.com

“Bill Wandel” wrote in message news:xxxxx@ntfsd…
> What is the PsXxx call? I don’t see it in the documentation.
>
> Bill Wandel
>
> -----Original Message-----
> From: [email protected]
> [ mailto:[email protected] ] On Behalf Of Maxim S. Shatskih
> Sent: Tuesday, August 30, 2011 3:36 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Getting process path from PID
>
>> I am trying to get the path to the process from its PID in the kernel. I
> am following the example from OSR:
>
> For Vista+, there is a PsXxx call which does this.
>
> For pre-Vista, you can get the PEB (user-mode) address by
> ZwQueryInformationProcess, then read the PEB and its child
> RTL_USER_PROCESS_PARAMETERS in user memory of the process, the full pathname
> is there.
>
> This is what psapi!GetModuleFileNameEx does. BTW - this is the recommended
> function to solve the same task in user mode, things like ipnatsvc (Windows
> Firewall) use it to implement the pathname-based rules.
>
> –
> Maxim S. Shatskih
>
> Windows DDK MVP
>
> [email protected]
>
> http://www.storagecraft.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system 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
>
>

Please do not use PsGetProcessImageFileName for anything other than a debugging aid, as the name yields *nothing* in terms of information about what you are running.

For example, I have seen (production) code where a driver checked to make sure it was SVCHOST.EXE calling. The problem with this is that just because “C:\malware\svchost.exe” has called your driver, it doesn’t mean that it’s trustworthy (and in that particular case the driver had serious bugs within it that could have been trivially exploited to crash the system.)

I wrote an article about this several years back:

http://www.osronline.com/article.cfm?article=472

The technique here will yield a valid path to the binary (when it was opened, so it ignores renames) and works for Windows XP and more recent.

Hope to see everyone September 19 for the next Developing File Systems for Windows seminar ( http://www.osr.com/fsd.html )

-----Original Message-----
From: [email protected]
[ mailto:[email protected] ] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, August 30, 2011 11:07 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Getting process path from PID

PsGetProcessImageFileName

Undocumented

You can also look at disassembly of user-mode GetProcessImageFileName,
probably it is a single ZwQueryInformationProcess call, and you can do the
same call.

Also, you can use Ps notify callbacks.

Maxim S. Shatskih
Windows DDK MVP
[email protected]
http://www.storagecraft.com

“Bill Wandel” wrote in message news:xxxxx@ntfsd…
> What is the PsXxx call? I don’t see it in the documentation.
>
> Bill Wandel
>
> -----Original Message-----
> From: [email protected]
> [ mailto:[email protected] ] On Behalf Of Maxim S.
> Shatskih
> Sent: Tuesday, August 30, 2011 3:36 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Getting process path from PID
>
>> I am trying to get the path to the process from its PID in the
>> kernel. I
> am following the example from OSR:
>
> For Vista+, there is a PsXxx call which does this.
>
> For pre-Vista, you can get the PEB (user-mode) address by
> ZwQueryInformationProcess, then read the PEB and its child
> RTL_USER_PROCESS_PARAMETERS in user memory of the process, the full
> pathname is there.
>
> This is what psapi!GetModuleFileNameEx does. BTW - this is the
> recommended function to solve the same task in user mode, things like
> ipnatsvc (Windows
> Firewall) use it to implement the pathname-based rules.
>
> –
> Maxim S. Shatskih
>
> Windows DDK MVP
>
> [email protected]
>
> http://www.storagecraft.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system 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
>
>

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

-----Original Message-----
From: [email protected]
[ mailto:[email protected] ] On Behalf Of Skywing
Sent: Tuesday, August 30, 2011 11:04 AM
To: Windows File Systems Devs Interest List
Subject: RE: Re:[ntfsd] Getting process path from PID

Of course an app can rewrite the contents of that structure at will as it
resides within the user mode address space.

-----Original Message-----
From: Maxim S. Shatskih
Sent: Tuesday, August 30, 2011 0:36
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Getting process path from PID

I am trying to get the path to the process from its PID in the kernel. I
am following the example from OSR:

For Vista+, there is a PsXxx call which does this.

For pre-Vista, you can get the PEB (user-mode) address by
ZwQueryInformationProcess, then read the PEB and its child
RTL_USER_PROCESS_PARAMETERS in user memory of the process, the full pathname
is there.

This is what psapi!GetModuleFileNameEx does. BTW - this is the recommended
function to solve the same task in user mode, things like ipnatsvc (Windows
Firewall) use it to implement the pathname-based rules.

Maxim S. Shatskih

Windows DDK MVP

[email protected]

http://www.storagecraft.com

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

One thing to mention is that ZwQueryInformationProcess gets the physical
path (\device\x) not the WIN32 path.

Bill Wandel

-----Original Message-----
From: [email protected]
[ mailto:[email protected] ] On Behalf Of Tony Mason
Sent: Tuesday, August 30, 2011 11:20 AM
To: Windows File Systems Devs Interest List
Subject: RE: Re:[ntfsd] Getting process path from PID

Please do not use PsGetProcessImageFileName for anything other than a
debugging aid, as the name yields *nothing* in terms of information about
what you are running.

For example, I have seen (production) code where a driver checked to make
sure it was SVCHOST.EXE calling. The problem with this is that just because
“C:\malware\svchost.exe” has called your driver, it doesn’t mean that it’s
trustworthy (and in that particular case the driver had serious bugs within
it that could have been trivially exploited to crash the system.)

I wrote an article about this several years back:

http://www.osronline.com/article.cfm?article=472

The technique here will yield a valid path to the binary (when it was
opened, so it ignores renames) and works for Windows XP and more recent.

Hope to see everyone September 19 for the next Developing File Systems for
Windows seminar ( http://www.osr.com/fsd.html )

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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