创建: 2021-11-10 11:26
http://scz.617.cn:8/windows/202111101126.txt

分析ALPC时获取到ServerCommunicationPort地址，想反查该ALPC Port在所属进程中的句柄号，以便对某些使用句柄号做形参的函数设置条件断点。这只是标题所示场景之一，显然存在其他场景，根据Object地址反查句柄号是个通用需求。

最蠢的办法是在目标进程中直接用!handle命令找，比如

.cache 0x20000
!handle -1 0 -1 ALPC Port
!handle -1 1 0n872 ALPC Port

这个输出可能很长，肉眼过滤指定Object不现实的话，就得.logopen/.logclose。

理论上可以这样，但实测从未成功过，可能!handle输出太多，始终没等到结束？

.shell -ci "!handle -1 0 -1 ALPC Port" findstr ffffda8843b8a870
.shell -ci "!handle -1 1 0n872 ALPC Port" findstr ffffda8843b8a870

从Win7到Win10，进入kd模式时很可能发现"!handle -1 0 -1 ALPC Port"不能有效过滤出"ALPC Port"对象。这事我在2017年向windbg团队以及另一个OS开发团队邮件反馈过细节，windbg团队礼节性回复说转给什么团队了，没有下文，另一个团队干脆没反馈，懒得再追。

10.0.19041.1版windbg，Win10企业版2016 LTSB 1607(OS Build 14393.4704)，仍能复现。不知算是!handle实现的问题，还是OS实现的问题，兼而有之吧。同样版本的windbg与XP配合时无此BUG，逆向分析XP内核相关数据结构，没有从Win7开始的幺蛾子。现在我要是确有需要，就临时在kd中热Patch内核数据结构，让!handle更正常些。

若"!handle -1 0 -1 ALPC Port"不能有效过滤出"ALPC Port"对象，至少还可在"!handle -1 0 -1"的输出中找指定Object，那个输出更冗长，不到万不得已别那么干。

除了上述最蠢的办法，调试时根据Object地址反查句柄号的正经套路是啥？我不是长年浸淫Windows内核调试的人，全是事件驱动型，孤陋寡闻得很。

就此通用需求，给个我自己的邪门办法。指定session、process、object，可用如下办法反查句柄号

dx @$session=0
dx @$process=0n872
dx @$object=0xffffda8843b8a870
dx Debugger.Sessions[@$session].Processes[@$process].Io.Handles.Where(h=>&h.Object.Body==(_QUAD *)@$object)

这比从"!handle -1 1 0n872 ALPC Port"输出中寻找要快得多，而且不受前述BUG影响，也不涉及过滤"ALPC Port"，就是吃果果地比较Object地址。

如有更好的办法，请指教。