本文借助windbg来理解程序中的函数如何使用handle对句柄表进行查询的。所以先要开启Win7下Windbg的内和调试功能。
- 解决win7下内核调试的问题
重启之后开启Local Kernel Debugging：
开启成功：
加载符号表之后，就可以使用！process命令了：
- 解决windbg源码调试的问题：
添加源文件路径：
开启源码级别的调试：
- 研究句柄
再开一个windbg用内核调试。！process 0 0 命令找到TestHandle.exe的信息：
查看这个进程的所有句柄信息（同时也显示出了OBJECT的信息，来给我们提供验证）：
下面，借助对TestHandle.exe的调试我们知道38号句柄是hEvent：
查看0x38号句柄的信息（这个信息被我当做“结果”来验证我的“推理”过程）：
- 推理步骤
查看TestHandle的EProcess结构：
得到TableCode，这个值指向一级、二级或三级句柄表（具体是几级句柄表由末尾数决定）:
根据低两位判断句柄表的层级。TableCode低位是1，说明是一个二级句柄表（可以参考这个文章的分析：https://www.cnblogs.com/lsh123/p/7296423.html）：
那么句柄值乘以4再加上fffff8a0`19ca8000就是指向对应的handle_table_entry：//为什么这里要乘以4？句柄是0x38，索引就是0x38/4，又由于每个handle_table_entry的大小是16字节。那么为什么索引是0x38/4?后面会回答
找到对应的handle_table_entry：
其中fffffa80`11399951 就是Object指针，偏移0x30-1就可以定位到OBJECT：
因为是在64位系统下，所以偏移是0x30-1，偏移发生了变化（32位系统下就是0x17）：
- handle的类型
- 为什么要除以4？
这个 TagBit 值占两位（bit 0 到 bit 1），被清为 0 值。因此：tHandle.Value 值就是对齐在 4 bytes 边界上。（出于某种原因）使用高30位作为索引来查找句柄表，低两位的存在没有意义。参考：https://www.cnblogs.com/ck1020/p/5897460.html
现在低两位没有意义不代表将来低两位没有意义，handle的含义和使用可能在未来发生变化。
