创建: 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地址。
如有更好的办法,请指教。