Re[2]: Get process full path from PEPROCESS structure

Hello Mark,

Tuesday, May 24, 2005, 12:37:55 PM, you wrote:
CM> As I recall, the last time this was discussed, the general consensus was
CM> that it would be better to allow your user mode component to resolve the
CM> pathname.
and I must again react, that this way is totally unsecure. Even
undocumented gathering of full path name (using section object) is far
much better than this documented method. Please read the following
text done by my friend. The problem is already fixed in new versions
of Kerio Personal Firewall - the vendor was contacted some months ago.

www.wasteland.cz/!/bypassing.zip - mainly concentrate on violation of
point two.


Best regards,
Ivona Prenosilova

Unfortunately, usermode is not an option.
It seems that ProcessImageFileName is like you said, only supported
on winxp. I checked Windows 2000 native api reference and didn’t find
it there.

From several discussions here, i know that there are filed / fields in
PEPROCESS structure that containe the full path - am i right ?
I did dig in the archive and tried to use the code samples i found but
it just didn’t work or BSOD my system… maybe it’s because PEPROCESS
structure changes from windows version to another and i got the wrong
structure definition?
Do you know such a code sample that actually works ?

Thanks!

On 5/24/05, Cook, Mark <mark.cook> wrote:
>
> Hi Omer
> The methods for doing this have been debated many times in the past so
> it might be worth a trawl through the archives. This is a surprisingly
> difficult thing to do and the only clean method for accomplishing this
> in Kernel Mode appears to be a call to ZwQueryInformationProcess with
> the class set to ProcessImageFileName. However, there is an important
> caveat to this because I believe ProcessImageFileName is only supported
> on XP or later.
>
> As I recall, the last time this was discussed, the general consensus was
> that it would be better to allow your user mode component to resolve the
> pathname.
>
> Regards
>
> Mark
>
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Omer B
> Sent: 24 May 2005 08:57
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Get process full path from PEPROCESS structure
>
> Hi
>
>
> Any way to get the FULL path of a process from a given PEPROCESS
> structure ?
>
> I saw one code sample in this forum but it didn’t work …
>
> Target systems: win2k, winxp and windows 2003
>
>
> Thanks!
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></mark.cook>

Hi ivona

Hello ivona

Do you mean using the section object from the PERPROCESS structure
(can you please remind me of the details of that method again?) ?
Isn’t that method only supported under windows xp systems?
What can i do for windows 2000 systems ?

Thanks

On 5/24/05, ivona prenosilova wrote:
> Hello Mark,
>
> Tuesday, May 24, 2005, 12:37:55 PM, you wrote:
> CM> As I recall, the last time this was discussed, the general consensus was
> CM> that it would be better to allow your user mode component to resolve the
> CM> pathname.
> and I must again react, that this way is totally unsecure. Even
> undocumented gathering of full path name (using section object) is far
> much better than this documented method. Please read the following
> text done by my friend. The problem is already fixed in new versions
> of Kerio Personal Firewall - the vendor was contacted some months ago.
>
> www.wasteland.cz/!/bypassing.zip - mainly concentrate on violation of
> point two.
>
> –
> Best regards,
> Ivona Prenosilova
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

If you are in the current process context, you can use
NtCurrentProcess() to get the process handle (“-1”) and then call
NtQueryInformationProcess, asking for ProcesImageInformation. That will
give you the path that was used when the process was executed.

While not formally documented, this technique relies upon information
that is actually maintained for auditing (process creation/termination)
so the name should be present throughout the lifetime of the process
itself.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Omer B
Sent: Tuesday, May 24, 2005 7:27 AM
To: ntdev redirect
Subject: Re: Re[2]: [ntdev] Get process full path from PEPROCESS
structure

Hi ivona

Hello ivona

Do you mean using the section object from the PERPROCESS structure
(can you please remind me of the details of that method again?) ?
Isn’t that method only supported under windows xp systems?
What can i do for windows 2000 systems ?

