If you recall, I previously referred to system resources such as processes, files, threads, and so on, as objects (or executive objects). The executive objects are managed by a component of a kernel called the object manager. Every executive object has a structure associated with it (such as _EPROCESS for process object). The executive object structure is preceded by a _OBJECT_HEADER structure, which contains information about an object's type and some reference counters. The _OBJECT_HEADER is then preceded by zero or more optional headers. In other words, you can think of an object as the combination of executive object structure, the object header, and the optional headers, as shown in the following screenshot:

To store an object, memory is needed, and this memory is allocated by the Windows memory manager from kernel pools. A kernel pool is a range of memory that can be divided into smaller blocks for storing data such as objects. The pool is divided into a paged pool (whose content may be swapped to disk) and a non-paged pool (whose content permanently resides in memory). The objects (such as process and threads) are kept in a non-paged pool in the kernel, which means they will always reside in the physical memory.

When the Windows kernel receives the request to create an object (possibly due to API calls made by processes such as CreateProcess or CreateFile), memory is allocated for the object either from the paged pool or non-paged pool (depending on the object type). This allocation is tagged by prepending a _POOL_HEADER structure to the object, so that in memory, each object will have a predictable structure, similar to the ones shown in the following screenshot. The _POOL_HEADER structure includes a field named PoolTag that contains a four-byte tag (referred to as a pool tag). This pool tag can be used to identify an object. For the process object, the tag is Proc and for the File object, the tag is File, and so on. The _POOL_HEADER  structure also contains fields that tell the size of the allocation and the type of memory (paged or non-paged pool) it describes:

You can think of all the process objects residing in the non-paged pool of kernel memory (which ultimately maps to physical memory) as marked with a tag, Proc. It is this tag that the Volatility's psscan uses as the starting point to identify the process object. In particular, it scans the physical memory for the Proc tag to identify the pool tag allocation associated with the process object, and it further confirms it by using a more robust signature and heuristics. Once the psscan finds the process object, it extracts the necessary information from its _EPROCESS structure. The psscan repeats this process until it finds all the process objects. In fact, many volatility plugins rely on pool tag scanning to identify and extract information from the memory image.

The psscan plugin not only detects the hidden process, because of the approach it uses, but it can also detect terminated processes. When an object is destroyed (such as when a process is terminated), the memory allocation containing that object is released back to the kernel pool, but the content in the memory is not immediately overwritten, which means the process object can still be in the memory, unless that memory is allocated for a different purpose. If the memory containing the terminated process object is not overwritten, then psscan can detect the terminated process.

At this point, you should have an understanding of how Volatility plugins work; most plugins use similar logic. To summarize, critical information exists in the data structures maintained by the kernel. The plugins rely on finding and extracting information from these data structures. The approach for finding and extracting forensic artifacts varies; some plugins rely on walking the doubly linked list (like pslist), and some use the pool tag scanning technique (such as psscan) to extract relevant information.