__report_gsfailure中UEF的特殊行为

原本以为对UEF的逻辑已经大概了解了（理解UnhandledExceptionFilter），最近调试__report_gsfailure的时候却碰到了新问题。从VS2005以来，编译器添加了对栈的保护检查以防止buffer overrun的危害。一旦发现栈的内容出现错误，会调用__report_gsfailure，代码如下：­

1. DebuggerWasPresent = IsDebuggerPresent(); ­

2. _CRT_DEBUGGER_HOOK(_CRT_DEBUGGER_GSFAILURE); ­

3. ­

4. SetUnhandledExceptionFilter(NULL); ­

5. UnhandledExceptionFilter((EXCEPTION_POINTERS *)&GS_ExceptionPointers); ­

6. if (!DebuggerWasPresent) ­

7. { ­

8. _CRT_DEBUGGER_HOOK(_CRT_DEBUGGER_GSFAILURE); ­

9. } ­

10.TerminateProcess(GetCurrentProcess(), STATUS_STACK_BUFFER_OVERRUN);

­

 

使用一小段简单的代码即可测试之，­

char overBuf[8];­

DWORD dwForBuf;

­

 

char anotherBuf[8];­

DWORD dwForAnotherBuf;

­

 

dwForBuf = 0x12341234;­

// break compiler fense­

strcpy( overBuf, "12345678""/xcc/xcc/xcc/xcc""1234" );

­

 

dwForAnotherBuf = 0xabcdabcd;­

strcpy( anotherBuf, "0123" );

­

 

1. 使用VS调试的时候，执行到最后会在第2行_CRT_DEBUGGER_HOOK处断下来，不知道原因，怀疑是VS做了特别的处理，因为使用windbg调试的时候，就象是执行了一个普通的函数，没有任何问题。­

2. 使用windbg的时候，是断在了kernel32!UnhandledExceptionFilter里，也就执行第5行的时候，有个int 3的断点指令。记得UEF的处理逻辑是在调试器里运行的时候直接返回EXCEPTION_CONTINUE_SEARCH， 为什么会产生了断点？ ­

3. 如果在调试器外执行，结果应该如何？

第一个问题的答案在这： __report_gsfailure中UEF的特殊行为 (1)

第二个问题的答案在这： __report_gsfailure中UEF的特殊行为 (2)

第三个问题的答案在这： __report_gsfailure中UEF的特殊行为 (3)