原本以为对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)
[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)
