-
-
[求助]有关于第8章，调试SEH的部分
-
发表于: 2019-6-22 16:54
-
------------------------------------------------------------------------------------------------------------
问题在：
p322 第7行( 8.2.3里 )
上面写道说：可以看到，此时栈顶就是_EXCEPTION_POINTERS结构
-------------------------------------------------------------------------------------------------------------
我想请问一下，为什么下断点在KiUserExceptionDespatcher入口
并且esp的内容开始就是_EXCEPTION_POINTERS 结构
是如何得知的？
另外，在我本机调试的CONTEXT位置为什么会不一样，如图所示：
这是我dt指令后 _EXCEPTION_RECORD的数据结构：
按书上说的，我的EXCEPTION_RECORD大小应该要是
0x14 + 2*sizeof( ULONG ) = 0x1C
我的ExceptionRecord + 0x1C
= 0019fa48 + 0x1C = 0019fa64
结果我的CONTEXT 跑去 0019fa98 了
虽然dd esp就可以看到位于0019fa48里的值也这么显示
用C++计算器算出来的结果是0x50
所以得到的 0019fa48 + 0x50 = 0019fa98是正确的无误
但不知为何跟书上的不一样，是因为ULONG大小的关系吗？
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
最后于 2019-6-22 18:05
被Tonybeartony编辑
，原因：
|
|
|---|---|
|
|
|
|
|
第一个问题，为什么下断点在KiUserExceptionDispatcher?
还是例子中的这个程序，它有一段异常处理程序： ;异常处理回调函数 myHandler proc C uses ebx esi edi pExcept,pFrame,pContext,pDispatch invoke MessageBox,0,addr messuc,addr szTit,MB_APPLMODAL or MB_OK invoke ExitProcess,0 myHandler endp 用Windbg载入后，在MessageBoxA函数下断点,然后g命令开始运行，此时第一次会因为内存访问异常中断到调试器，输入gn命令让调试器忽略这个异常，让程序自己去处理，它就会调用myHandler，并调用到MessageBoxA函数，此时用kvn命令查看栈回调，是这个样子的： 0:000> kvn # ChildEBP RetAddr Args to Child 00 0018f9bc 00401019 00000000 00403003 00403000 USER32!MessageBoxA (FPO: [Non-Fpo]) WARNING: Stack unwind information not available. Following frames may be wrong. 01 0018f9e0 7ded34c1 0018facc 0018ff80 0018fb1c image00400000+0x1019 02 0018fa04 7ded3493 0018facc 0018ff80 0018fb1c ntdll!ExecuteHandler2+0x26 (FPO: [Uses EBP] [5,3,1]) 03 0018fa28 7ded3434 0018facc 0018ff80 0018fb1c ntdll!ExecuteHandler+0x24 (FPO: [5,0,3]) 04 0018fab4 7de80163 0018facc 0018fb1c 0018facc ntdll!RtlDispatchException+0x127 (FPO: [Non-Fpo]) 05 0018fab4 00000000 0018facc 0018fb1c 0018facc ntdll!KiUserExceptionDispatcher+0xf (FPO: [2,0,0]) (CONTEXT @ 00000008) 从栈中的函数名字可以大概看得出来，是系统模块ntdll在执行异常处理函数，最底层的函数就是KiUserExceptionDispatcher，是用户部分异常处理函数执行的第一步，所以在这里下断点。该函数的原型可以在Wrk中找到（研究Win系统必看资料）：  函数原型可以看得很清楚，当执行到这个函数时，栈顶就是它的两个参数。对于一般函数来说，在函数头中断的时候，栈顶肯定是返回地址，然后才是参数，但是由于这个函数是从内核回调回来的， 不同于一般的普通函数调用，所以栈顶直接就是参数。 关于你的第二个问题，
CONTEXT位置为什么不一样的问题，我看了一下，这个应该是操作系统版本不同导致的区别。在我写这一章时，我是在Win7系统上调试的，相应的结果在WinXP上也是一样的。EXCEPTION_RECORD结构的定义是这样的： typedef struct _EXCEPTION_RECORD {
DWORD ExceptionCode;
DWORD ExceptionFlags;
struct _EXCEPTION_RECORD *ExceptionRecord;
PVOID ExceptionAddress;
DWORD NumberParameters;
ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];
} EXCEPTION_RECORD;它的最后一个成员，定义是ULONG_PTR ExceptionInformation[15]，在32位系统上，ULONG_PTR和ULONG一样都是4字节，最大是15个，你用Windbg看到的大小是0x50并没有错，实际上0x50 = 0x14 + 4*15。在Win7系统上，系统在构造
EXCEPTION_RECORD结构时是按需分配内存大小的，在本例程序中， 系统并没有使用全部的15个元素，实际使用的NumberParameters是2，也就是用了2个元素，所以计算它实际使用的空间是0x14 + 4*2 = 0x1C。这种结构的最后一个元素是变长的现象在Windows中非常常见。而在你的系统中，虽然
NumberParameters也是2，但是系统分配了全部的空间（中间有大片的0），所以此时
EXCEPTION_RECORD结构 的大小是完整的大小0x50，而
0019fa48 + 0x50 = 0019fa98 ，所以实际上跟书上讲的是一致的，它们在内存中的布局仍然是紧挨着的。所以，我猜你的系统肯定不是Win7。 建议以后再提类似的问题，把自己的操作系统版本信息一并报上来，系统版本的差别确实会造成这样的现象，这样也方便别人进行分析。书上也很难把所有的情况都讲到，都是深入一两个现象讲原理，理解了原理，得出以上结论并上难。 |
|
|
好的，非常谢谢您这么详细的解说 下次我会附上我的版本相关信息的 我的操作系统是Win10 我再来回去研究研究！ |
