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.
Related
I am studying a smartphone project. During compilation process it's installing kernel header files for user space building.
Why do user space apps need kernel headers?
In general, those headers are needed because userspace applications often talk to kernel, passing some data. To do this, they have to agree on the structure of data passed between them.
Most of the kernel headers are only needed by libc library (if you're using one) as it usually hides all the lowlevel aspects from you by the providing abstractions conforming to some standards like POSIX (it will usually provide its own include files). Those headers will, for example, provide all the syscall numbers and definitions of all the structures used by their arguments.
The are, however, some "custom services" provided by kernel that are not handled by libc. One example is creating userspace programs that talk directly to some hardware drivers. That may require passing some data structures (so you need some struct definitions), knowing some magic numbers (so you need some defines), etc.
As an example, take a look at hid-example.c from kernel sources. It will, for example, call this ioctl:
struct hidraw_report_descriptor rpt_desc;
[...]
ioctl(fd, HIDIOCGRDESC, &rpt_desc);
But where did it get HIDIOCGRDESC or know the structure of struct hidraw_report_descriptor? They are of course defined in linux/hidraw.h which this application included.
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.
I can't find any source code on the prerequisites of an MTA compliant COM. I tried changing the ThreadingModel registry key of my object from Apartment to Both, and it results in a crash when a secondary thread calls the method before any data is accessed.
If STA COMs require a message pump, what kind of plumbing code do MTA COM objects require?
I do not think that there is anything special about MTA, except that you need to use synchronization primitives like mutexes to synchronize access to your internal structures. Does the "Multithreaded Apartments" not give you all that you need?
Quoting from the documentation, emphasis is mine:
Because calls to objects are not serialized in any way, multithreaded object concurrency offers the highest performance and takes the best advantage of multiprocessor hardware for cross-thread, cross-process, and cross-machine calling. This means, however, that the code for objects must provide synchronization in their interface implementations, typically through the use of synchronization primitives such as event objects, critical sections, mutexes, or semaphores, which are described later in this section. In addition, because the object doesn't control the lifetime of the threads that are accessing it, no thread-specific state may be stored in the object (in thread local storage).
xmalloc can be used in the process environment only when I write a AIX kernel extension.
what's the memory allocation functions can be called from the interrupt environment in AIX?
thanks.
The network memory allocation routines. Look in /usr/include/net/net_malloc.h. The lowest level is net_malloc and net_free.
I don't see much documentation in IBM's pubs nor the internet. There are a few examples in various header files.
There is public no prototype that I can find for these.
If you look in net_malloc.h, you will see MALLOC and NET_MALLOC macros defined that call it. Then if you grep in all the files under /usr/include, you will see uses of these macros. From these uses, you can deduce the arguments to the macros and thus deduce the arguments to net_malloc itself. I would make one routine that is a pass through to net_malloc that you controlled the interface to.
On your target system, do "netstat -m". The last bucket size you see will be the largest size you can call net_malloc with the M_NOWAIT flag. M_WAIT can be used only at process time and waits for netm to allocate more memory if necessary. M_NOWAIT returns with a 0 if there is not enough memory pinned. At interrupt time, you must use M_NOWAIT.
There is no real checking for the "type" but it is good to pick an appropriate type for debugging purposes later on. The netm output from kdb shows the type.
In a similar fashion, you can figure out how to call net_free.
Its sad IBM has chosen not to document this. An alternative to get this information officially is to pay for an "ISV" question. If you are doing serious AIX development, you want to become an ISV / Partner. It will save you lots of heart break. I don't know the cost but it is within reach of small companies and even individuals.
This book is nice to have too.