Thanks

On 5/24/05, ivona prenosilova wrote:
> Hello Mark,
>
> Tuesday, May 24, 2005, 12:37:55 PM, you wrote:
> CM> As I recall, the last time this was discussed, the general
consensus was
> CM> that it would be better to allow your user mode component to
resolve the
> CM> pathname.
> and I must again react, that this way is totally unsecure. Even
> undocumented gathering of full path name (using section object) is far
> much better than this documented method. Please read the following
> text done by my friend. The problem is already fixed in new versions
> of Kerio Personal Firewall - the vendor was contacted some months ago.
>
> www.wasteland.cz/!/bypassing.zip - mainly concentrate on violation of
> point two.
>
> –
> Best regards,
> Ivona Prenosilova
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

“Undocumented” is too strong a word. It’s all “documented” if
you use Windbg’s “dt” command on the data structures you need.
Russinovitch and Solomon have enough information on the
interconnections between those object structures, and you can
always resort to Gary Nebbett in case of doubt. Sure, it’s a bit
of a pain because you have to watch out for OS builds and such,
but that’s the price of advanced functionality.

Alberto.

----- Original Message -----
From: “ivona prenosilova”
To: “Windows System Software Devs Interest List”

Sent: Tuesday, May 24, 2005 7:09 AM
Subject: Re[2]: [ntdev] Get process full path from PEPROCESS
structure

> Hello Mark,
>
> Tuesday, May 24, 2005, 12:37:55 PM, you wrote:
> CM> As I recall, the last time this was discussed, the general
> consensus was
> CM> that it would be better to allow your user mode component
> to resolve the
> CM> pathname.
> and I must again react, that this way is totally unsecure.
> Even
> undocumented gathering of full path name (using section
> object) is far
> much better than this documented method. Please read the
> following
> text done by my friend. The problem is already fixed in new
> versions
> of Kerio Personal Firewall - the vendor was contacted some
> months ago.
>
> www.wasteland.cz/!/bypassing.zip - mainly concentrate on
> violation of
> point two.
>
> –
> Best regards,
> Ivona Prenosilova
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

The way I look at it is that " (Almost ) Anything outside the ddk documents
and ms docs should be considered as undocumented". MS dont have a
responsibility to have a backward compatibilities for all those described in
Nebbett or in Russinovitch … Only thing published in ddk is documented,
finding anything from several headers might not qualify being documented.
When a ddk api is depricated, it states so in the ddk document. But who is
going to be responsible for all the Nebbett stuff.

Based on the new architecture on the filtmanger and wdf, it is somewhat
evident that even in the future it is going to be more of a problem to
qualify those discussion in those books being (semi)documented. And when I
look at the Type I or Type II vmm, I dont think I can say those above books
are in the documented corner.

I should not mangale with philosophy, but I was not able to toally kill my
imagination yet :-).

For the actual problem, its been discovered many times and carried to
different places many times than I can count. I see same patterns over and
again when I am asked to debug, even the spacing etc could be same in lot of
cases.

-pro


Everything in life is probability.
We only find out at or after the occurrence.
– Prof. Lawler ( Now in Cornell Univ. )
----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, May 24, 2005 5:04 AM
Subject: Re: Re[2]: [ntdev] Get process full path from PEPROCESS structure

