搜索论坛 帖子排序:  Oldest to newest Newest to oldest

2011-04-28, 14:49 下午 wrong 注册: 2011-01-07 发 贴: 66 buffer overrun下__report_gsfailure的不同表现。 看了第22章节，现在的VS中使用security cookie技术来阻止buffer overrun，总是觉得CRT的代码比较奇怪，难以理解，如下： 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); 写了段代码来测试它， 1. 使用VS调试的时候，代码的最后在第2行_CRT_DEBUGGER_HOOK断了下来，但是不知道原因，是不是VS做了特别的处理？ 2. 使用windbg的时候，是断在了kernel32!UnhandledExceptionFilter里，也就执行第5行的时候，有个int 3即断点指令。记得UEF的处理逻辑是在调试器里运行的时候直接返回EXCEPTION_CONTINUE_SEARCH， 为什么会产生了断点？ IP 地址: 已记录   报告

2011-05-03, 01:42 上午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: buffer overrun下__report_gsfailure的不同表现。 1，_CRT_DEBUGGER_HOOK是CRT中与VS调试器通信的代码，当使用VS调试器时，这个函数会触发一个异常，通知VS调试器，VS调试器通常附带的参数_CRT_DEBUGGER_GSFAILURE，知道这是溢出情况。不使用VS调试器时，这个函数会跳转到一个dummy的函数 2，UnhandledExceptionFilter里对GS也有特殊支持，会判断异常代码是否是0C0000409h，即STATUS_STACK_BUFFER_OVERRUN，也即是__report_gsfailure中模拟出的异常 0:001> !error 0C0000409h Error code: (NTSTATUS) 0xc0000409 (3221226505) - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application. IP 地址: 已记录   报告

2011-05-04, 13:53 下午 wrong 注册: 2011-01-07 发 贴: 66 Re: buffer overrun下__report_gsfailure的不同表现。 第2个问题，正在看UEF的代码，确实是有些特殊处理。 第1个问题奇怪的地方是，代码只有一份，_CRT_DEBUGGER_HOOK检测当前的调试器并且VS下trigger 异常的话，这些代码应该可以被观察到的，但事实上使用windbg看不到这些代码。难道是VS加载程序的时候修改了PE文件？ IP 地址: 已记录   报告

2011-05-04, 14:11 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: buffer overrun下__report_gsfailure的不同表现。 动态Hook，VS调试时，再用WinDBG选择noninvasive附加WinDBG可以看到... IP 地址: 已记录   报告

2011-05-04, 16:26 下午 wrong 注册: 2011-01-07 发 贴: 66 Re: buffer overrun下__report_gsfailure的不同表现。 花了点时间，总算有了点结果，http://user.qzone.qq.com/31731705/blog/1304480303 第一条指令被替换成了int 3。但看到的是替换后的结果，怎么样才能跟踪到替换的过程呢？ 由这个问题还引出了另一个问题，一个Exe的import table是在加载DLL的时候修改的，那怎么能跟踪这个过程呢。我发现在初始断点的时候我需要跟踪的dll已经被load了，import table里已经填充了正确的值。 IP 地址: 已记录   报告

2011-05-06, 09:48 上午 wrong 注册: 2011-01-07 发 贴: 66 Re: buffer overrun下__report_gsfailure的不同表现。 一开始的想法是使用数据断点，不管是VS替换_CRT_DEBUGGER_HOOK，还是加载器替换import table中值，理论上都可以中断。 问题是找不到合适的时机，调试器上去的时候，上述动作已经完成了。 IP 地址: 已记录   报告

高端调试 » 软件调试 » Windows内核调试 » buffer overrun下__report_gsfailure的不同表现。

请选择 论坛首页 |- 论坛搜索 |- 热门主题 |- 未回复的主题 用户选项 |- 登录 |- 注册 |- 找回密码 软件调试 |- Windows内核调试 |- C/C++本地代码调试 |- .Net程序调试 |- 脚本程序调试 |- Java程序调试 |- Linux内核调试 |- 《程序员》杂志调试专栏 |- WinDbg |- GDB |- 远程调试 |- 调试ACPI和BIOS |- 特殊的调试任务 |- 转储分析 |- GDK7 内核探秘 |- Windows内核 |- Linux内核 系统架构 |- CPU架构 |- PCI/PCI Express架构 程序人生 |- 软件物语 |- 社区活动 |- 名人逸事 联盟论坛 |- 欢迎使用CnForums 没有银弹 |- BUG也精彩 |- 豆腐工程 |- 软件圈里十大怪 Windows Vista |- 用调试利剑剖析VISTA内幕 |- 老专家如何破解新问题 |- 我的电脑谁说了算？ |- 资源 Office开发 |- Visio 驱动程序开发 |- Windows驱动开发 |- Linux驱动开发 |- Windows CE驱动开发 用户态开发 |- Windows本地代码（native）高级开发 |- Web应用开发 |- WinFX和.Net |- Office开发 本站建设 |- 高端调试团队 |- 版面布局 |- 活动建议 |- 网站维护 64位计算 |- 64-bit Windows |- 64-bit CPU 图书 |- 《软件调试》的示例程序 |- 《软件调试》的工具 |- 《软件调试》书友 |- 《软件调试》答疑 |- 《软件调试》勘误和意见 |- 《格蠹汇编》 |- 《软件调试》第二版卷1 |- 《软件调试》第二版卷2 云计算 |- IaaS |- 云存储 |- 大数据 |- PaaS和SaaS GPU |- CUDA |- OpenCL |- HSA |- 游戏开发与调试