EPROCESS KPROCESS PEB 《寒江独钓》内核学习笔记（2）
在学习笔记(1)中，我们学习了IRP的数据结构的相关知识，接下来我们继续来学习内核中很重要的另一批数据结构: EPROCESS/KPROCESS/PEB。把它们放到一起是因为这三个数据结构及其外延和windows中进程的表示关系密切，我们在做进程隐藏和进程枚举的时候一定会涉及到这3类数据结构，所以这里有必要及时做一下总结，做个学习笔记，理清思路。
1. 相关阅读材料
《windows 内核原理与实现》 --- 潘爱民
《深入解析windows操作系统(第4版,中文版)》 --- 潘爱民
《Windows核心编程(第四版)》中文版
首先我们来看一张windows的内核分布图，我们之后要讲的执行体和内核层都在上面。
每个windows进程都是由一个执行体进程块(EPROCESS)块来表示的。"EPROCESS块中除了包含许多与进程有关的属性之外，还包含和指向许多其他的相关数据结构"(这也是为什么能利用EPROCESS进行进程枚举的原因)。例如，每个进程都有一个或多个线程，这些线程由执行体线程块(ETHREAD)来表示。EPROCESS块和相关的数据结构位于系统空间中，不过，进程环境块(PEB)是个例外。它位于进程地址空间中(因为它包含一些需要由用户模式代码来修改的信息)。
除了EPROCESS块以外，windows子系统进程(Csrss.exe)为每个windows进程维护了一个类似的结构。而且，windows子系统的内核部分(Win32k.sys)有一个针对每个进程的数据结构(KPROCESS)，当一个线程第一次调用windows的USER或GDI函数(它们在内核模式中实现的)时，此数据结构就会被创建。在学习的一开始，我们对这些数据结构在windows系统的层级位置和大致的作用有一个了解很关键。接下来，我们来详细了解这些数据结构。
一 . EPROCESS
EPEOCESS(执行体进程块，E是Execute的意思，注意和KPROCESS区分开来)位于内核层之上(KPROCESS就内核层，我们之后会学习到KPROCESS)，它侧重于提供各种管理策略，同时为上层应用程序提供基本的功能接口。所以，在执行体层的进程和线程数据结构中，有些成员直接对应于上层应用程序中所看到的功能实体。
我们使用winDbg来查看windows XP下的EPROCESS数据结构(winDbg双机调试的方法在《寒江独钓》第一章以及网上有很多成熟的使用说明)。
我们接下来的例子都以windows XP下的notepad.exe作为实验材料。首先，启动winDbg后，找到notepad.exe这个进程(你在虚拟机里要先启动notepad.exe哦)
!process 0 0 //查看当前进程
....
PROCESS 823e5490 SessionId: 0 Cid: 0af0 Peb: 7ffd5000 ParentCid: 02b8
DirBase: 0f200340 ObjectTable: e283dc30 HandleCount: 106.
Image: alg.exe PROCESS 824a7020 SessionId: 0 Cid: 00a0 Peb: 7ffda000 ParentCid: 0668
DirBase: 0f2001a0 ObjectTable: e292f898 HandleCount: 44.
Image: notepad.exe
...
可以看到 PROCESS 824a7020 ,824a7020 就是notepad.exe的_EPROCESS结构地址(这个地址在notepad的生命周期中就不会变了)
dt _eprocess 824a7020 //查看notepad.exe的_EPROCESS
kd> dt _eprocess 824a7020
ntdll!_EPROCESS
+0x000 Pcb : _KPROCESS
+0x06c ProcessLock : _EX_PUSH_LOCK
+0x070 CreateTime : _LARGE_INTEGER 0x1ceee34`5d8ce8a2
+0x078 ExitTime : _LARGE_INTEGER 0x0
+0x080 RundownProtect : _EX_RUNDOWN_REF
+0x084 UniqueProcessId : 0x000000a0
+0x088 ActiveProcessLinks : _LIST_ENTRY [ 0x8055b158 - 0x823e5518 ]
+0x090 QuotaUsage : [3] 0xa50
+0x09c QuotaPeak : [3] 0xc48
+0x0a8 CommitCharge : 0x184
+0x0ac PeakVirtualSize : 0x244d000
+0x0b0 VirtualSize : 0x1f87000
+0x0b4 SessionProcessLinks : _LIST_ENTRY [ 0xf8b6a014 - 0x823e5544 ]
+0x0bc DebugPort : (null)
+0x0c0 ExceptionPort : 0xe1982848
+0x0c4 ObjectTable : 0xe292f898 _HANDLE_TABLE
+0x0c8 Token : _EX_FAST_REF
+0x0cc WorkingSetLock : _FAST_MUTEX
+0x0ec WorkingSetPage : 0xc6af
+0x0f0 AddressCreationLock : _FAST_MUTEX
+0x110 HyperSpaceLock : 0
+0x114 ForkInProgress : (null)
+0x118 HardwareTrigger : 0
+0x11c VadRoot : 0x82401480
+0x120 VadHint : 0x8256a530
+0x124 CloneRoot : (null)
+0x128 NumberOfPrivatePages : 0xc0
+0x12c NumberOfLockedPages : 0
+0x130 Win32Process : 0xe109b210
+0x134 Job : (null)
+0x138 SectionObject : 0xe19d2c18
+0x13c SectionBaseAddress : 0x01000000
+0x140 QuotaBlock : 0x82cf5db8 _EPROCESS_QUOTA_BLOCK
+0x144 WorkingSetWatch : (null)
+0x148 Win32WindowStation : 0x0000003c
+0x14c InheritedFromUniqueProcessId : 0x00000668
+0x150 LdtInformation : (null)
+0x154 VadFreeHint : (null)
+0x158 VdmObjects : (null)
+0x15c DeviceMap : 0xe21f5258
+0x160 PhysicalVadList : _LIST_ENTRY [ 0x824a7180 - 0x824a7180 ]
+0x168 PageDirectoryPte : _HARDWARE_PTE_X86
+0x168 Filler : 0
+0x170 Session : 0xf8b6a000
+0x174 ImageFileName : [16] "notepad.exe"
+0x184 JobLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
+0x18c LockedPagesList : (null)
+0x190 ThreadListHead : _LIST_ENTRY [ 0x823c224c - 0x823c224c ]
+0x198 SecurityPort : (null)
+0x19c PaeTop : 0xf8cba1a0
+0x1a0 ActiveThreads : 1
+0x1a4 GrantedAccess : 0x1f0fff
+0x1a8 DefaultHardErrorProcessing : 1
+0x1ac LastThreadExitStatus : 0
+0x1b0 Peb : 0x7ffda000 _PEB
+0x1b4 PrefetchTrace : _EX_FAST_REF
+0x1b8 ReadOperationCount : _LARGE_INTEGER 0x1
+0x1c0 WriteOperationCount : _LARGE_INTEGER 0x0
+0x1c8 OtherOperationCount : _LARGE_INTEGER 0x248
+0x1d0 ReadTransferCount : _LARGE_INTEGER 0x57ce
+0x1d8 WriteTransferCount : _LARGE_INTEGER 0x0
+0x1e0 OtherTransferCount : _LARGE_INTEGER 0x18846
+0x1e8 CommitChargeLimit : 0
+0x1ec CommitChargePeak : 0x184
+0x1f0 AweInfo : (null)
+0x1f4 SeAuditProcessCreationInfo : _SE_AUDIT_PROCESS_CREATION_INFO
+0x1f8 Vm : _MMSUPPORT
+0x238 LastFaultCount : 0
+0x23c ModifiedPageCount : 7
+0x240 NumberOfVads : 0x42
+0x244 JobStatus : 0
+0x248 Flags : 0xd0800
+0x248 CreateReported : 0y0
+0x248 NoDebugInherit : 0y0
+0x248 ProcessExiting : 0y0
+0x248 ProcessDelete : 0y0
+0x248 Wow64SplitPages : 0y0
+0x248 VmDeleted : 0y0
+0x248 OutswapEnabled : 0y0
+0x248 Outswapped : 0y0
+0x248 ForkFailed : 0y0
+0x248 HasPhysicalVad : 0y0
+0x248 AddressSpaceInitialized : 0y10
+0x248 SetTimerResolution : 0y0
+0x248 BreakOnTermination : 0y0
+0x248 SessionCreationUnderway : 0y0
+0x248 WriteWatch : 0y0
+0x248 ProcessInSession : 0y1
+0x248 OverrideAddressSpace : 0y0
+0x248 HasAddressSpace : 0y1
+0x248 LaunchPrefetched : 0y1
+0x248 InjectInpageErrors : 0y0
+0x248 VmTopDown : 0y0
+0x248 Unused3 : 0y0
+0x248 Unused4 : 0y0
+0x248 VdmAllowed : 0y0
+0x248 Unused : 0y00000 (0)
+0x248 Unused1 : 0y0
+0x248 Unused2 : 0y0
+0x24c ExitStatus : 259
+0x250 NextPageColor : 0x8d96
+0x252 SubSystemMinorVersion : 0 ''
+0x253 SubSystemMajorVersion : 0x4 ''
+0x252 SubSystemVersion : 0x400
+0x254 PriorityClass : 0x2 ''
+0x255 WorkingSetAcquiredUnsafe : 0 ''
+0x258 Cookie : 0x5c77be6c
并结合windows的"开源"学习版本的源代码: WRK。 在\base\ntos\inc\ps.h中，可以找到相关的数据结构的定义说明。
typedef struct _EPROCESS
{
KPROCESS Pcb; EX_PUSH_LOCK ProcessLock; LARGE_INTEGER CreateTime;
LARGE_INTEGER ExitTime; EX_RUNDOWN_REF RundownProtect; HANDLE UniqueProcessId; LIST_ENTRY ActiveProcessLinks; SIZE_T QuotaUsage[PsQuotaTypes];
SIZE_T QuotaPeak[PsQuotaTypes];
SIZE_T CommitCharge; SIZE_T PeakVirtualSize;
SIZE_T VirtualSize; LIST_ENTRY SessionProcessLinks; PVOID DebugPort;
PVOID ExceptionPort;
PHANDLE_TABLE ObjectTable; EX_FAST_REF Token; PFN_NUMBER WorkingSetPage;
KGUARDED_MUTEX AddressCreationLock;
KSPIN_LOCK HyperSpaceLock; struct _ETHREAD *ForkInProgress;
ULONG_PTR HardwareTrigger; PMM_AVL_TABLE PhysicalVadRoot;
PVOID CloneRoot;
PFN_NUMBER NumberOfPrivatePages;
PFN_NUMBER NumberOfLockedPages;
PVOID Win32Process;
struct _EJOB *Job;
PVOID SectionObject; PVOID SectionBaseAddress; PEPROCESS_QUOTA_BLOCK QuotaBlock; PPAGEFAULT_HISTORY WorkingSetWatch;
HANDLE Win32WindowStation;
HANDLE InheritedFromUniqueProcessId; PVOID LdtInformation;
PVOID VadFreeHint;
PVOID VdmObjects;
PVOID DeviceMap; PVOID Spare0[3];
union
{
HARDWARE_PTE PageDirectoryPte;
ULONGLONG Filler;
};
PVOID Session;
UCHAR ImageFileName[ 16 ]; LIST_ENTRY JobLinks;
PVOID LockedPagesList; LIST_ENTRY ThreadListHead; PVOID SecurityPort;
PVOID PaeTop; ULONG ActiveThreads; ACCESS_MASK GrantedAccess; ULONG DefaultHardErrorProcessing; NTSTATUS LastThreadExitStatus; PPEB Peb; EX_FAST_REF PrefetchTrace; LARGE_INTEGER ReadOperationCount;
LARGE_INTEGER WriteOperationCount;
LARGE_INTEGER OtherOperationCount;
LARGE_INTEGER ReadTransferCount;
LARGE_INTEGER WriteTransferCount;
LARGE_INTEGER OtherTransferCount; SIZE_T CommitChargeLimit;
SIZE_T CommitChargePeak; PVOID AweInfo; SE_AUDIT_PROCESS_CREATION_INFO SeAuditProcessCreationInfo; MMSUPPORT Vm; LIST_ENTRY MmProcessLinks; ULONG ModifiedPageCount; ULONG JobStatus; union
{
ULONG Flags; struct {
ULONG CreateReported : 1;
ULONG NoDebugInherit : 1;
ULONG ProcessExiting : 1;
ULONG ProcessDelete : 1;
ULONG Wow64SplitPages : 1;
ULONG VmDeleted : 1;
ULONG OutswapEnabled : 1;
ULONG Outswapped : 1;
ULONG ForkFailed : 1;
ULONG Wow64VaSpace4Gb : 1;
ULONG AddressSpaceInitialized : 2;
ULONG SetTimerResolution : 1;
ULONG BreakOnTermination : 1;
ULONG SessionCreationUnderway : 1;
ULONG WriteWatch : 1;
ULONG ProcessInSession : 1;
ULONG OverrideAddressSpace : 1;
ULONG HasAddressSpace : 1;
ULONG LaunchPrefetched : 1;
ULONG InjectInpageErrors : 1;
ULONG VmTopDown : 1;
ULONG ImageNotifyDone : 1;
ULONG PdeUpdateNeeded : 1; // NT32 only
ULONG VdmAllowed : 1;
ULONG SmapAllowed : 1;
ULONG CreateFailed : 1;
ULONG DefaultIoPriority : 3;
ULONG Spare1 : 1;
ULONG Spare2 : 1;
};
}; NTSTATUS ExitStatus; USHORT NextPageColor;
union
{
struct
{
UCHAR SubSystemMinorVersion;
UCHAR SubSystemMajorVersion;
};
USHORT SubSystemVersion;
};
UCHAR PriorityClass; MM_AVL_TABLE VadRoot; ULONG Cookie; } EPROCESS, *PEPROCESS;
不好意思一下子复制了一大堆的代码出来，也说明EPOCESS在windows内核中的地位，所以很复杂，我们现在来一条一条的学习这个EPROCESS的数据结构成员，和其他内核中数据结构的联系以及相关的应用场景和外延。
1. KPROCESS Pcb
Pcb域即KPROCESS结构体，它们是同一种东西，只是两种叫法而已，我们现在只要知道几点，KRPOCESS的详细细节我们放到后面讲：
1) KPROCESS位于比EPROCESS更底层的内核层中 2) KPROCESS被内核用来进行线程调度使用
这里还要注意的是，因为Pcb域是EPROCESS结构的第一个成员，所以在系统内部，一个进程的KPROCESS对象的地址和EPROCESS对象的地址是相同的。这种情况和"TIB就是TEB结构的第一个成员，而EXCEPTION_REGISTRATION_RECORD又是TIB的第一个成员，又因为FS:[0x18] 总是指向当前线程的 TEB 。 所以导致用 FS:[0x18] 就直接可以寻址到SEH的链表了"。windows中的这种结构体的嵌套思想，应该予以领会。
2. EX_PUSH_LOCK ProcessLock
ProcessLock域是一个推锁(push lock)对象，用于保护EPROCESS中的数据成员(回想IRP中也同样有一种类似的锁机制)。用来对可能产生的并行事件强制串行化。
typedef struct _EX_PUSH_LOCK
{
union
{
ULONG Locked: 1;
ULONG Waiting: 1;
ULONG Waking: 1;
ULONG MultipleShared: 1;
ULONG Shared: 28;
ULONG Value;
PVOID Ptr;
};
} EX_PUSH_LOCK, *PEX_PUSH_LOCK;
3. LARGE_INTEGER CreateTime / LARGE_INTEGER ExitTime
这两个域分别代表了进程的创建时间和退出时间，windows在内核中会记录大量和进程周边的相关信息，例如创建事件，运行时间，负载，使用内存数等，一方面对于上层应用来说，我们可以很方便地调用一些API去获取到实时的系统运行状态，另一方面操作系统本身也可以依据这些信息对进程进行合理的调度。
typedef union _LARGE_INTEGER
{
struct
{
DWORD LowPart;
LONG HighPart;
};
struct
{
DWORD LowPart;
LONG HighPart;
} u;
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
+0x070 CreateTime : _LARGE_INTEGER 0x1ceee34`5d8ce8a2
4. EX_RUNDOWN_REF RundownProtect
RundownProtect域是进程的停止保护锁，当一个进程到最后被销毁时，它要等到所有其他进程和线程已经释放了此锁，才可以继续进行，否则就会产生孤儿线程。加锁机制也是windows中进程间或线程间同步的一个很经典的机制，进程只要设置阻塞等待在一个锁对象上，等待拥有那个锁的其他进程或线程释放锁对象，操作系统会发出signal信号，重新激活之前阻塞等待在那个锁上的进程，这样就完成了进程间，线程间的同步。
struct EX_RUNDOWN_REF typedef struct _EX_RUNDOWN_REF
{
union
{
ULONG Count;
PVOID Ptr;
};
} EX_RUNDOWN_REF, *PEX_RUNDOWN_REF;
5. HANDLE UniqueProcessId
UniqueProcessId域是进程的唯一编号，在进程创建时就设定好了，我们在"任务管理器"中看到的PID就是从这个域中获取的值。
+0x084 UniqueProcessId : 0x000000a0
6. LIST_ENTRY ActiveProcessLinks
ActiveProcessLinks域是一个双链表节点(注意是双链表中的一个节点)，在windows系统中，所有的活动进程都连接在一起，构成了一个链表。
表头是全局变量PsActiveProcessHead。内部变量PsActiveProcessHead是一个LIST_ENTRY结构，它是一个双链表的表头，在windows的进程双链表中指定了系统进
程列表的第一个成员(回想数据结构中双链表需要一个和链表项相同的表头结构来当作入口点)。
这里注意一下:
PID=4的System的ActiveProcessLinks其实也就是PsActiveProcessHead。即系
统进程System的LIST_ENTRY结构充当这个进程双链表的表头。
当一个进程被创建时，其ActiveProcessLinks域将被作为"节点"加入到内核中的进程双链表中，当进程被删除时，则从链表中移除。如果我们需要枚举所有的进程，直接操纵此链表即可。思路其实很清晰的，利用PsGetCurrentProcess()获得当前进程的EPROCESS结构，在根据指定偏移找到Flink和Blink，后面的事情就是数据结构中的遍历双链表了。
typedef struct _LIST_ENTRY
{
struct _LIST_ENTRY *Flink;
struct _LIST_ENTRY *Blink;
} LIST_ENTRY, *PLIST_ENTRY;
+0x088 ActiveProcessLinks : _LIST_ENTRY [ 0x8055b158 - 0x823e5518 ]
我们暂且不表，将进程枚举的知识放到后面的学习笔记中，我们集中精力学习EROCESS的数据结构。
7. 进程内存配额使用
ULONG QuotaUsage[3]
ULONG QuotaPeak[3]
QuotaUsage和QuotaPeak域是指一个进程的内存使用量和尖峰使用量(作用我们之前说过，即为了实时地报告出当前进程运行的性能数据)。这两个域是数组，其中的元素:
[0]: 非换页内存池
[1]: 换页内存池
[2]: 交换文件中的内存使用情况。
QuotaUsage[3]和QuotaPeak[3]这两个数组是在PspChargeQuota函数中计算的。在WRK中 \base\ntos\ps\psquota.c 有具体的函数实现。
NTSTATUS FORCEINLINE PspChargeQuota (
IN PEPROCESS_QUOTA_BLOCK QuotaBlock,
IN PEPROCESS Process,
IN PS_QUOTA_TYPE QuotaType,
IN SIZE_T Amount)
{
..
}
+0x090 QuotaUsage : [3] 0xa50
+0x09c QuotaPeak : [3] 0xc48
8. 进程虚拟内存使用
ULONG CommitCharge
ULONG PeakVirtualSize
ULONG VirtualSize
CommitCharge域中存储了一个进程的虚拟内存已提交的"页面数量"。PeakVirtualSize域是指虚拟内存大小的尖峰值。VirtualSize域是指一个进程的虚拟内存大小。
+0x0a8 CommitCharge : 0x184
+0x0ac PeakVirtualSize : 0x244d000
+0x0b0 VirtualSize : 0x1f87000
(我们在任务管理器中看到的这些性能参数就是从这些域中计算总和得到的)
9. LIST_ENTRY SessionProcessLinks
SessionProcessLinks域是一个双链表节点，当进程加入到一个系统会话中时，这个进程的SessionProcessLinks域将作为一个节点(LIST_ENTRY在内核中很常见)加入到该会话的进程链表中。
+0x0b4 SessionProcessLinks : _LIST_ENTRY [ 0xf8b6a014 - 0x823e5544 ]
10. 端口
PVOID DebugPort;
PVOID ExceptionPort;
DebugPort和ExceptionPort域是两个句柄(指针)，分别指向当前进程对应的调试端口和异常端口。当该进程的线程发生用户模式的异常时(软件中断)时，内核的异常处理例程在处理异常过程中，将向
该进程的"异常端口"或"调试端口"发送消息，从而使这些端口的接收方(调试器或windows子系统)能够处理该异常。这涉及到windows的异常分发过程。请参考《windows内核原理与实现》
5.2.7节: 异常分发。这里总结一下windows异常发生时的处理顺序。
发生异常时系统的处理顺序: 1.系统首先判断异常是否应发送给目标程序的异常处理例程,如果决定应该发送,并且目标程序正在被调试,则系统
挂起程序并向调试器发送EXCEPTION_DEBUG_EVENT消息.注意,这也是用来探测调试器的存在的技术之一 2.如果你的程序没有被调试或者调试器未能处理异常,系统就会继续查找你是否安装了线程相关的异常处理例程,如果
你安装了线程相关的异常处理例程,系统就把异常发送给你的程序seh处理例程,交由其处理. 3.每个线程相关的异常处理例程可以处理或者不处理这个异常,如果他不处理并且安装了多个线程相关的异常处理例程,
可交由链起来的其他例程处理. 4.如果这些例程均选择不处理异常,如果程序处于被调试状态,操作系统仍会再次挂起程序通知debugger. 5.如果程序未处于被调试状态或者debugger没有能够处理,并且你调用SetUnhandledExceptionFilter安装了最后异
常处理例程的话,系统转向对它的调用. 6.如果你没有安装最后异常处理例程或者他没有处理这个异常,系统会调用默认的系统处理程序,通常显示一个对话框,
你可以选择关闭或者最后将其附加到调试器上的调试按钮.如果没有调试器能被附加于其上或者调试器也处理不了,系统
就调用ExitProcess终结程序. 7.不过在终结之前,系统仍然对发生异常的线程异常处理句柄来一次展开,这是线程异常处理例程最后清理的机会.
+0x0bc DebugPort : (null)
+0x0c0 ExceptionPort : 0xe1982848
11. PHANDLE_TABLE ObjectTable
ObjectTable域是当前进程的句柄表。句柄是一个抽象概念，代表了进程已打开的一个对象。句柄表包含了所有已经被该进程打开的那些"对象"的引用(这里对象的概念很大了，所有的内核对象都算对象)。
windows进程的句柄表是一个层次结构。
windows执行体实现了一套对象机制来管理各种资源或实体。每种对象都有一个"类型对象"，类型对象定义了该类对象的一些特性和方法。对象管理器中的对象是执行体对象(在内核空间中)，
它们位于系统空间中，在进程空间不能通过地址来引用它们。windows使用句柄(handle)来管理进程中的对象引用(类似我们进行文件操作时返回的文件对象句柄)。 当一个进程利用名称来创建或打开一个对象时，将获得一个句柄(这个句柄本质上一个指针，保存在当前进程的EPROCESS的句柄表中)。
该句柄指向所创建或打开的对象(同时，被创建或打开的内核对象的引用计数+1)。以后，该进程无须再次使用名称来引用该对象，使用此句柄访问即可。windows这样做可以显著提高引用对象的效率。 在windows中，句柄是进程范围内的对象引用，换句话说，句柄仅在一个进程范围内有效。一个进程中的句柄传递给另一个进程后(例如父进程创建了子进程时会自动复制父进程拥有的句柄表)，
但是句柄值已经不一样了，不同进程空间中可能引用的是同一个对象，但是它们的句柄值不同(联想进程的空间独立性)。
实际上，windows支持的句柄是一个"索引"，指向该句柄所在进程的句柄表(handle table)中的一个表项。 base\ntos\inc\ex.h
typedef struct _HANDLE_TABLE
{
//指向句柄表的结构
ULONG TableCode;
//句柄表的内存资源记录在此进程中
PEPROCESS QuotaProcess;
//创建进程的ID，用于回调函数
PVOID UniqueProcessId;
//句柄表锁，仅在句柄表扩展时使用
EX_PUSH_LOCK HandleLock;
//所有的句柄表形成一个链表(这个成员域用来指向下一个句柄表节点的)，链表头为全局变量HandleTableListHead
LIST_ENTRY HandleTableList;
//若在访问句柄时发生竞争，则在此推锁上阻塞等待
EX_PUSH_LOCK HandleContentionEvent;
//调试信息，仅当调试句柄时才有意义
PHANDLE_TRACE_DEBUG_INFO DebugInfo;
//审计信息所占用的页面数量
LONG ExtraInfoPages;
//空闲链表表头的句柄索引
LONG FirstFreeHandle;
//最近被释放的句柄索引，用于FIFO类型空闲链表
PHANDLE_TABLE_ENTRY LastFreeHandleEntry;
//下一次句柄表扩展的起始句柄索引
ULONG NextHandleNeedingPool;
//正在使用的句柄表项的数量
LONG HandleCount;
union
{
//标志域
ULONG Flags;
//是否使用FIFO风格的重用，即先释放还是先重用
BOOLEAN StrictFIFO : 1;
}
} HANDLE_TABLE, *PHANDLE_TABLE;
HANDLE_TABLE结构中的第一个域成员TableCode域是一个指针，指向句柄表的最高层表项页面(前面说过句柄表是一个多层的结构)，它的低2bit的值代表了当前句柄表的层数。
1) 如果TableCode的最低2位为0(..00)。说明句柄表只有一层(从0开始计数)，这种情况下该进程最多只能容纳512个句柄(宏定义LOWLEVEL_THRESHOLD)。 2) 如果TableCode的最低2位为1(..01)。说明句柄表有两层，这种情况下该进程可容纳的句柄数是512*1024(宏定义MIDLEVEL_THRSHOLD)。 3) 如果TableCode的最低2位为2(..10)。说明句柄表有三层，这种情况下该进程可容纳的句柄数是512*1024*1024(宏定义HIGHLEVEL_THRSHOLD)。
但windows执行体限定每个进程的句柄数不得超过2^24=16777216(宏定义MAX_HANDLES)。
看到这里，我们要理清一下思路:
1. 在EPROCESS中有一个 PHANDLE_TABLE ObjectTable 成员域指向的是一个HENDLE_TABLE数据结构，这个结构并不是真正保存句柄表真实数据的地址，我们可以把这个
结构理解为一个句柄表的meta元数据结构。在HANDLE_TABLE数据结构的第一个域成员TableCode才是指向"这个句柄表"对应的真实句柄数组数据。
2. TableCode指向的这个句柄数据的数据结构为: HANDLE_TABLE_ENTRY。即图中的每个小格子为一个HANDLE_TABLE_ENTRY结构
typedef struct _HANDLE_TABLE_ENTRY
{
union
{
PVOID Object;
ULONG ObAttributes;
PHANDLE_TABLE_ENTRY_INFO InfoTable;
ULONG_PTR Value;
};
union
{
union
{
ACCESS_MASK GrantedAccess;
struct
{
USHORT GrantedAccessIndex;
USHORT CreatorBackTraceIndex;
};
};
LONG NextFreeTableEntry;
};
} HANDLE_TABLE_ENTRY, *PHANDLE_TABLE_ENTRY;
3. 每个HANDLE_TABLE_ENTRY结构体，即每个句柄的大小的为4byte，而windows执行体在分配句柄表内存时按页面(32位系统下4KB大小)来申请内存。因此，才有了我们
之前看到了每层的句柄数1024。
4. 那我们在图中看到的不同的句柄表(注意是表，一个表中有很多句柄项)之间的的链接是怎么回事呢？这是通过TABLE_HANDLE中的成员域HandleTableList来进行链接的，这个一个LIST_ENTRY结构，也即和进程双链表一样，这是一个句柄表双链表。
总结一下:EPROCESS中的PHANDLE_TABLE ObjectTable 成员域指向的是一个HENDLE_TABLE数据结构，这个域的第一个成员的低2位很重要，它决定了这个进程中总
共有多少个这样的PHANDLE_TABLE ObjectTable结构，例如(..10)，那就有3个PHANDLE_TABLE ObjectTable结构，它们依靠PHANDLE_TABLE ObjectTable中
的HandleTableList来形成一个双链表，依次形成层次关系，而PHANDLE_TABLE ObjectTable中的TableCode指向的才是指向真实的句柄数组，每个句柄以
HANDLE_TABLE_ENTRY节诶狗来标识，大小为4byte。所有的HANDLE_TABLE_ENTRY形成一个句柄数组组成一层这样的"句柄数据组"，总共有3排
(因为TableCode的低2位为..10)。 这样，windows中一个进程的句柄表就被表现出来了。
+0x0c4 ObjectTable : 0xe292f898 _HANDLE_TABLE
+0x000 TableCode : 0xe10fd000
+0x004 QuotaProcess : 0x824a7020 _EPROCESS
+0x008 UniqueProcessId : 0x000000a0
+0x00c HandleTableLock : [4] _EX_PUSH_LOCK
+0x01c HandleTableList : _LIST_ENTRY [ 0xe1090f64 - 0xe283dc4c ]
+0x024 HandleContentionEvent : _EX_PUSH_LOCK
+0x028 DebugInfo : (null)
+0x02c ExtraInfoPages : 0
+0x030 FirstFree : 0xac
+0x034 LastFree : 0
+0x038 NextHandleNeedingPool : 0x800
+0x03c HandleCount : 48
+0x040 Flags : 0
+0x040 StrictFIFO : 0y0
更多的关于句柄表的数据结构和句柄表随着进程创建和运行过程中的扩展和收缩请参考《windows 内核原理与实现》3.4.1: windows进程的句柄表。我们这里就不继续展开了。
12. EX_FAST_REF Token
Token域是一个快速引用，指向该进程的访问令牌，用于该进程的安全访问检查。这是进程访问令牌相关的知识，之前做西电线上赛的时候就遇到一题是要提升进程访问令牌权限的要求。
BOOL WINAPI OpenProcessToken(
_In_ HANDLE ProcessHandle,
_In_ DWORD DesiredAccess,
_Out_ PHANDLE TokenHandle
);
+0x0c8 Token : _EX_FAST_REF
+0x000 Object : 0xe10ea4bb
+0x000 RefCnt : 0y011
+0x000 Value : 0xe10ea4bb
http://msdn.microsoft.com/library/aa379295(VS.85).aspx
相关的内容请参考《Windows核心编程(第四版)》中文版》4.5章，有关UAC的部分。这里提供一个提升进程Access Token权限的链接，小聂博客看到的，当时用的就是这个思路
http://xiaonieblog.com/?post=81
13. PFN_NUMBER WorkingSetPage
WorkingSetPage域是指包含进程工作集的页面
工作集是指一个进程当前正在使用的物理页面的集合。在windows中，有3种工作工作集。 1) 进程工作集 2) 系统工作集
系统工作集是指System进程(由全局变量PsInitialSystemProcess表示)的工作集，其中包括系统模块的映像区(比如ntoskrnl.exe和设备驱动程序)、换页内存池和系统缓存(cache) 3) 会话工作集
会话工作集是指一个会话所属的代码和数据区，包括windows子系统用到的与会话有关的数据结构、会话换页内存池、会话的映射视图，以及会话空间中的设备驱动程序。
每个进程都有一个专门的页面用来存放它的"工作集链表"，这是在创建进程地址空间时已经映射好的一个页面，其地址位于全局变量MmWorkingSetList中，所以，在任何一个进程中，通过变量MmWokingSetList就可以访问到它的"工作集链表"。windows通过MmWokingSetList来跟踪一个进程所使用的物理页面。 这个MmWokingSetList的类型为"MMWSL":
typedef struct _MMWSL
{
WSLE_NUMBER FirstFree;
WSLE_NUMBER FirstDynamic;
WSLE_NUMBER LastEntry;
WSLE_NUMBER NextSlot; // The next slot to trim
PMMWSLE Wsle;
WSLE_NUMBER LastInitializedWsle;
WSLE_NUMBER NonDirectCount;
PMMWSLE_HASH HashTable;
ULONG HashTableSize;
ULONG NumberOfCommittedPageTables;
PVOID HashTableStart;
PVOID HighestPermittedHashAddress;
ULONG NumberOfImageWaiters;
ULONG VadBitMapHint;
USHORT UsedPageTableEntries[MM_USER_PAGE_TABLE_PAGES];
ULONG CommittedPageTables[MM_USER_PAGE_TABLE_PAGES/(sizeof(ULONG)*8)];
} MMWSL, *PMMWSL;
更多的内容请学习《windows 内核原理与实现》 4.6章: 工作集管理的相关知识。因为windows内核的知识很多，要在一次的学习中把所有相关的知识点都学到，那就有点像无线递归的感觉了，一层又一层。我们把工作集的内容放到以后研究，但是有一点很重要，我们要记住的一点是: 工作集定了这个进程所拥有的所有内存页，那进程的内存分配，使用，调度算法一定和工作集有关，如果以后我们遇到有关内存调度算法的题目，我们应该要能反应到一些相关的基础知识点，然后到这些经典的书上去翻阅相关知识，这样慢慢积累下来感觉会比较好。
14. KGUARDED_MUTEX AddressCreationLock
AddressCreationLock域是一个守护互斥体锁(guard mutex)，用于保护对地址空间的操作。当内核代码需要对虚拟地址空间进行操作时(回想IRP中讲到3种缓冲区时说过，UserBuffer方式，内核代码直接访问用户空间的内存数据)，它必须在AddressCreationLock上执行"获取锁"操作，完成以后再"释放锁"操作。
base\ntos\mm\mi.h中的宏可以简化代码:
#define LOCK_ADDRESS_SPACE(PROCESS) KeAcquireGuardedMutex (&((PROCESS)->AddressCreationLock));
#define UNLOCK_ADDRESS_SPACE(PROCESS) KeReleaseGuardedMutex (&((PROCESS)->AddressCreationLock));
15. KSPIN_LOCK HyperSpaceLock
HyperSpaceLock是一个自旋锁，用于保护进程的超空间。
typedef struct
{
volatile unsigned int lock;
}
spinlock_t;
16. struct _ETHREAD *ForkInProgress
ForkInProgress指向正在复制地址空间的那个线程，仅当在地址空间复制过程中，此域才会被赋值，在其他情况下为NULL。
base\ntos\mm\forksup.c:
NTSTATUS
MiCloneProcessAddressSpace (
IN PEPROCESS ProcessToClone,
IN PEPROCESS ProcessToInitialize
)
17. ULONG_PTR HardwareTrigger
HardwareTrigger用于记录硬件错误性能分析次数
18.进程的复制
PMM_AVL_TABLE PhysicalVadRoot: PhysicalVadRoot域指向进程的物理VAD的根。它并不总是存在，只有当确实需要映射物理内存时才会被创建。
PVOID CloneRoot: CloneRoot指向一个平衡树的根，当进程地址空间复制时，此树被创建，创建出来后，一直到进程退出的时候才被销毁。CloneRoot域完全是为了支持fork语义而引入。
PFN_NUMBER NumberOfPrivatePages: 指进程私有页面的数量
PFN_NUMBER NumberOfLockedPages: 指进程被锁住的页面的数量
+0x11c VadRoot : 0x82401480
+0x120 VadHint : 0x824392c8
+0x124 CloneRoot : (null)
+0x128 NumberOfPrivatePages : 0xd9
+0x12c NumberOfLockedPages : 0
19. PVOID Win32Process / struct _EJOB *Job
Win32Process域是一个指针，指向由windows子系统管理的进程区域，如果此值不为NULL，说明这是一个windows子系统进程(GUI进程)。对于job域，只有当一个进程属于一个job(作业)的时候，它才会指向一个_EJOB对象。
+0x130 Win32Process : 0xe109b210
+0x134 Job : (null)
20. 进程对应的内存区
PVOID SectionObject: SectionObject域也是一个指针，代表进程的内存去对象(进程的可执行映像文件的内存区对象)
PVOID SectionBaseAddress: SectionBaseAddress域为该内存区对象的基地址
+0x138 SectionObject : 0xe19d2c18
+0x13c SectionBaseAddress : 0x01000000
21. PEPROCESS_QUOTA_BLOCK QuotaBlock
QuotaBlock域指向进程的配额块，进程的配额块类型为: EPROCESS_QUOTA_BLOCK
typedef struct _EPROCESS_QUOTA_BLOCK
{
struct _EPROCESS_QUOTA_ENTRY QuotaEntry[3];
struct _LIST_ENTRY QuotaList;
ULONG32 ReferenceCount;
ULONG32 ProcessCount;
}EPROCESS_QUOTA_BLOCK, *PEPROCESS_QUOTA_BLOCK;
注意到结构中有我们熟悉的LIST_ENTRY双链表结构，心里基本猜到了。windows系统中的"配额块"相互串起来构成了一个双链表，每个配额块都可以被多个进程共享，所以有一个引用计数指用来说明当前有多少个进程正在使用这一配额块。配额块中主要定义了非换页内存池、换页内存池、交换文件中的内存配额限制。
这里要注意的是，所有配额块构成的双链表的表头为PspQuotaBlockList。系统的默认配额块为PspDefaultQuotaBlock。
+0x140 QuotaBlock : 0x82cf5db8 _EPROCESS_QUOTA_BLOCK
+0x000 QuotaEntry : [3] _EPROCESS_QUOTA_ENTRY
+0x030 QuotaList : _LIST_ENTRY [ 0x82c4dea0 - 0x82ca7700 ]
+0x038 ReferenceCount : 0x751
+0x03c ProcessCount : 7
22. PPAGEFAULT_HISTORY WorkingSetWatch
WorkingSetWatch域用于监视一个进程的页面错误，一旦启用了页面错误监视功能(由全局变量PsWatchEnabled开关来控制)，则每次发生页面错误都会将该页面错误记录到WorkingSetWatch域的WatchInfo成员数组中，知道数组满为止。
相关的处理函数为： PsWatchWorkingSet()。
typedef struct _PAGEFAULT_HISTORY
{
ULONG CurrentIndex;
ULONG MapIndex;
KSPIN_LOCK SpinLock;
PVOID Reserved;
PROCESS_WS_WATCH_INFORMATION WatchInfo[1];
} PAGEFAULT_HISTORY, *PPAGEFAULT_HISTORY;
23. HANDLE Win32WindowStation
Win32WindowStation域是一个进程所属的窗口站的句柄。由于句柄的值是由每个进程的句柄表来决定的，所以，两个进程即使同属于一个窗口站，它们的Win32WindowStation也可能不同，但指向的窗口站对象是相同的。窗口站是由windows子系统来管理和控制的。
24. HANDLE InheritedFromUniqueProcessId
InheritedFromUniqueProcessId域说明了一个进程是从哪里继承来的，即父进程的标识符。
25. PVOID LdtInformation
LdtInformation用来维护一个进程的LDT(局部描述符表)信息。
http://blog.csdn.net/billpig/article/details/5833980
http://hi.baidu.com/zeyu203/item/74192edfb16abd392b35c7c0
这两篇文章对GDT和LDT解释的很好了，这里总结一下我对GDT和LDT的理解。
1) 全局描述符表GDT(Global Descriptor Table)
除了使用虚拟地址来实现有效和灵活的内存管理以外，在计算机发展史上，另一种重要的内存管理方式是将物理内存划分成若干个段(segment)，处理器在访问一个内存单元时，通过"段基址+偏移"的方式算出实际的物理地址。每个段都可以有自己的访问属性，包括读写属性、特权级别等。例如，在Intel x86处理器中，有专门的段寄存器，允许每条指令在访问内存时指定在哪个段上进行。段的概念在Intel 8086/8088实模式中已经使用了，但当时段的用途是扩展地址范围，将系统的内存从64KB扩展到1MB(CS:IP那种模式)。
在Intel x86中，逻辑地址的段部分(即原来的CS:IP中的CS部分)称为"段选择符(segment selector)"，也有称为段选择子的。
这个"段选择符"指定了段的索引以及要访问的特权级别。段寄存器CS,SS,DS,ES,FS,GS专门用于指定一个地址的段选择符。虽然只有这六个寄存器，但是软件可以灵活地使用它们来完成各种功能。其中与有三个段寄存器有特殊的用途:
1) CS: 代码段寄存器，指向一个包含指令的段，即代码段
2) SS: 栈段寄存器，指向一个包含当前调用栈的段，即栈段
3) DS: 数据段寄存器，指向一个包含全局和静态数据的段，即数据段
在整个系统中，全局描述符表GDT只有一张(一个处理器对应一个GDT)，GDT可以被放在内存的任何位置，但CPU必须知道GDT的入口，也就是基地址放在哪里，Intel的设计者提供了一个寄存器GDTR用来存放GDT的入口地址，程序员将GDT设定在内存中某个位置之后，可以通过LGDT指令将GDT的入口地址装入此积存器，从此以后，CPU就根据此寄存器中的内容作为GDT的入口来访问GDT了。GDTR中存放的是GDT在内存中的基地址和其表长界限(也就是说，我们通过GDTR中的值可以找到这张全局描述表的真实数据结构，GDTR的作用也就仅仅这样了，找到GDT就没了)。
那借来来就有一个问题了，我们通过GDTR中保存的基地址找到了一个所谓的全局描述表GDT，并通过"段选择子"索引到了GDT中的某一项(具体怎么索引我们后面会举例子)，我们这里暂时称为某一项，因为我们目前还不知道GDT中的一项项是什么数据，那GDT中都保存了什么数据呢？这就要涉及到局部描述符表LDT了。
2) 局部描述符表LDT(Local Descriptor Table)
局部描述符表可以有若干张，每个任务可以有一张。我们可以这样理解GDT和LDT：GDT为一级描述符表，LDT为二级描述符表。
我们知道，一个应用程序中有代码段/数据段/TSS段/LDT段，而每一个段都对一个一个LDT，而这些LDT可以通过GDT寻址到。我们回想一下，GDTR是用来寻址GDT的，因为GDT只有一个，所以可以用GDTR+段选择子的方法来寻址LDT，但是LDT不一样了，LDT有很多个，所以不存在基址这一说，所以LDTR中保存的是当前的LDT，这个指是可以动态改变的。
LDT即局部描述符(或者叫段描述符)，他记录了这个段的一些属性: 段的起始地址、有效范围、和一些属性。
每一个LDT中都这样的数据结构，它很好地描述了这个段对应的信息。我们重点解释其中几个字段:
G: 当G位为0时，此长度单位为byte。当G为1时，此长度单位为4096byte。所以，段长度可达2^20 * 4096 = 4GB，即整个32位线性地址空间。 DPL(描述符特权级 Descriptor Privilege Level)是允许访问此段的最低特权级(结合下面学习的"段选择子"中有一个字段(RPL)是标识这个段选择子也即这个内存访问请求的
特权级)，这样是不是就把对应关系建立起来了，比如DPL为0的段只有当RPL=0时才能访问，而DPL为3的段，可由任何RPL的代码访问。这样就解释了为什么ring3的内存空间
ring0的内核代码可以任意访问，而ring0的内存空间ring3不能访问了。 TYPE(类型域): 指定了段的类型，包括代码段、数据段、TSS段、LDT段。
3) 段选择子(Selector)
我们之前还有一个疑问没解决，"我们通过GDTR中保存的基地址找到了一个所谓的全局描述表GDT，并通过"段选择子"索引到了GDT中的某一项"。那段选择字是怎么来进行索引的呢？
段选择子是一个16位的寄存器(同实模式下的段寄存器相同)
段选择子包括三部分：描述符索引(index)、TI、请求特权级(RPL)。他的index(描述符索引)部分表示所需要的段的描述符(LDT)在描述符表的位置(编号)，由这个位置再根据在GDTR中存储的描述符表基址(GDTR的32位基地址用来寻址GDT的基地址)就可以找到相应的描述符(LDT)。然后用描述符表中的段基址加上逻辑地址(假如给出这样的逻辑地址 SEL:OFFSET)的OFFSET就可以转换成线性地址，段选择子中的TI值只有一位0或1，0代表选择子是在GDT选择，1代表选择子是在LDT选择。请求特权级(RPL)则代表选择子的特权级，共有4个特权级(0级、1级、2级、3级)(但是只有2中状态被实际使用，0表示最高特权级，3表示最低特权级，CPU只能访问同一特权级或级别较低特权级的段)。
例如给出逻辑地址：21h:12345678h转换为线性地址
a. 选择子SEL=21h=0000000000100 0 01b 他代表的意思是：选择子的index=4即100b选择GDT中的第4个描述符；TI=0代表选择子是在GDT选择；左后的01b代表特权级RPL=1
b. OFFSET=12345678h若此时GDT第四个描述符中描述的段基址（Base）为11111111h，则线性地址=11111111h+12345678h=23456789h
说了这么多，来总一下LDT和GDT:
1. 首先，要把一些概念和名词弄清楚，有很多书和网上的文章中给了很多名词，我们要能理解它们。段选择符和段选择子是一个概念，它们就相当于8080下实模式中的CS。 2. 我们给出的逻辑地址由段选择子和偏移量组成: SEL + OFFSET. 3. GDTR中保存着GDT的基地址，通过GDTR我们可以寻址到GDT(你可以理解为寻址一个数组的基地址) 4. GDT这个"数组"中保存着很多LDT，它们每个都代表着一个段，我们需要通过SEL(段选择子)来索引具体的LDT 5. LDTR中保存的是当前的LDT地址，也即一个段选择子。 6. 每个LDT中保存了这个段的一些关键的信息，包括段基址，段的特权，段的大小等等。
更多细节请参考《windows 内核原理与实现》4.1.2 段式内存管理
说了这么多，回到我们的主线上来，LdtInformation域保存的就是一个进程的LDT。
26. PVOID VadFreeHint
VadFreeHint域指向一个提示VAD(虚拟地址描述符)节点，用于加速在VAD树中执行查找操作。
27. PVOID VdmObjects
VdmObjects域指向当前进程的VDM数据区，其类型为VMD_PROCESS_OBJECTS，进程可通过NtVdmControl系统服务来初始化VDM。
28. PVOID DeviceMap
DeviceMap域指向进程使用的设备表，通常情况下同一个会话中的进程共享同样的设备表。有关设备表的用法请参考《windows 内核原理与实现》 7章。请原谅我又采取这么马虎的方式忽略过去了，因为我不想让这篇文章的主线变得过于冗长，我会在之后的学习笔记中补充上之前说过的类似的参考之类的话，分专题进行学习笔记。
29. PVOID Spare0[3]
Spare0域是一个备用域。用法未知，WRK中也没有使用。
30. 页表项
union
{
HARDWARE_PTE PageDirectoryPte;
ULONGLONG Filler;
};
PageDirectoryPte域是*页目录页面的页表项。这涉及到windows中的页式内存管理的知识，我们拓展出去。
让进程使用虚拟地址，而虚拟地址和物理地址之间通过一个映射表来完成转译。页式内存和我们之前学习的段式内存管理方式都是基于这样一种思路的具体实现。 在页式内存管理中，虚拟地址空间是按页(page)来管理的(回想段式内存管理中，虚拟地址空间是靠"段+偏移"来管理的)，对应于物理内存也按页来管理(一般情况下虚拟内存和物理内存使用相同的页面大小
4KB)。物理内存中的页面有时称为"页帧(page frmae)"，其大小与虚拟空间中的页面相同。因此，映射的基本度量单位为"页"，在虚拟地址空间中连续的页面对应于在物理内存中的页面可以不连续。
通过维护这个虚拟地址空间与物理内存页面之前的映射关系，物理页面可以被"动态"地分配给特定的虚拟页面，从而当只有真正有需要的时候才把物理页面分配给虚拟页面(其他时候，进程看到的都是一个
伪的平坦4GB内存空间)。注意，在一个系统中，物理地址空间只有一个，但虚拟地址空间可以有多个。每个虚拟地址空间都必须有一个映射关系。
有了页面划分的机制以后，每个虚拟地址(逻辑地址)32位信息中，其中一部分位信息指定了一个"页索引"，其余的位信息则指定了业内的偏移量。也就是说，虚拟地址分成了两部分: 页索引+页内偏移。
既然有页索引，就自然会有一个页表。在windows中，我们称之为"页面映射表"。Intel x86采用了"分级页表"的方式来管理这一映射关系。32位的虚拟地址中的"页索引部分"又被分成"页目录索引(10位)"
和"页表索引(10位)"这两部分。
基于这样的虚拟地址构成，每个虚拟地址(进程地址空间)对应有一个页目录(最顶层)，其中包含2^10=1024个目录项(PDE Page Directory Entry)。而页目录中的每一个目录项又指向一张包含1024项的页
表，而每个页表中才保存的是页面。
所以，Intel x86处理器在解析一个虚拟地址时，首先根据最高10位在"页目录"中定位到一个"页目录项(PDE)"，这个"页目录项"指向一个"页表"，然后根据接下来的10位，在页表中定位到一个"页表项(
PTE Page Table Entry)"。这个"页表项"就是一个"页面"，此页表项指定了目标页面的物理地址。最后在此物理地址的基础上加上页面偏移，即得到最终的物理地址。
(这段话可能有点绕，一定要结合图片细心的理解，它其实就是一个多层的关系)
《windows 内核原理与实现》 4.1.1 节中有关于页式内存管理的详细细节。 回到我们的主线上来:
PageDirectoryPte域是*页目录页面的页表项
即PageDirectoryPte域是页目录中的第一项对应的那个页表。
31. PVOID Session
Session指向进程所在的系统会话，实际上它是一个指向MM_SESSION_SPACE的指针。\base\ntos\mm\mi.h 中相关的结构体定义。
每个进程在初始化创建地址空间时会加入到当前的系统会话中。
+0x170 Session : 0xf8b6a000
32. UCHAR ImageFileName[ 16 ]
ImageFileName域包含了进程的映像文件名，仅包含最后一个路径分隔符之后的字符串，不超过16字节。
+0x174 ImageFileName : [16] "notepad.exe"
33. LIST_ENTRY JobLinks
JobLinks域是一个双链表节点，通过此节点，一个job中的所有进程构成了一个链表。在windows中，所有的job构成了一个双链表，其链表头为全局变量PspJobList。每个job中的进程又构成了一个双链表。
(可以发现，在windows内核中，进程，job，线程都是可以通过双链表遍历的方法来进行枚举的，但是遇到"断链法"就不行了，我们之后会专题研究windows内核中进程枚举的知识)
+0x184 JobLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
+0x000 Flink : (null)
+0x004 Blink : (null)
34. PVOID LockedPagesList
LockedPagesList域是一个指向LOCK_HEADER结构的指针，该结构包含了一个链表头，windows通过此链表来记录哪些页面已被锁住(这里所谓的锁住和Mdll中的映射机制有关，本质上就是把用户空间下的内存地址锁定到内核空间中以便访问)。
base\ntos\mm\iosup.c中有一组函数用于管理此链表: MiAddMdlTracker、MiFreeMdlTracker、MiUpdateMdlTracker/
35. LIST_ENTRY ThreadListHead
ThreadListHead域是一个双链表的"头结点"，该链表中包含了一个进程中的所有"线程"。即EPROCESS中的ThreadListHead域的链表中包含了各个子线程的ETHREAD结构中的ThreadListHead节点。
这里要注意看清除哦，EPROCESS中的ThreadListHead域包含的不是EHREEAD的基址，而是ETHREAD中的ThreadListHead节点的指针，即它们是通过这个双链表来串起
来的，这个细节在我们枚举进程或枚举进程的时候会经常遇到，就是要处理一个偏移量的问题。
36. PVOID SecurityPort
SecurityPort域是一个安全端口，指向该进程域lsass.exe进程之间的跨进程通信端口。
37. PVOID PaeTop
PaeTop域用于支持PAE内存访问机制。
+0x19c PaeTop : 0xf8cb21a0
38. ULONG ActiveThreads
ActiveThreads域记录了当前进程有多少活动线程。当该值减为0时，所有的线程将退出，于是进程也退出。
+0x1a0 ActiveThreads : 1
(可以看到，当前记事本进程就一个线程: 主线程)
39. ACCESS_MASK GrantedAccess
GrantedAccess域包含了进程的访问权限，访问权限是一个"位组合"。 public\sdk\inc\ntpsapi.h 中的宏 PROCESS_XXX
...
#define PROCESS_TERMINATE (0x0001) // winnt
#define PROCESS_CREATE_THREAD (0x0002) // winnt
#define PROCESS_SET_SESSIONID (0x0004) // winnt
#define PROCESS_VM_OPERATION (0x0008) // winnt
#define PROCESS_VM_READ (0x0010) // winnt
#define PROCESS_VM_WRITE (0x0020) // winnt
// begin_ntddk begin_wdm begin_ntifs
#define PROCESS_DUP_HANDLE (0x0040) // winnt
...
+0x1a4 GrantedAccess : 0x1f0fff
40. ULONG DefaultHardErrorProcessing
DefaultHardErrorProcessing域指定了默认的硬件错误处理，默认为1
+0x1a8 DefaultHardErrorProcessing : 1
41. NTSTATUS LastThreadExitStatus
LastThreadExitStatus域记录了刚才最后一个线程的退出状态。当主线程的入口点函数(WinMain, wWinMain, main, wmain)返回时，会返回到C/C++"运行库启动代码"，后者将正确清理进程使用的全部C运行时资源。在《windows核心编程》这本书中的第4章: 进程。有对进程和线程的创建以及C/C++运行库的启动代码的权威解释。
+0x1ac LastThreadExitStatus : 0
42. PPEB Peb
Peb域是一个进程的"进程环境块(PEB Process Environment Block)"，这是一个位于"进程地址空间(即用户模式空间)"的内存块(为什么要放在用户模式空间呢？因为这个结构需要在被用户模式空间的代码在运行中修改)，其中包含了有关进程地址空间中的堆和系统模块等信息。我们之后会详细分析PEB。
43. EX_FAST_REF PrefetchTrace
PrefetchTrace域是一个快速引用，指向与该进程关联的一个"预取痕迹结构"，以支持该进程的预取。
+0x1b4 PrefetchTrace : _EX_FAST_REF
+0x000 Object : 0x8252944e
+0x000 RefCnt : 0y110
+0x000 Value : 0x8252944e
44. 进程中和IRP相关的内容
LARGE_INTEGER ReadOperationCount;
LARGE_INTEGER WriteOperationCount;
LARGE_INTEGER OtherOperationCount;
LARGE_INTEGER ReadTransferCount;
LARGE_INTEGER WriteTransferCount;
LARGE_INTEGER OtherTransferCount;
ReadOperationCount，WriteOperationCount记录了当前进程NtReadFile和NtWriteFile系统服务被调用的次数，OtherOperationCount记录了除读写操作以外的其他IO服务的次数(文件信息设置.)
ReadTransferCount，WriteTransferCount记录了IO读写操作"完成"的次数，OtherTransferCount记录了除读写操作以外操作完成的次数。 44. PVOID AweInfo
AweInfo域是一个指向AWEINFO结构的指针，其目的是支持AWE(Adress Windowing Extension 地址窗口扩展) 45. SE_AUDIT_PROCESS_CREATION_INFO SeAuditProcessCreationInfo
SeAuditProcessCreationInfo域包含了创建进程时指定的进程映像全路径名，我们之前学过的ImageFileName域实际上就是从这里"提取"出来的。
+0x1f4 SeAuditProcessCreationInfo : _SE_AUDIT_PROCESS_CREATION_INFO
+0x000 ImageFileName : 0x82851db0 _OBJECT_NAME_INFORMATION
46. MMSUPPORT Vm
Vm域是windows为每个进程管理虚拟内存的重要数据结构成员，其类型为MMSUPPORT， \base\ntos\inc\ps.h 中有相关定义。
typedef struct _MMSUPPORT
{
LIST_ENTRY WorkingSetExpansionLinks;
LARGE_INTEGER LastTrimTime; MMSUPPORT_FLAGS Flags;
ULONG PageFaultCount;
WSLE_NUMBER PeakWorkingSetSize;
WSLE_NUMBER GrowthSinceLastEstimate; WSLE_NUMBER MinimumWorkingSetSize;
WSLE_NUMBER MaximumWorkingSetSize;
struct _MMWSL *VmWorkingSetList;
WSLE_NUMBER Claim; WSLE_NUMBER NextEstimationSlot;
WSLE_NUMBER NextAgingSlot;
WSLE_NUMBER EstimatedAvailable;
WSLE_NUMBER WorkingSetSize; EX_PUSH_LOCK WorkingSetMutex; } MMSUPPORT, *PMMSUPPORT;
+0x1f8 Vm : _MMSUPPORT
+0x000 LastTrimTime : _LARGE_INTEGER 0x1ceeef4`925cc6fc
+0x008 Flags : _MMSUPPORT_FLAGS
+0x00c PageFaultCount : 0x3c6
+0x010 PeakWorkingSetSize : 0x39b
+0x014 WorkingSetSize : 0x399
+0x018 MinimumWorkingSetSize : 0x32
+0x01c MaximumWorkingSetSize : 0x159
+0x020 VmWorkingSetList : 0xc0883000 _MMWSL
+0x024 WorkingSetExpansionLinks : _LIST_ENTRY [ 0x805595f0 - 0x828ec62c ]
+0x02c Claim : 0
+0x030 NextEstimationSlot : 0
+0x034 NextAgingSlot : 0
+0x038 EstimatedAvailable : 0
+0x03c GrowthSinceLastEstimate : 0x3c6
(从它的数据结构中我们可以看到很多熟悉的字段，因为一定涉及到内存调度，所以有工作集字段，此外，包括峰值等..)
47. LIST_ENTRY MmProcessLinks
MmProcessLinks域代表一个双链表节点，所有拥有自己地址空间的进程都将加入到一个双链表中，链表头是全局变量MmProcessList。当进程地址空间被初始创建时，MmProcessLinks节点会被加入到此全局链表中。当进程地址空间被销毁时，该节点脱离此链表。此全局链表的存在使得windows系统共可以方便地执行一些全局的内存管理任务，同时也可以被我们用来进行进程枚举。
48. ULONG ModifiedPageCount
ModifiedPageCount域记录了该进程中已修改的页面的数量，即"脏页面数量"，这和缓存的读写有关。
+0x23c ModifiedPageCount : 7
49. ULONG JobStatus
JobStatus域记录了进程所属job的状态。
50. ULONG Flags
Flags域包含了进程的标志位，这些标志位反映了进程的当前状态和配置。 \base\ntos\inc\ps.h 中的宏定义 PS_PROCESS_FLAGS_XXX
...
#define PS_PROCESS_FLAGS_PROCESS_DELETE 0x00000008UL // Delete process has been issued
#define PS_PROCESS_FLAGS_WOW64_SPLIT_PAGES 0x00000010UL // Wow64 split pages
#define PS_PROCESS_FLAGS_VM_DELETED 0x00000020UL // VM is deleted
#define PS_PROCESS_FLAGS_OUTSWAP_ENABLED 0x00000040UL // Outswap enabled
#define PS_PROCESS_FLAGS_OUTSWAPPED 0x00000080UL // Outswapped
#define PS_PROCESS_FLAGS_FORK_FAILED 0x00000100UL // Fork status
#define PS_PROCESS_FLAGS_WOW64_4GB_VA_SPACE 0x00000200UL // Wow64 process with 4gb virtual address space
#define PS_PROCESS_FLAGS_ADDRESS_SPACE1 0x00000400UL // Addr space state1
#define PS_PROCESS_FLAGS_ADDRESS_SPACE2 0x00000800UL // Addr space state2
#define PS_PROCESS_FLAGS_SET_TIMER_RESOLUTION 0x00001000UL // SetTimerResolution has been called
...
+0x248 Flags : 0xd0800
51. NTSTATUS ExitStatus
ExitStatus域包含了进程的退出状态，从进程的退出状态通常可以获知进程非正常退出的大致原因。反映退出状态的一些宏定义位于 public\sdk\inc\ntstatus.h
...
#define STATUS_SEVERITY_SUCCESS 0x0
#define STATUS_SEVERITY_INFORMATIONAL 0x1
...
52. USHORT NextPageColor
NextPageColor域用于物理页面分配算法。
53. USHORT SubSystemVersion
SubSystemVersion域中的SubSystemMinorVersion和SubSystemMajorVersion分别记录了一个"进程的子系统"的主板本号和此版本号，它们的值来源于进程映像文件PE的对应版本信息(PE的头部包含了此信息)。在之前的PE结构探究中有关于这方面的内容。
http://www.cnblogs.com/LittleHann/archive/2013/06/14/3136111.html
+0x252 SubSystemMinorVersion : 0 ''
+0x253 SubSystemMajorVersion : 0x4 ''
54. UCHAR PriorityClass
PriorityClass域是一个单字节值，它说明了一个进程的优先级程度。这和进程、线程优先级的知识有关。
1) windows支持6个进程优先级类(priority class): idle, below normal, normal, above normal, high, real-time。
normal是最常用的优先级类
real-time：此进程中的线程必须立即响应事件，执行实时任务。次进程中的线程还会抢占操作系统的组件的CPU时间。
high：此进程中的线程必须立即响应事件，执行实时任务。任务管理器运行在这一级，因此用户可以通过它结束失控的进程
above normal：
normal：此进程中的线程无需特殊的调度，大多数进程都是这一级别的
below normal：
idle：此进程中的线程在系统空闲时运行。屏保，后台实时程序通常使用该优先级
2) 选择了进程优先级后，我们应该转而关心进程中线程的相对优先级
idle, lowest, below normal, normal, above normal, highest, time-critical
应用程序的开发人员无需处理优先级，而是由系统将进程的优先级类和线程的相对优先级整合起来映射到一个优先级值(组成一个二维表)。
注意：
1. 表中线程优先级没有0，因为0优先级保留给页面清零线程了，系统不允许其他任何线程的优先级为0.
2. ring3应用程序无法获得一下优先级：17，18，19，20，21，27，28，29，30。如果你编写的是内核模式的驱动程序，那可以获得这些优先级
3. real-time优先级类的线程，其优先级不能低于16.非real-time优先级线程的优先级不能高于1
在 public\sdk\inc\ntpsapi.h 中可以找到PROCESS_PRIORITY_CLASS_XX的宏定义
#define PROCESS_PRIORITY_CLASS_UNKNOWN 0
#define PROCESS_PRIORITY_CLASS_IDLE 1
#define PROCESS_PRIORITY_CLASS_NORMAL 2
#define PROCESS_PRIORITY_CLASS_HIGH 3
#define PROCESS_PRIORITY_CLASS_REALTIME 4
#define PROCESS_PRIORITY_CLASS_BELOW_NORMAL 5
#define PROCESS_PRIORITY_CLASS_ABOVE_NORMAL 6
PriorityClass域说明了一个进程的优先级程度
55. MM_AVL_TABLE VadRoot
VadRoot域指向一个平衡二叉树的根，用于管理该进程的虚拟地址空间。
56. ULONG Cookie
Cookie域存放的是一个代表该进程的随机值，当第一次通过NtQueryInformationProcess函数获取此Cookie值的时候，系统会生成一个随机值，以后就用此值代表此进程。
+0x258 Cookie : 0x936269b3
我们在编译时使用的GS防御技术中用到的Cookie值指的就是这个，关于这个Cookie，我了解的不是很多，这里给出在程序中dunp下来的cookie创建流程吧。
大概思路是计算这么一个表达式的值
KPRCB->KeSystemCalls^KPRCB->InterruptTime^KeQuerySystemTime()返回值的高双字^KeQuerySystemTime()返回值的低双字
再用cmpxchg指令把这个随机值赋给EPROCESS.COOKIE 805c395b 8d45c4 lea eax,[ebp-0x3c]
805c395e 50 push eax
805c395f e8c643f3ff call nt!KeQuerySystemTime (804f7d2a)
805c3964 3ea120f0dfff mov eax,ds:[ffdff020] ;eax=kpcr->Prcb
805c396a 8b8818050000 mov ecx,[eax+0x518] ;ecx=KPRCB->KeSystemCalls
805c3970 3388b8040000 xor ecx,[eax+0x4b8] ;ecx=KPRCB->KeSystemCalls ^ KPRCB->InterruptTime
805c3976 334dc8 xor ecx,[ebp-0x38] ;ecx=
805c3979 334dc4 xor ecx,[ebp-0x3c]
805c397c 898d34ffffff mov [ebp-0xcc],ecx ;ecx=KPRCB->KeSystemCalls ^ KPRCB->InterruptTime ^KeQuerySystemTime()
返回值的高双字^KeQuerySystemTime()返回值的
低双字
805c3982 89bd2cffffff mov [ebp-0xd4],edi ;edi=&eprocess->Cookie
805c3988 b800000000 mov eax,0x0 ;eax=0
805c398d 8b8d2cffffff mov ecx,[ebp-0xd4] ;ecx=&eprocess->Cookie
805c3993 8b9534ffffff mov edx,[ebp-0xcc] ;edx=KPRCB->KeSystemCalls ^ KPRCB->InterruptTime ^KeQuerySystemTime()
返回值的高双字^KeQuerySystemTime()返回值的
低双字
805c3999 0fb111 cmpxchg [ecx],edx
+0x258 Cookie : 0x936269b3
至此，我们已经把EPROCESS的全部结构都分析完毕了，本来是想把KPROCESS/PEB放到一起的，可以发现这样篇幅有些过长了，所以决定把KPROCESS和PEB放到下一篇学习笔记一起解决。
EPROCESS KPROCESS PEB 《寒江独钓》内核学习笔记（3）