> “Undocumented” is too strong a word. It’s all “documented” if you use
> Windbg’s “dt” command on the data structures you need. Russinovitch and
> Solomon have enough information on the interconnections between those
> object structures, and you can always resort to Gary Nebbett in case of
> doubt. Sure, it’s a bit of a pain because you have to watch out for OS
> builds and such, but that’s the price of advanced functionality.
>
> Alberto.
>
>
> ----- Original Message -----
> From: “ivona prenosilova”
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, May 24, 2005 7:09 AM
> Subject: Re[2]: [ntdev] Get process full path from PEPROCESS structure
>
>
>> Hello Mark,
>>
>> Tuesday, May 24, 2005, 12:37:55 PM, you wrote:
>> CM> As I recall, the last time this was discussed, the general consensus
>> was
>> CM> that it would be better to allow your user mode component to resolve
>> the
>> CM> pathname.
>> and I must again react, that this way is totally unsecure. Even
>> undocumented gathering of full path name (using section object) is far
>> much better than this documented method. Please read the following
>> text done by my friend. The problem is already fixed in new versions
>> of Kerio Personal Firewall - the vendor was contacted some months ago.
>>
>> www.wasteland.cz/!/bypassing.zip - mainly concentrate on violation of
>> point two.
>>
>> –
>> Best regards,
>> Ivona Prenosilova
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Hello ,Omer

Tuesday, May 24, 2005, 10:57:24 AM, you wrote:

OB> Any way to get the FULL path of a process from a given PEPROCESS
OB> structure ?

OB> I saw one code sample in this forum but it didn’t work …

OB> Target systems: win2k, winxp and windows 2003

Here is the code I wrote for my project.
It calculates the CRC of the process’ main module path and name. But
you can modify it to return the path itself.

NTSYSAPI
NTSTATUS
NTAPI
ZwOpenProcess (
OUT PHANDLE ProcessHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PCLIENT_ID ClientId OPTIONAL
);

NTSYSAPI
NTSTATUS
NTAPI
ZwQueryInformationProcess (
IN HANDLE ProcessHandle,
IN PROCESSINFOCLASS ProcessInformationClass,
OUT PVOID ProcessInformation,
IN ULONG ProcessInformationLength,
OUT PULONG ReturnLength OPTIONAL
);

typedef struct _PEB_LDR_DATA {
ULONG Length;
BOOLEAN Initialized;
HANDLE SsHandle;
LIST_ENTRY InLoadOrderModuleList;
LIST_ENTRY InMemoryOrderModuleList;
LIST_ENTRY InInitializationOrderModuleList;
} PEB_LDR_DATA, *PPEB_LDR_DATA;

typedef struct _PEB {
UCHAR Reserved1[4];
PVOID Reserved2;
PVOID ImageBaseAddress;
PPEB_LDR_DATA Ldr;
UCHAR Reserved3[216];
PVOID Reserved4[59];
ULONG SessionId;
} PEB, *PPEB;

typedef struct _LDR_DATA_TABLE_ENTRY {
LIST_ENTRY InLoadOrderLinks;
LIST_ENTRY InMemoryOrderLinks;
LIST_ENTRY InInitializationOrderLinks;
PVOID DllBase;
PVOID EntryPoint;
ULONG SizeOfImage;
UNICODE_STRING FullDllName;
UNICODE_STRING BaseDllName;
ULONG Flags;
USHORT LoadCount;
USHORT TlsIndex;
union {
LIST_ENTRY HashLinks;
struct
{
PVOID SectionPointer;
ULONG CheckSum;
};
};
ULONG TimeDateStamp;
} LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY;

