近期我想从事win32k的漏洞挖掘 分析了些漏洞，从这个漏洞我考虑的是怎么发现的呢，
我对这块比较陌生，我熟悉的是DirectX这块的漏洞挖掘。
SetWindowsHookExA挂钩 ，TrackPopupMenu显示快捷菜单，poc是截获1EB消息。然后EndMenu 返回-5 为什么这样是因为xxxMNFindWindowFromPoint的返回值 叫做v1吧 他的返回判断是下面这样
v38 = xxxMNFindWindowFromPoint((WCHAR)v3, (int)&UnicodeString, (int)v7);
if ( !v38 && !UnicodeString )
{
xxxMNDismiss(a2);
return 1;
}
if ( *(_BYTE *)v3 & 2 && v38 == -5 ) //与2其与-5比较
{
xxxMNSwitchToAlternateMenu(v3);
v38 = -1;
}
if ( v38 == -1 )//与-1比较
{
xxxMNDoubleClick(a2, v3, UnicodeString);
return 1;
}
v46 = *((_DWORD *)gptiCurrent + 45);
*((_DWORD *)gptiCurrent + 45) = &v46;
v47 = v38;
if ( v38 )
++*(_DWORD *)(v38 + 4);
v41 = UnicodeString;
LOBYTE(v40) = -15;
v39 = (void *)v38;
LABEL_144:
xxxSendMessage(v39, v40, v41, 0); //xxxMNFindWindowFromPoint 的返回值接着被发送
LABEL_145:
ThreadUnlock1();
return 1;
调用路径 NtUserTrackPopupMenuEx->xxxTrackPopupMenuEx->xxxMNLoop->xxxHandleMenuMessages->xxxMNFindWindowFromPoint->xxxSendMessage
因为对0xFFFFFFFB单独判断 查看反汇编得知0xFFFFFFFFB被xxxSendMessage当作消息发送 即bsod 如果0xFFFFFFFFB被申请 则会被利用。下面是汇编 eax即是0xFFFFFFFFB
.text:BF93935E test byte ptr [edi], 2
.text:BF939361 jz short loc_BF939371
.text:BF939363 cmp eax, 0FFFFFFFBh
.text:BF939366 jnz short loc_BF939371
.text:BF939368 push edi ; HDC
.text:BF939369 call _xxxMNSwitchToAlternateMenu@4 ; xxxMNSwitchToAlternateMenu(x)
.text:BF93936E or eax, 0FFFFFFFFh
.text:BF939371
.text:BF939371 loc_BF939371: ; CODE XREF: xxxHandleMenuMessages(x,x,x)+5E9�j
.text:BF939371 ; xxxHandleMenuMessages(x,x,x)+5EE�j
.text:BF939371 cmp eax, 0FFFFFFFFh
.text:BF939374 jnz short loc_BF939382
.text:BF939376 push dword ptr [ebp+UnicodeString]
.text:BF939379 push edi
.text:BF93937A push esi
.text:BF93937B call _xxxMNDoubleClick@12 ; xxxMNDoubleClick(x,x,x)
.text:BF939380 jmp short loc_BF9393B7
.text:BF939382 loc_BF939382: ; CODE XREF: xxxHandleMenuMessages(x,x,x)+5FC�j
.text:BF939382 mov ecx, _gptiCurrent
.text:BF939388 add ecx, 0B4h
.text:BF93938E mov edx, [ecx]
.text:BF939390 mov [ebp+var_20], edx
.text:BF939393 lea edx, [ebp+var_20]
.text:BF939396 mov [ecx], edx
.text:BF939398 mov [ebp+var_1C], eax
.text:BF93939B test eax, eax
.text:BF93939D jz short loc_BF9393A2
.text:BF93939F inc dword ptr [eax+4]
.text:BF9393A2
.text:BF9393A2 loc_BF9393A2: ; CODE XREF: xxxHandleMenuMessages(x,x,x)+625�j
.text:BF9393A2 push 0 ; Address
.text:BF9393A4 push dword ptr [ebp+UnicodeString] ; UnicodeString
.text:BF9393A7 push 1F1h ; MbString
.text:BF9393AC push eax ; P
.text:BF9393AD
.text:BF9393AD loc_BF9393AD: ; CODE XREF: xxxHandleMenuMessages(x,x,x)+172�j
.text:BF9393AD call _xxxSendMessage@16 ; xxxSendMessage(x,x,x,x)
.text:BF9393B2
对于挖掘 如果看到这里发现对于-5没有单独判断，可以尝试挂钩处理会有收获。
fuzz呢？我对于fuzz说起来也就是for循环，加一些自己的小想法，这种漏洞我觉得发现者可能是看出来的，我之前也看出来过一个Directx的漏洞，但是刚看出来人家就补了 蛮遗憾。这个漏洞的分析有现成poc打断点调试即可，至于怎么发现类似的我想是注意返回比较，看吧 当然要熟悉menu的很多内容比如结构体，所以我决定在调试几个就再看文档整理成册 然后先调调函数 其他的再说
