Hi All,
I am developing an Antirootkit product.
My requirement is that I have to retrieve hidden process’s image path and as the process in context is of rootkit it is not possible to get image path in usermode.
One way I am using is in my kernel module(In my driver) I have used ZwQueryInformationProcess with ProcessBasicInformation class, In it I am getting address of PEB in which I can get the image path, But as we know PEB is usermode datastructure so whenever I derefrence the PEB address I am getting the image path of the process in whose context my code is running.
Please help me to get the result.
Thanks & Regerds,
Amit.
You can use ZwQueryInformationProcess with ProcessInformationClass of ProcessImageFileName
or ZwQuerySystemInformation with SYSTEM_PROCESS_INFORMATION’s undocumented member ProcessName:
http://www.volynkin.com/procenum.htm
Letting a compromised system validate its own integrity is absurd.
> Letting a compromised system validate its own integrity is absurd.
If it was the case, the very idea of malware detection, let alone cleaning , would be infeasible in itself. Certainly, there is no way to insure 100% probablitity of detecting malware, bit still the idea in itself as not as absurd as you claim…
Anton Bassov
ZwQuerySystemInformation will provide ProcessName but my requirement is Image path.
It’s a Halting problem (validation, that is); that’s pretty absurd, but
nowhere near as absurd as the amount of money people pour in to a
technology about which no deterministic statements may be stated
honestly. That being said, like all things security, it is quite
profitable, and that’s a damn good reason in my book.
In either case, AlyahDot, Kurt Godel would be proud.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, August 06, 2007 03:50
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to get Image path of a running process?
Letting a compromised system validate its own integrity is absurd.
If it was the case, the very idea of malware detection, let alone
cleaning , would be infeasible in itself. Certainly, there is no way to
insure 100% probablitity of detecting malware, bit still the idea in
itself as not as absurd as you claim…
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other 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
Amit Kulkarni wrote:
ZwQuerySystemInformation will provide ProcessName but my requirement is Image path.
Rename “ProcessName” to “ImagePath” in your typedef struct and it will be the image path.
You’re welcome.
You mean that I will use following structure
typedef struct _SYSTEM_PROCESSES { // Information Class 5
ULONG NextEntryDelta;
ULONG ThreadCount;
ULONG Reserved1[6];
LARGE_INTEGER CreateTime;
LARGE_INTEGER UserTime;
LARGE_INTEGER KernelTime;
// UNICODE_STRING ProcessName;
UNICODE_STRING ImagePath;
KPRIORITY BasePriority;
ULONG ProcessId;
ULONG InheritedFromProcessId;
ULONG HandleCount;
ULONG Reserved2[2];
VM_COUNTERS VmCounters;
IO_COUNTERS IoCounters; // Windows 2000 only
SYSTEM_THREADS Threads[1];
} SYSTEM_PROCESSES, *PSYSTEM_PROCESSES;
But my friend renaming a field name does not give you the path.
I am getting process name e.g. temp.exe in ProcessName instead of I want c:\temp.exe or ??\c:\temp.exe
How many times do we have to answer this one? There are three options:
-
For Windows 2000 and later - use PsSetLoadImageNotifyRoutine and build
your own database of process to image mappings. This is the safe and
supported model.
-
For Windowx XP and later use the UNDOCUMENTED CALL:
PCHAR PsGetProcessImageFileName( PEPROCESS Process );
-
Use the UNDOCUMENTED CALL ZwQueryInformationProcess then by doing a
bunch of work (note: very easy to miss a corner case) get the path out of
the PEB.
Personally, I would avoid option 3, and stick with the other two.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
Don,
Personally, I would avoid option 3, and stick with the other two.
PsSetLoadImageNotifyRoutine () is a good solution, but is of no help to you if the process in question
had been launched before your driver was loaded, and PsGetProcessImageFileName() returns just a file name, rather than the whole path. Therefore, ZwQueryInformationProcess() is the only option that is guaranteed to work.
Here we have 2 cases
-
The target OS is >=XP. In this case you can use infoclass 0x1B, and get the whole thing in one go. This is totally undocumented infoclass
-
The target OS is >=W2K. In this case you have use infoclass 0 to get a pointer to PEB, so that you can retrieve all info from PEB. This option is *not* undocumented - MSDN provides all info that you need, although with a warning. Please note that PEB is user-mode structure, and, hence, may be unusable in the caller’s context - in order to make any use of it, you have to attach your thread to the address space of the target process…
Anton Bassov
wrote in message news:xxxxx@ntdev…
> Don,
>
>> Personally, I would avoid option 3, and stick with the other two.
>
>
> PsSetLoadImageNotifyRoutine () is a good solution, but is of no help to
> you if the process in question
> had been launched before your driver was loaded, and
> PsGetProcessImageFileName() returns just a file name, rather than the
> whole path. Therefore, ZwQueryInformationProcess() is the only option
> that is guaranteed to work.
The solution here is to make your driver an early load (boot or system
load) driver, so that you do not miss processes.
> Here we have 2 cases
>
> 1. The target OS is >=XP. In this case you can use infoclass 0x1B, and
> get the whole thing in one go. This is totally undocumented infoclass
>
> 2. The target OS is >=W2K. In this case you have use infoclass 0 to get a
> pointer to PEB, so that you can retrieve all info from PEB. This option
> is not undocumented - MSDN provides all info that you need, although
> with a warning. Please note that PEB is user-mode structure, and, hence,
> may be unusable in the caller’s context - in order to make any use of it,
> you have to attach your thread to the address space of the target
> process…
>
Technically it is undocumented since there is nothing in any WDK
documentation that specifies this call is supported. Also, this method
requires that care be taken as you can attack the driver through PEB
manipulation in user space. Getting this right is not easy.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
> Also, this method requires that care be taken as you can attack the driver through PEB
manipulation in user space.
This is true…
Any process has an access to its own PEB, regardless of user privileges. Therefore, if driver reads PEB, restricted users may *deliberately* try to exploit it in order to gain access to the kernel and/or elevate their privilege level somehow. Even if they fail to meet their objectives, they still may be quite successfull in causing BSOD…
Anton Bassov