首先是参考文章：

https://bbs.pediy.com/thread-14600.htm （作者：一块三毛钱）

https://bbs.pediy.com/thread-55453.htm （作者：炉子）

    这里先简单回顾一下前人的枚举思路：一块三毛钱采用的是枚举所有线程并取ETHREAD的THREADINFO，同时枚举16种钩子类型iHookType，调用win32k.sys中未导出函数PVOID PhkFirstValid(PTHREADINFO pti, int iHookType)获得保存钩子信息的结构体tagHOOK的首地址，随后循环调用PVOID PhkNextValid(tagHOOK*)以枚举所有的消息钩子。炉子的思路是获取user32.dll中与win32k.sys的共享变量gSharedInfo，遍历gSharedInfo->aheList的数组成员_HANDLEENTRY，总数为gSharedInfo->psi->cHandleEntries，若成员_HANDLEENTRY的bType为5，则其为消息钩子，_HANDLEENTRY的phead成员即为钩子对应的内核tagHOOK结构体首地址。

    鉴于炉子的方法相对简便，本文的研究思路以炉子的方法作为基础展开。

    首先介绍枚举方案中涉及的关键结构体：tagHOOK和_HANDLEENTRY。

    tagHOOK结构体成员在64位Win10下没有变化，其简要结构为

    在Win10 RS1（14393）及之前的64位Windows系统，_HANDLEENTRY结构为：

    按照炉子的方法，只要取出其中的phead成员即为内核tagHOOK结构体的首地址，然而Win10 RS2（15063）中，微软为了修复GDI Object Leak，将_HANDLEENTRY中的phead和pOwner成员移除了，以下分别是14393和15063下gSharedInfo->aheList的_HANDLEENTRY数组：

    新的HANDLEENTRY结构也没有写进符号文件，笔者水平有限，只能得到新的HANDLEENTRY大概长这样：

    第一眼看过去，似乎新版HANDLEENTRY没有提供多少查找tagHOOK结构体的线索。笔者决定跟一下gSharedInfo在内核的变动，值得一提的是，Windows 10下gSharedInfo从win32k.sys移到了win32kbase.sys中。

    经过一番查找，笔者发现win32kbase!HMValidateHandle引用了gSharedInfo->aheList的成员，传入的句柄参数取低16位即为aheList数组的索引，同时该索引也参与到取内核结构体地址的运算。在Win10 RS2中伪代码如下：

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！