最近、私はいくつかの抜け穴の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を分解するので、別々に分析します。以下は0xFFFFFFFFB EAXでまとめたものです
.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ない単一の裁判官見つかったかどうかを確認するために掘るためには、ハンドルが収穫されますフックしようとするかもしれません。
それをファジング？私はサイクリングのためにあるアップファジングと言う、プラス彼の小さなアイデアのいくつかは、私はこの脆弱性の発見者が見ることができたと思うし、また私の前のDirectXの脆弱性を見渡すが、ちょうど非常に補うために他の人を見ます申し訳ありません。デバッグに対する脆弱性準備POCブレークポイントの分析は、私は似たノートのリターンを見つけるしたいと思いますどのようにこのようなメニュー構造として、コンテンツの多くに精通して当然の外にそれを比較したので、私は、デバッガでいくつかのドキュメントを見て決めました最初の本の中に整理して、チューニング機能、他の発言