原文发表于百度空间，2009-02-28
==========================================================================
句柄是Windows对象管理中引入的一个东西，它的实际意义是对象在句柄表中的索引。Windows2000使用的是固定的三层句柄表，而WindowsXP和Windows2003都是使用的动态可扩展的三层句柄表，这是一种很优秀的结构，易扩展，且查找迅速，值得学习。通常情况下每个进程的句柄表都是一级表，当句柄数超过一级表的容量时，就会扩展为二级表，此时二级表中放的是指向一级表的指针。同样，当二级表也放满时，就会扩展为三级表，里面放指向二级表的指针。但是通常我们看不到这种情况，因为就目前的大多数情况来说，二级表的容量已经够我们用了。
接下来具体地看一下进程的句柄表。每个进程都有一个句柄表，包括System进程(不过System的句柄表稍有点特殊)，但是Idle除外，因为它并不是一个事实上真正的进程。在进程对象EPROCESS中，可以直接找到句柄表指针。
来找个进程对象看看：
lkd> dt _EPROCESS 8a92cb98 nt!_EPROCESS ... +0x0c4 ObjectTable : 0xe23d3690 _HANDLE_TABLE
句柄表是一个HANDLE_TABLE结构，继续来看：
lkd> dt _HANDLE_TABLE 0xe23d3690 nt!_HANDLE_TABLE +0x000 TableCode : 0xe3202001 //句柄表 +0x004 QuotaProcess : 0x89833da0 _EPROCESS //所属进程的EPROCESS +0x008 UniqueProcessId : 0x00000430 //所属进程的pid +0x00c HandleTableLock : [4] _EX_PUSH_LOCK //句柄表锁，用于进程某些操作时锁住句柄表 +0x01c HandleTableList : _LIST_ENTRY [ 0xe216735c - 0xe2394fd4 ] //句柄表的双链，所有进程的句柄表链在一起，如果搞隐藏进程的话，这个地方是必须要照顾到的 +0x024 HandleContentionEvent : _EX_PUSH_LOCK +0x028 DebugInfo : (null) +0x02c ExtraInfoPages : 0 +0x030 FirstFree : 0x114c +0x034 LastFree : 0 +0x038 NextHandleNeedingPool : 0x1800 //当前句柄表池的上界 +0x03c HandleCount : 1152 //当前进程中句柄总数 +0x040 Flags : 0 +0x040 StrictFIFO : 0y0
这里面最重要的，当然就是TableCode了。
TableCode的低两位被用作标志位，用于表示当前句柄表的级数,0,1,2分别表示一级表，二级表，三级表。
比如这里的0xe3202001 ，掩去高位，低两位的值为1,即为二级表。对于二级表，表中存放的是指向一级表的指针，一级表又被称为基本表，这实际上一个HANDLE_TABLE_ENTRY数组，它里面存放的HANDLE_TABLE_ENTRY中才是真正的对象，其定义如下:
typedef struct _HANDLE_TABLE_ENTRY { // // The pointer to the object overloaded with three ob attributes bits in // the lower order and the high bit to denote locked or unlocked entries // union { PVOID Object; ULONG ObAttributes; PHANDLE_TABLE_ENTRY_INFO InfoTable; ULONG_PTR Value; }; // // This field either contains the granted access mask for the handle or an // ob variation that also stores the same information. Or in the case of // a free entry the field stores the index for the next free entry in the // free list. This is like a FAT chain, and is used instead of pointers // to make table duplication easier, because the entries can just be // copied without needing to modify pointers. // union { union { ACCESS_MASK GrantedAccess; struct { USHORT GrantedAccessIndex; USHORT CreatorBackTraceIndex; }; }; LONG NextFreeTableEntry; }; } HANDLE_TABLE_ENTRY, *PHANDLE_TABLE_ENTRY;
一级表可以放多大的句柄呢？按WRK中的宏展开，有
(TABLE_PAGE_SIZE / sizeof(HANDLE_TABLE_ENTRY))*HANDLE_VALUE_INC
即0x1000/8*4=0x800
计算过程：一级表(基本表)的大小为一页即4K=0x1000 Byte，而HANDLE_TABLE_ENRY大小为8字节，则可存放的个数为0x1000/8=0x200=512,而句柄以4为步进，因此最大句柄为0x200*4=0x800.其中可存放的最大句柄不超过0x800(最大为0x800-4)，而每个一级表的第一个HANDLE_TABLE_ENTRY的Object总是为0,因为我们都知道0是一个无效的句柄，它不指向一个有效的对象。因此，每个一级表实际存放的句柄数为511个。我们当前查看的句柄表中共有句柄1152个，显然一个表是不够的，1152=511*2+130，这里显然需要三个表，且第三个表未放满。而TableCode值为0xe3202001，其低两位也说明了这是个二级表。掩去低两位之后才是二级表的真正地址。来查看一下：
lkd> dd 0xe3202000 e3202000 e2a7b000 e3203000 e2c1e000 00000000 e3202010 00000000 00000000 00000000 00000000 e3202020 00000000 00000000 00000000 00000000 e3202030 00000000 00000000 00000000 00000000 e3202040 00000000 00000000 00000000 00000000
没错的，二级表中放了三个一级表指针。再来查看一下第一个一级表的内容。
lkd> dd e2a7b000 e2a7b000 00000000 fffffffe e100b4e9 000f0003 e2a7b010 e1a9ef41 00000003 898343b3 00100020 e2a7b020 8982ece9 021f0003 e1a794e9 000f000f e2a7b030 e23a61b9 021f0001 e2390a59 020f003f
明显看到，第一个HANDLE_TABLE_ENTRY的Object为0.从第二个起才是有效的对象(如果某对象所对应的句柄被关闭，那么该对象就会从相应的句柄表中删除，所以并非句柄表中的每个位置存放的都是有效对象)。
接下来看HANDLE_TABLE_ENTRY，e100b4e9 000f0003这一对数据就是HANDLE_TABLE_ENTRY结构中的Object和GrantedAccess了。但是这里的Object并不是直接指向对象的。因为对象体总是8字节对齐，所以地址的低三位总是0，因此被用于标志位，表明该对象所对应的句柄的一些属性，比如可继承等等。因此，要对这里得到的Object掩去低三位，才会得到一个指向对象头OBJECT_HEADER的指针。
e100b4e9这里掩去之后为e100b4e8
lkd> dt _OBJECT_HEADER e100b4e8 nt!_OBJECT_HEADER +0x000 PointerCount : 28 +0x004 HandleCount : 27 +0x004 NextToFree : 0x0000001b +0x008 Type : 0x8a928e70 _OBJECT_TYPE +0x00c NameInfoOffset : 0x20 ' ' +0x00d HandleInfoOffset : 0 '' +0x00e QuotaInfoOffset : 0 '' +0x00f Flags : 0x36 '6' +0x010 ObjectCreateInfo : 0x00000001 _OBJECT_CREATE_INFORMATION +0x010 QuotaBlockCharged : 0x00000001 +0x014 SecurityDescriptor : 0xe100b44d +0x018 Body : _QUAD
继续来看一下这个OBJECT_TYPE
lkd> dt _OBJECT_TYPE 0x8a928e70 nt!_OBJECT_TYPE +0x000 Mutex : _ERESOURCE +0x038 TypeList : _LIST_ENTRY [ 0xe100b4d8 - 0xe100b4d8 ] +0x040 Name : _UNICODE_STRING "KeyedEvent" +0x048 DefaultObject : 0x80568b40 +0x04c Index : 0x10 +0x050 TotalNumberOfObjects : 1 +0x054 TotalNumberOfHandles : 0x1b +0x058 HighWaterNumberOfObjects : 1 +0x05c HighWaterNumberOfHandles : 0x1b +0x060 TypeInfo : _OBJECT_TYPE_INITIALIZER +0x0ac Key : 0x6579654b +0x0b0 ObjectLocks : [4] _ERESOURCE
是个KeyedEvent对象。对象头再加上它本身的大小0x18之后就到了对象体OJBECT_BODY了，这个因不同对象而异。直接来看一下:
lkd> !object e100b4e8+0x18 Object: e100b500 Type: (8a928e70) KeyedEvent ObjectHeader: e100b4e8 (old version) HandleCount: 27 PointerCount: 28 Directory Object: e10000a8 Name: CritSecOutOfMemoryEvent
跟前面看到的对比一下，完全是一致的。这样就了解了如何从进程的句柄表中得到实际的对象。
下面以该进程中的一个句柄0x1078为例说明句柄如何索引到对象。
0x1078/0x800=2
0x1078%0x800=0x78
前面已经知道，该进程的句柄表为二级表，而上面的计算结果表明，该句柄大小已经超出了两个句柄表的范围，在第三个句柄表中，且偏移为0x78*2.(因为句柄按4递增，而HANDLE_TABLE_ENTRY结构大小为8，所以正确公式应该为0x78除以4得到索引值，再乘以8得到以字节计算的偏移值，结果即0x78*2)
而第三张表基址为e2c1e000 。来看一下:
lkd> dd e2c1e000+0x78*2 e2c1e0f0 896b7019 001f03ff 8984e659 00100003 e2c1e100 8984e611 00100003 e2d183d9 00020019 e2c1e110 898003f1 001f0003 896c0701 0012019f e2c1e120 8984e5c9 00100003 89834691 00100003
可以得到Object为896b7019，掩去低两位，则对象头指针为896b7018，对象体指针为896b7018+0x18
lkd> !object 896b7018+0x18 Object: 896b7030 Type: (8a92c040) Thread ObjectHeader: 896b7018 (old version) HandleCount: 3 PointerCount: 5
结果显示这是一个线程对象，与Process Explorer中显示的结果完全一致。以上过程很容易转化为程序实现并且不依赖任何系统函数，具体实现过程可参考WRK中的ExpLookupHandleTableEntry 函数，其原型为
PHANDLE_TABLE_ENTRY
ExpLookupHandleTableEntry (
IN PHANDLE_TABLE HandleTable,
IN EXHANDLE tHandle
);
下一篇准备再写写PspCidTable~
ps:大部分进程中句柄数并不多，因此通常为一级表。那么如何找到一个有二级表的进程进行观察呢？首先，你可以自己人为地“造”一个出来。或者，找服务数最多的那个svchost.exe进程(用Process Explorer可以很容易找出来)，它是20多个服务的宿主，句柄不多就怪了~~