DSP

栈溢出崩溃排查(二)

2019-07-13 19:46发布

(接上文) 竟然全是0,试着输出再多一些,输入dps esp L100,终于能看到熟悉的调用栈了,当然这种形式与我们平时看windbg的不同,这里把调用栈的原始数据输出了,具体调用流程,还要我们自己去分析。 实际上到这里,已经猜到十有八九是发生了栈溢出,其判断理由有二,第一EIPEBP的值同时被覆盖掉了,第二EIPEBP的值跟ESP指向的栈上的值相同,都是0,想想函数的调用过程,当函数调用时,首先会把返回地址,原EBP压栈,当函数返回时,再将EBP,返回地址弹出栈,这时EIPEBP就跟栈上的数据一致,这种情况下,就是原来压入堆栈的返回地址,EBP值被覆盖了。 接下来的工作,就是要找到在哪里发生了栈溢出,从图中可以看到,很多地方要么是系统的要么是第三方的,我们找到自己写的代码离系统调用最近的那部分,藉此作为突破口。 图中可以清楚看到,windbg为我们指出了一个位置,download.cpp 的第129行。由于离当前调用栈很远,这一般不是发生栈溢出的位置,我们可以从这里继续跟踪下去,直到发生问题的最终现场。   三、追踪问题现场,找出幕后元凶 windbg为我们指明的代码处下断点,进行单步调试。 通过单步跟踪,发现问题发生在这一行 这是一个帧分析库的API,当调用(图中隐去API名称)时,会将结果返回到packet变量中,从下图中可以看出,当调用该API时,影响了从packet变量起始的0x2F2AF888~~0X2F2AF8F8总共116个字节,而在IDE中看到,packet实际只有80个字节,因此这里造成了栈溢出。 一般这种情况是,所使用的DLL库版本对结构体的定义不一致造成,这就是著名的DLL HELL,统一下该帧分析库的版本,问题迎刃而解。