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.
Related
I am working on a windows system. I need to create a shared memory for inter process communication to share objects (containing pointers as members). Or some equivalent way for fast transfer of objects from a generator process to a receiver process. the size of the objects are also huge. How do i do that? The porblem is that even if i share the objects I need a way so that the other process gets the access to the locations pointed by the pointers in the objects. And sharing each of those locations for each object is not feasible.
It's difficult to say without more details, but I would consider a memory mapped file. How you create the file depends on whether you need to communicate between sessions or not. You would also need a notification mechanism when new data was posted. You could do that with a registered message, but again that's only possible if your processes are in the same session/desktop.
I can't really be more specific without knowing the details of the requirement.
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.
Can someone tell me how to get address of USER objects in paged pool on windows 8 (some code or any ideas)?
F.e. on win 7 we can do this by min. 2 ways: by CsrClientConnectToServer and gSharedInfo.
Thanks!
Ok. Here are some of the articles which may help you in finding your answer..
http://msdn.microsoft.com/en-us/library/ms810501.aspx
Object Manager is the centralized resource broker in the Windows NT line of Operating Systems, which keeps track of the resources allocated to processes. It is resource-agnostic and can manage any type of resource, including device and file handles. All resources are represented as objects, each belonging to a logical namespace for categorization and having a type that represents the type of the resource, which exposes the capabilities and functionalities via properties.
An object is kept available until all processes are done with it; Object Manager maintains the record of which objects are currently in use via reference counting, as well as the ownership information. Any system call that changes the state of resource allocation to processes goes via the Object Manager.
Source: http://en.wikipedia.org/wiki/Object_Manager_(Windows)
Something about Kernal Objects and their difference from the GDI/User Objects
http://windowsarchitecture.wordpress.com/2010/11/24/kernel-objects-%E2%80%9Care%E2%80%9D-different-from-gdi-user-objects/
Here is an article which may give you some idea about paged pool in the kernal..
http://vishu25.wordpress.com/2012/08/30/kernelmemory/
And below paper will surely help you in your deeper study...
www.mista.nu/research/MANDT-kernelpool-PAPER.pdf
Let me know if it helps you..
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.
Upon analysis, I learnt that even _KPROCESS objects can be members of the ActiveProcessLinks list. What is the difference between _EPROCESS and _KPROCESS objects? When is one created and one not? What are the conceptual differences between them?
This is simplified, but the kernel mode portion of the Windows O/S is broken up into three pieces: the HAL, the Kernel, and the Executive Subsystems. The Executive Subsystems deal with general O/S policy and operation. The Kernel deals with process architecture specific details for low level operations (e.g. spinlocks, thread switching) as well as scheduling. The HAL deals with differences that arise in particular implementations of a processor architecture (e.g. how interrupts are routed on this implementation of the x86). This is all explained in greater detail in the Windows Internals book.
When you create a new Win32 process, both the Kernel and the Executive Subsystems want to track it. For example, the Kernel wants to know the priority and affinity of the threads in the process because that's going to affect scheduling. The Executive Subsystems want to track the process because, for example, the Security Executive Subsystem wants to associate a token with the process so we can do security checking later.
The structure that the Kernel uses to track the process is the KPROCESS. The structure that the Executive Subsystems use to track it is the EPROCESS. As an implementation detail, the KPROCESS is the first field of the EPROCESS, so the Executive Subsystems allocate the EPROCESS structure and then call the Kernel to initialize the KPROCESS portion of it. In the end, both structures are part of the Process Object that represents the instance of the user process. This should also all be covered in the Windows Internals book.
-scott
Have a look here:
http://channel9.msdn.com/Shows/Going+Deep/Arun-Kishan-Process-Management-in-Windows-Vista
EPROCESS is the kernel mode equivalent of the PEB from user mode. More details can be found in this document on Alex Ionescu's site as well as the book by Schreiber and other books about the NT internals.
Use dt in WinDbg to get an idea how they look.
EPROCESS is not available in user mode. Neither is KPROCESS.
KPROCESS is a subset of EPROCESS. If you look at the fields in a debugger, you'll see the KPROCESS contains fields more related to scheduling and book-keeping of the process at a lower level, while EPROCESS has higher-level process contexts inside of it. The names, as far as I am aware, come from different subsystems that interact with these structures (the Executive has structures and functions frequently prefixed with Ex while the Kernel has structures and functions frequently prefixed with Ke)
You can see this in different documented functions. Consider the prototype for KeStackAttachProcess ( http://msdn.microsoft.com/en-us/library/ff549659(v=vs.85).aspx ), which is a Ke functions and takes a KPROCESS. There aren't any exported and documented Ex functions that accept EPROCESS (or KPROCESS), but Ps functions deal entirely in EPROCESSES.
A similar divide exists for threads, with KTHREAD and ETHREAD.