ULONG GetMainModuleNameId(ULONG ProcessId)
{
PROCESS_BASIC_INFORMATION BasicInfo;
NTSTATUS Status;
PPEB Peb;
PPEB_LDR_DATA Ldr;
PLIST_ENTRY LdrHead;
PLIST_ENTRY LdrNext;
HANDLE hProcess = NULL;
CLIENT_ID clientId;
OBJECT_ATTRIBUTES objectAttributes;

clientId.UniqueProcess = (HANDLE)ProcessId;
clientId.UniqueThread = NULL;

InitializeObjectAttributes(
&objectAttributes,
NULL,
0,
NULL,
NULL);

Status = ZwOpenProcess(
&hProcess,
PROCESS_ALL_ACCESS,
&objectAttributes,
&clientId);

if( !NT_SUCCESS(Status) ) return 0;

Status = ZwQueryInformationProcess(
hProcess,
ProcessBasicInformation,
&BasicInfo,
sizeof(BasicInfo),
NULL);

if( !NT_SUCCESS(Status) )
{
ZwClose(hProcess);
return 0;
}

Peb = BasicInfo.PebBaseAddress;

if( Peb == NULL )
{
ZwClose(hProcess);
return 0;
}

Ldr = Peb->Ldr;

if( Ldr == NULL )
{
ZwClose(hProcess);
return 0;
}

LdrHead = &Ldr->InMemoryOrderModuleList;
LdrNext = LdrHead->Flink;

ZwClose(hProcess);

while( LdrNext != LdrHead )
{
PLDR_DATA_TABLE_ENTRY LdrEntry;

LdrEntry = CONTAINING_RECORD(LdrNext, LDR_DATA_TABLE_ENTRY, InMemoryOrderLinks);

if( LdrEntry->DllBase == Peb->ImageBaseAddress )
{
UNICODE_STRING usUpperCase;

if( RtlUpcaseUnicodeString(
&usUpperCase,
&LdrEntry->FullDllName,
TRUE) == STATUS_SUCCESS )
{
ANSI_STRING ansiStr;

if( RtlUnicodeStringToAnsiString(
&ansiStr,
&usUpperCase,
TRUE) == STATUS_SUCCESS )
{
ULONG ulCRC = GetCRC(ansiStr.Buffer, ansiStr.Length);

RtlFreeAnsiString(&ansiStr);
RtlFreeUnicodeString(&usUpperCase);
return ulCRC;
}
RtlFreeUnicodeString(&usUpperCase);
return 0;
}
return 0;
}
LdrNext = LdrEntry->InMemoryOrderLinks.Flink;
}
return 0;
}


Best regards,
Yura mailto:xxxxx@mail.zp.ua

If I correctly recall, you can find a pointer to the full
Unicode path string in the File Object.

Alberto.

----- Original Message -----
From: “PeterGV (OSR)”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”

Sent: Tuesday, May 24, 2005 10:08 AM
Subject: Re:[ntdev] Get process full path from PEPROCESS
structure

> ivona prenosilova wrote:
>> Please read the following
>> text done by my friend. The problem is already fixed in new
>> versions
>> of Kerio Personal Firewall - the vendor was contacted some
>> months ago.
>>
>> www.wasteland.cz/!/bypassing.zip
>>
>
> One of the more cogent articles of its type, it actually makes
> sense. I’m not saying it’s assertions are correct (this isn’t
> my field), but it is certainly interesting.
>
> Recommended reading.
>
> Don’t forget that the ImageName field from the EPROCESS only
> has the NAME of the file, no path info provided. And its
> location does change from release to release. So, some method
> (such as slogging through the section object… Ugh!) is
> probably required.
>
> Peter
> OSR
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

The name derived from a file object should be considered valid only in the
context of a create operation.

Dan

----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, May 25, 2005 3:35 PM
Subject: Re: Re:[ntdev] Get process full path from PEPROCESS structure

> If I correctly recall, you can find a pointer to the full Unicode path
> string in the File Object.
>
> Alberto.
>
>
> ----- Original Message -----
> From: “PeterGV (OSR)”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, May 24, 2005 10:08 AM
> Subject: Re:[ntdev] Get process full path from PEPROCESS structure
>
>
>> ivona prenosilova wrote:
>>> Please read the following
>>> text done by my friend. The problem is already fixed in new versions
>>> of Kerio Personal Firewall - the vendor was contacted some months ago.
>>>
>>> www.wasteland.cz/!/bypassing.zip
>>>
>>
>> One of the more cogent articles of its type, it actually makes sense. I’m
>> not saying it’s assertions are correct (this isn’t my field), but it is
>> certainly interesting.
>>
>> Recommended reading.
>>
>> Don’t forget that the ImageName field from the EPROCESS only has the NAME
>> of the file, no path info provided. And its location does change from
>> release to release. So, some method (such as slogging through the
>> section object… Ugh!) is probably required.
>>
>> Peter
>> OSR
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com