There is a Flink and Blink (Forward Link and Backward Link) for a double-linked list of processes. There is a process identifier. All of this is packed in a struct that is referenced to as PEPROCESS or _KPROCESS. But where are those and what are the other elements in this structure?
Or, if the answer is neither short nor simple, where can one find references if not in the documentation or header files? (Which is the place i looked and probably overlooked something.)
EPROCESS reference
The EPROCESS structure is an opaque
structure that serves as the process
object for a process.
Some routines, such as
PsGetProcessCreateTimeQuadPart, use
EPROCESS to identify the process to
operate on. Drivers can use the
PsGetCurrentProcess routine to obtain
a pointer to the process object for
the current process and can use the
ObReferenceObjectByHandle routine to
obtain a pointer to the process object
that is associated with the specified
handle. The PsInitialSystemProcess
global variable points to the process
object for the system process.
Note that a process object is an
Object Manager object. Drivers should
use Object Manager routines such as
ObReferenceObject and
ObDereferenceObject to maintain the
object’s reference count.
This means, that you shouldn't care about what the members of a the process structure are. Nevertheless there are sources which detail the layout of the process structure.
This book has a more in detail description what the individual members are.
The EPROCESS structure is documented in the windows debugging symbols.
While connected to a kernel with windbg, assuming you have the debugging symbols properly set up, issuing the command "dt nt!_EPROCESS" should give you the layout for the EPROCESS struct specific to the version of the kernel you are attached to.
The EPROCESS structure are especially opaque and can only be found per build, by examining the data types exported by build debugging symbols.
So you could do the following:
Download volatility here
Run volatility on one of their sample memory dumps or your own dump if you'd want to.
Using the volshell.py plug-in, run
dt('_EPROCESS')
This would produce an output of the structure of EPROCESS and various other structures in the Windows kernel
or you could just see the structure contents here
This also might prove useful
Related
I am doing some work that requires interprocess communication. I created a memory-mapped file using CreateFileMapping (using windows API) in one process. In another process I used OpenFileMapping and MapViewOfFile to access the (supposedly) same data. I found that the address of these data are different in each process, is this expected or have I done something wrong?
This is completely expected and normal behavior.
Different processes have different address spaces. A pointer in one process is not valid in another process. What is important is that each process obtains its own local valid pointer to your shared mapping object. When each process wants to access the data inside of the shared mapping object, the access needs to be done using pointers and addresses that are relative to each process.
This is covered in more detail in Microsoft's own documentation: File Mapping
is there any way to determine which driver is the owner of the hanlde?
I mean is it stored any where is Windows objects?
I can see handles via volatilty but all kernel handles are assigned to System.exe pid:4, I need to know exactly which driver is using this system handle?
thanks
Is there any way to determine which driver is the owner of the
handle?
When kernel modules (or thread in kernel space) call Kernel API (NtCreateFile, for example), the handles are allocated from handle table of System process. In this case, the answer is: no.
I mean is it stored any where is Windows objects?
I guess no
I need to know exactly which driver is using this system handle?
Depend on analisys you're doing. If you need to associate an object back to the driver that owns it, you can try to analize _POOL_HEADER structure to obtain information about who produced the allocation. BUT if you need to analyze an executive object (_FILE object, for example), the PoolTag field in this header will be equal to ObjectType.Key, so this way is not very useful for your purpose.
In general, if you're looking for which resources a process can access (i.e. memory-mapped files), you can analyze with memmap volatility's plugin the process' page tables and so the memory area of the process. I suggest you to use VAD structures' dedicated plugin so that you can gather an high-level information about virtual address space of the process.
In Windows, what is the formal way of identifying a process uniquely? I am not talking about PID, which is allocated dynamically, but a unique ID or a name which is permanent to that process. I know that every program/process has a security descriptor but it seems to hold SIDs for loggedin user and group (not the process). We cannot use the path and name of executable from where the process starts as that can change.
My aim is to identify a process in the kernel mode and allow it to perform certain operation. What is the easiest and best way of doing this?
Your question is too vague to answer properly. For example how could the path possibly change (without poking around in kernel memory) after creation of a process? And yes, I am aware that one could hook into the memory-mapping process during process creation to replace the image originally destined to be loaded with another. Point is that a process is merely one instance of running a given executable. And it's not clear what exact tampering attempts you want to counter here.
But from kernel mode you do have the ability to simply use the pointer to the EPROCESS structure. No need to use the PID, although that will be unique while the process is still alive.
So assuming your process uses an IRP to communicate to the driver (whether it be WriteFile, ReadFile, DeviceIoControl or something more exotic), in order to register itself, you can use IoGetCurrentProcess to get the PEPROCESS value which will be unique to the process.
While the structure itself is not officially documented, hints can be gleaned from the "Windows Internals" book (in its various incarnations), the dt (Display Type) command in WinDbg (and friends) as well as from third-party resources on the internet (e.g. here, specific to Vista).
The process objects are kept in several linked lists. So if you know the (officially undocumented!!!) layout for a particular OS version, you may traverse the lists to get from one to the next process object (i.e. EPROCESS structure).
Cautionary notes
Make sure to reference the object of the process, by using the respective object manager routines. Otherwise you cannot be certain it's safe to both reach into these structures (which is anyway unsafe, since you cannot rely on their layout across OS versions) or to pass it to functions that expect a PEPROCESS.
As a side-note: Harry Johnston is of course right to assert that a privileged user can insert arbitrary (well almost arbitrary) code into the TCB in order to thwart your protective measures. In the end it is going to be an arms race.
Also keep in mind that similar to PIDs, theoretically the value of the PEPROCESS may be recycled. But in both cases you can simply counter this by invalidating whatever internal state you keep in your driver that allows the process to do its magic, whenever the process goes down. Using something like PsSetCreateProcessNotifyRoutine would seem to be a good method here. In order to translate your process handle from the callback to a PEPROCESS value, use ObReferenceObjectByHandle.
An alternative of countering recycling of the PID/PEPROCESS is by keeping a reference to the process object and thus keeping it in a kind of undead state (similar to not closing a handle in user mode), although the main thread may have finished.
As the title says, I want to associate a random bit of data (ULONG) with a running process on the local machine. I want that data persisted with the process it's associated with, not the process thats reading & writing the data. Is this possible in Win32?
Yes but it can be tricky. You can't access an arbitrary memory address of another process and you can't count on shared memory because you want to do it with an arbitrary process.
The tricky way
What you can do is to create a window (with a special and known name) inside the process you want to decorate. See the end of the post for an alternative solution without windows.
First of all you have to get a handle to the process with OpenProcess.
Allocate memory with VirtualAllocEx in the other process to hold a short method that will create a (hidden) window with a special known name.
Copy that function from your own code with WriteProcessMemory.
Execute it with CreateRemoteThread.
Now you need a way to identify and read back this memory from another process other than the one that created that. For this you simply can find the window with that known name and you have your holder for a small chunk of data.
Please note that this technique may be used to inject code in another process so some Antivirus may warn about it.
Final notes
If Address Space Randomization is disabled you may not need to inject code in the process memory, you can call CreateRemoteThread with the address of a Windows kernel function with the same parameters (for example LoadLibrary). You can't do this with native applications (not linked to kernel32.dll).
You can't inject into system processes unless you have debug privileges for your process (with AdjustTokenPrivileges).
As alternative to the fake window you may create a suspended thread with a local variable, a TLS or stack entry used as data chunk. To find this thread you have to give it a name using, for example, this (but it's seldom applicable).
The naive way
A poor man solution (but probably much more easy to implement and somehow even more robust) can be to use ADS to hide a small data file for each process you want to monitor (of course an ADS associated with its image then it's not applicable for services and rundll'ed processes unless you make it much more complicated).
Iterate all processes and for each one create an ADS with a known name (and the process ID).
Inside it you have to store the system startup time and all the data you need.
To read back that informations:
Iterate all processes and check for that ADS, read it and compare the system startup time (if they mismatch then it means you found a widow ADS and it should be deleted.
Of course you have to take care of these widows so periodically you may need to check for them. Of course you can avoid this storing ALL these small chunk of data into a well-known location, your "reader" may check them all each time, deleting files no longer associated to a running process.
I am reading < windows via c/c++ >, it describes GetModuleHandle() API as below:
When you call this function, you pass a zero-terminated string that specifies the name of an executable or DLL file loaded into the calling process's address space. If the system finds the specified executable or DLL name, GetModuleHandle returns the base address where that executable or DLL;s file image is loaded.
I am wondering where does the system look for the file name? When I loaded some file into my process address space, is there some centralized table to store the mapping of all the loaded files' names and their load addresses? If we search based on a string match, is it kind of low efficiency?
Many thanks for your insigts.
The loaded module info is maintained as a linked list in process' PEB, in a struct named PEB_LDR_DATA. If you get the PEB pointer, you can traverse through this list and get information like DLL name, base address, entry point, size etc. Check out these pages:
http://msdn.microsoft.com/en-us/library/aa813708.aspx
http://www.codeproject.com/KB/threads/CmdLine.aspx
It looks in the loader (the Windows name for the dynamic linker)'s internal data structure.
GetModuleHandle only works for DLLs that you have loaded in the current process. Whenever the loader loads a DLL into the process, it of course maintains a data structure that includes the module's name. No need to visit the file system.
LdrInitializeThunk runs in user space to start the process of pulling in the DLLs.
I wanted confirm (see the answer of swatkat), that in my information the implementation of GetModuleHandle() really look inside of Wine and ReactOS (and this). You will see the implementation of GetModuleHandle(). The developers of Wine and ReactOS disassemble the code of Windows and implemented his own code based on the results of disassemble. So the code do in the most cases the same as Windows code do.
If you want you can implement your own implementation of GetModuleHandle() base of VirtualAllocEx() only. See my old answer for details. (If you not yet know the handle returned by the function GetModuleHandle() is the Address of the corresponding module in the memory, so one need just find in any way the dll in the memory of the current process).