I am trying to figure out how to loop through all PEPROCESS running on my machine. In order to do that I learned I should use the following to access the KTHREAD which then supposedly contains a linked list of all PEPROCESS’s.
PKTHREAD pThread = KeGetCurrentThread();
That being said I am not sure how to change PKTHREAD to an instance of _KTHREAD and I am also not sure which ones of these is the linked list containing all instances of PEPROCESS.
With which lock can you do this?
Threads change so rapidly, itetating them this way is guaranteed to use
corrupted nemory at best, and cause BSOD usually.
You can use ZwQuerySystemInformation to get a snapshot of processes, but I
do not know of a viable way to loop processes, because a global kernel lock
must be held (not documented) to avoid BSODs.
Kind regards, Dejan.
@Dejan_Maksimovic said:
With which lock can you do this?Threads change so rapidly, itetating them this way is guaranteed to use
corrupted nemory at best, and cause BSOD usually.You can use ZwQuerySystemInformation to get a snapshot of processes, but I
do not know of a viable way to loop processes, because a global kernel lock
must be held (not documented) to avoid BSODs.Kind regards, Dejan.
Would you not advise me to use a kernel lock? Also I looked up ZwQuerySystemInformation and it said ZwQuerySystemInformation is no longer available for use as of Windows 8.
Would you not advise me to use a kernel lock?
We would advise you not to use it AT ALL. The PEPROCESS structure is not documented, and it changes from version to version. You can’t use a kernel lock, because you don’t know which kernel lock to use.
ZwQuerySytemInformation is not available in user mode. It’s still present in kernel mode.
@Tim_Roberts said:
Would you not advise me to use a kernel lock?
We would advise you not to use it AT ALL. The PEPROCESS structure is not documented, and it changes from version to version. You can’t use a kernel lock, because you don’t know which kernel lock to use.
ZwQuerySytemInformation is not available in user mode. It’s still present in kernel mode.
It is documented here and it documents it for every version. But if I can’t use a lock then that is an issue why exactly would I not know which lock to use?
Which lock will you use?
It is documented here…
If you think that “documentation” came from Microsoft, then you are confused. It’s not documented by Microsoft, and that means those other sites are just guessing.
The lock you should grab is one that prevents the kernel from making any changes behind your back. You don’t know which lock that is.
@Tim_Roberts said:
It is documented here…
If you think that “documentation” came from Microsoft, then you are confused. It’s not documented by Microsoft, and that means those other sites are just guessing.
The lock you should grab is one that prevents the kernel from making any changes behind your back. You don’t know which lock that is.
Yes I had to resort to a third party because Microsoft does not document it for some reason but I know you can also dump these results via WinDbg. But yes you do bring up a great point that reversing their internals to determine which lock they use will be very challenging. I wonder if I can get a list of processes and then use PsLookupProcessByProcessId to get the EPROCESS of each. Do you happen to know how it works? Here is the documentation but I am not sure what it means by HANDLE since it wants the PID assuming I go through each processes PID and I use my custom EPROCESS struct as the second parameter how would I convert the PID in integer form into a HANDLE that is compatible with PsLookupProcessByProcessId?
Sometimes you wake up and get cheered up by forum posts 
@Dejan_Maksimovic said:
Sometimes you wake up and get cheered up by forum posts
Whats your opinion on using PsLookupProcessByProcessId?
Whats your opinion on using PsLookupProcessByProcessId?
That’s a documented function. So… enjoy using it as you wish.
Peter