下面是应用程序崩溃转储的调用堆栈。报告的崩溃是名为“HelperLibrary”的模块内的访问冲突,我们没有该模块的符号或源代码。调用堆栈看起来不太可能:

0:000> kv
ChildEBP RetAddr  Args to Child             
WARNING: Stack unwind information not available. Following frames may be wrong.
0028fcec 74ba339a 7efde000 0028fd38 77479ed2
  HelperLibrary+0x1014
0028fcf8 77479ed2 7efde000 776a5346 00000000
  kernel32!BaseThreadInitThunk+0xe (FPO: [1,0,0])
0028fd38 77479ea5 011212b2 7efde000 00000000
  ntdll!__RtlUserThreadStart+0x70 (FPO: [SEH])
0028fd50 00000000 011212b2 7efde000 00000000
  ntdll!_RtlUserThreadStart+0x1b (FPO: [2,2,0])

除了HelperLibrary+0x1014之外,这里没有其他真正的帧,但是我们非常确定堆栈上应该还有其他代码,比如应用程序的主函数
要从这个堆栈重建某些内容,您需要了解谁调用了HelperLibrary+0x1014,即使您没有准确的符号。通常,这是一个遍历EBP引用的问题,但是如果它那么简单,调试器就已经做到了!

好吧,那么EBP怎么样了?

0:000> r ebp
ebp=0034fbfc
0:000> ln ebp
0:000> u ebp
0034fbfc 08fc            or      ah,bh
0034fbfe 3400            xor     al,0
0034fc00 9a33ba7400e0fd  call    FDE0:0074BA33
0034fc07 7e48            jle     0034fc51
0034fc09 fc              cld
0034fc0a 3400            xor     al,0
0034fc0c d29e477700e0    rcr     byte ptr [
  esi-1FFF88B9h],cl
0034fc12 fd              std

如果你没有注意到,这不是实际的代码,而是一堆被解释为指令的数据。EBP完全有可能被损坏,指向完全不相关的位置,但也有另一种可能:当前代码正在使用FPO。
什么是FPO?FPO(帧指针省略)是一种优化技术,而编译器使用EBP寄存器作为暂存值来存储杂项数据,就像任何其他通用寄存器一样。如何处理局部变量和函数参数?直接通过ESP。
换言之,当使用FPO(您可以使用/Oy编译开关启用它)时,编译器可以自由地避免使用以前的EBP值创建“真实”堆栈帧。没有从当前EBP值开始的堆栈帧的链接列表。如果没有FPO信息(出现在符号文件中,而我们没有这些信息),调试器将无法执行任何操作。
这使得我们需要反汇编HelperLibrary+0x1014并尝试手动找出它返回的位置。让我们看看HelperLibrary+0x1014(粗体的违规指令)附近:

0:000> u HelperLibrary+0x1014-0x14 L8
HelperLibrary+0x1000:
66951000 56              push    esi
66951001 ff157c209566    call    dword ptr [6695207c]
66951007 50              push    eax
66951008 c60061          mov     byte ptr [eax],61h
6695100b ff1578209566    call    dword ptr [66952078]
66951011 83c408          add     esp,8
66951014 c60661          mov     byte ptr [esi],61h
66951017 c3              ret

这看起来,确实,像一个FPO的栈帧-没有EBP被看到。但是,随后的ret指令会转到某个地方,因此我们可以查看ESP并在那里找到返回地址:

0:000> dps esp L1
0034fb9c  66951040 HelperLibrary+0x1040

好的,那么HelperLibrary+0x1040是什么?

0:000> u HelperLibrary+0x1040-0x20 LC
HelperLibrary+0x1020:
66951020 56              push    esi
66951021 8bf0            mov     esi,eax
66951023 56              push    esi
66951024 ff157c209566    call    dword ptr [6695207c]
6695102a 50              push    eax
6695102b c60061          mov     byte ptr [eax],61h
6695102e ff1578209566    call    dword ptr [66952078]
66951034 03742410        add     esi,dword ptr [esp+10h]
66951038 83c408          add     esp,8
6695103b e8c0ffffff      call    HelperLibrary+0x1000
66951040 5e              pop     esi
66951041 c3              ret

有点意思。此帧也不使用EBP,因此我们可以预期返回值为ESP+4(因为返回之前的pop指令)。但在这个函数中,我们如何计算ESP的值呢?好吧,假设上一个函数返回。它已经从堆栈中删除了四个字节(返回地址)。ESP的下一个值是ESP+4,我们需要再添加4个字节来解释“pop esi”指令。

0:000> dps esp+8 L1
0034fba4  6695106b HelperLibrary!ImportantFunction+0x1b

好吧!我们正在取得一些真正的进展,我们有一个非常小的偏移量,即使没有符号,ImportantFunction可能是一个导出函数,因此我们在DLL中有它的位置:

0:000> u HelperLibrary!ImportantFunction LD
HelperLibrary!ImportantFunction:
66951050 8b442404        mov     eax,dword ptr [esp+4]
66951054 85c0            test    eax,eax
66951056 7501            jne     HelperLibrary!ImportantFunction+0x9
66951058 c3              ret
66951059 837c240c00      cmp     dword ptr [esp+0Ch],0
6695105e 7e0e            jle     HelperLibrary!ImportantFunction+0x1e
66951060 8b4c2408        mov     ecx,dword ptr [esp+8]
66951064 49              dec     ecx
66951065 51              push    ecx
66951066 e8b5ffffff      call    HelperLibrary+0x1020
6695106b 83c404          add     esp,4
6695106e b801000000      mov     eax,1
66951073 c3              ret

这是另一个没有EBP使用痕迹的函数。注意,它有参数,并且它使用来自ESP的直接偏移量来访问这些参数,ESP是FPO的信号。这个函数返回到哪里?好吧,在上一个函数返回后,ESP已经在当前值的ESP+0xC处。ImportantFunction再添加四个字节,然后返回,因此我们需要查看ESP+0x10:

0:000> dps esp+0x10 L1
0034fbac  00ed100f MainApp!wmain+0xf

对!我们离开了动态链接库,回到符号区!因此,重建的堆栈如下所示:

HelperLibrary!…somefunction…
HelperLibrary!…someotherfunction…
HelperLibrary!ImportantFunction
MainApp!wmain

这些都不是调试器提供的。作为参考,这里是相同的调用堆栈与符号(其中包含FPO信息)

 

0:000> kv
ChildEBP RetAddr  Args to Child             
003dfee4 668e1040 00000001 668e106b 0000000f
 
HelperLibrary!AnotherHelperFunction+0x14 (FPO: [0,0,0])
003dfeec 668e106b 0000000f 010c100f 010c20f4
  HelperLibrary!HelperFunction+0x20 (FPO: [1,0,4])
003dfef4 010c100f 010c20f4 00000010 00000001
  HelperLibrary!ImportantFunction+0x1b (FPO: [3,0,0])
003dff04 010c1191 00000001 00771b78 00771c10
  MainApp!wmain+0xf (FPO: [2,0,0])
003dff48 74ba339a 7efde000 003dff94 77479ed2
  MainApp!__tmainCRTStartup+0x122 (FPO: [Non-Fpo])
003dff54 77479ed2 7efde000 777db3e9 00000000
  kernel32!BaseThreadInitThunk+0xe (FPO: [1,0,0])
003dff94 77479ea5 010c12b2 7efde000 00000000
  ntdll!__RtlUserThreadStart+0x70 (FPO: [SEH])
003dffac 00000000 010c12b2 7efde000 00000000
  ntdll!_RtlUserThreadStart+0x1b (FPO: [2,2,0])

标签: none

添加新评论