Win32调试API原理(3)

在被调试的线程中发生了一个异常。如果指定了DBG_CONTINUE，线程将忽略它自己的异常处理部分并继续执行。在这种情况下，程序必须在以DBG_CONTINUE恢复线程之前检查并处理异常，否则异常将不断地发生，直至程序被系统终止。如果指定了

DBG_EXCEPTION_NOT_HANDLED值，就是告诉Windows：程序并不处理异常。Windows将使用被调试线程的默认异常处理函数来处理异常。这一般发生在什么时候呢？在进程被载入后发生的第一个EXCEPTION_DEBUG_EVENT，我们必须以DBG_CONTINUE为标志继续，在程序中如果调用了DebugBreak函数，或者插入INT3设置断点成功，并将内存恢复后，都应该使用DBG_CONTINUE为标志继续。如果在程序中发生了不确定的异常，特别是调试带壳程序的时候，多半是由于外壳的SEH引起的，此时应该以

DBG_EXCEPTION_NOT_HANDLED为标志继续，以便让被调试程序本身的异常处理机制来处理。

在发生其他调试事件时，可以利用类似的结构取得线程、进程所调用的DLL或其他一些事物的信息集合。

3.1.6 线程环境详解

在WIN32系统中，进程的概念实际包含了它的私有地址空间、代码、数据和一个主线程。每个进程都有一个最初的主线程，通过这个主线程可以在以后创建在同一地址空间中运行的其他线程。和一般说法不同的是进程并不执行代码，真正执行代码的是线程。每个线程共同分享相同的地址空间和相同的系统资源，但是它们各自又有不同的执行环境，这到底如何理解呢？Windows是一个多任务多线程的操作系统，在系统的同一时间里看似运行着多个线程，但事实并非如此。Windows分配给每个线程一小段时间片，这段时间结束后，Windows将冻结当前线程并切换到下一个具有最高优先级的线程。在切换之前，Windows将把当前线程执行状态保存到一个名为CONTEXT的结构中。这个环境包含下面几部分： ● 线程执行所用寄存器 ● 系统堆栈和用户堆栈

● 线程所用的描述符表等其他状态信息

这样当该线程再次恢复运行时，Windows就可以恢复最近一次线程运行的“环境”，好像中间什么都没有发生一样。

CONTEXT结构包含了特定处理器的寄存器数据，系统使用CONTEXT结构执行各种内部操作。由于此结构是依赖于硬件的，所以在X86，Alpha等不同的系统上，此结构是不同的。下面是X86系统中此结构的构成情况：

view plain

1. typedef struct _CONTEXT { 2. DWORD ContextFlags; 3. DWORD Dr0;

4. DWORD Dr1; 5. DWORD Dr2; 6. DWORD Dr3; 7. DWORD Dr6; 8. DWORD Dr7;

9. FLOATING_SAVE_AREA FloatSave; 10. DWORD SegGs; 11. DWORD SegFs; 12. DWORD SegEs; 13. DWORD SegDs; 14. DWORD Edi; 15. DWORD Esi; 16. DWORD Ebx; 17. DWORD Edx; 18. DWORD Ecx; 19. DWORD Eax; 20. DWORD Ebp; 21. DWORD Eip;

22. DWORD SegCs; 23. DWORD EFlags; 24. DWORD Esp; 25. DWORD SegSs; 26. } CONTEXT;

其中的FloatSave是指向FLOATING_SAVE_AREA结构的指针，FLOATING_ SAVE_AREA结构定义如下：

view plain

1. typedef struct _FLOATING_SAVE_AREA { 2. DWORD ControlWord; 3. DWORD StatusWord; 4. DWORD TagWord; 5. DWORD ErrorOffset; 6. DWORD ErrorSelector; 7. DWORD DataOffset; 8. DWORD DataSelector;

9. BYTE RegisterArea[SIZE_OF_80387_REGISTERS]; 10. DWORD Cr0NpxState; 11. } FLOATING_SAVE_AREA;

另外，其中的ContextFlags字段用于控制GetThreadContext和SetThreadContext处理那些环境信息。它的定义如下：

CONTEXT_CONTROL ContextFlags包含此标志时处理Ebp,Eip,Cs, Flages,Esp,Ss

CONTEXT_INTEGER ContextFlags包含此标志时处理 Edi,Esi,Ebx,Edx,Ecx,Eax

CONTEXT_SEGMENTS ContextFlags包含此标志时处理 GS,FS,ES,DS

CONTEXT_FLOATING_POINT ContextFlags包含此标志时处理 FLOATING_SAVE_AREA FloatSave

CONTEXT_DEBUG_REGISTERS ContextFlags包含此标志时处理 Dr0,Dr1,Dr2,Dr3,Dr6,Dr7

CONTEXT_FULL = (CONTEXT_CONTROL | CONTEXT_INTEGER | CONTEXT_SEGMENTS)

为什么在CONTEXT_FULL中不包含CONTEXT_DEBUG_REGISTERS和

CONTEXT_FLOATING_POINT呢？或许这只能去问微软，不过这看上去确实有点不合情理。

Windows实际上允许查看线程内核对象的内部情况，以便抓取它的当前一组CPU寄存器。若要进行这项操作，可以调用GetThreadContext和SetThreadContext函数。 GetThreadContext用来获取指定线程的执行环境，语法如下：

语法：BOOL GetThreadContext(HANDLE hThread, LPCONTEXT lpContext ) 参数：

hThread HANDLE：欲获取执行环境的线程的句柄 lpContext LPCONTEXT：指向CONTEXT结构的指针

要注意的是，在使用GetThreadContext函数之前，必须先将ContextFlags初始化为适当的标志，指明想要收回哪些寄存器，并将该结构的地址传递给GetThreadContext函数。例如设置的标志是CONTEXT_CONTROL，只返回Ebp，Eip，Cs，Flages，Esp，Ss这些值。

SetThreadContext用来设置指定线程的执行环境，语法如下：

语法：BOOL SetThreadContext(HANDLE hThread, LPCONTEXT lpContext ) 参数：

hThread HANDLE：欲设置执行环境的线程的句柄 lpContext LPCONTEXT：指向CONTEXT结构的指针

与GetThreadContext函数相类似，SetThreadContext函数也是通过ContextFlags的值来控制哪些数据将被恢复。

这两个函数威力非凡。有了它们，对于被调试进程你就有了上帝的能力。如果改变其寄存器内容，那么在被调试程序恢复运行前，这些值将会写回寄存器中。在进程环境中所做的任何

改动，都将反映到被调试程序中。想像一下：甚至可以改变EIP寄存器的内容，这样就可以让程序运行到想要的任何地方! 在正常情况下是不可能做到这一点的。

在调用GetThreadContext函数之前，应该调用SuspendThread函数，否则线程可能被调度，而且线程的环境可能与收回的不同。一个线程实际上有两个环境：一个是用户方式，一个是内核方式。GetThreadContext函数只能返回线程的用户方式环境。如果调用SuspendThread函数来停止线程的运行，但该线程目前正在用内核方式运行，那么，即使SuspendThread实际上尚未暂停该线程的运行，它的用户方式仍然处于稳定状态。线程在恢复用户方式之前，无法执行更多的用户方式代码，因此可以放心地将线程视为处于暂停状态，GetThreadContext函数将能正常运行。

所以，正确的做法应该是先利用SuspendThread函数暂停一个线程，当设置好环境后再利用ResumeThread函数来恢复它。但要注意的是：ResumeThread函数并不能保证线程真地继续执行，为什么呢？每一个线程 …… 此处隐藏：3736字，全部文档内容请下载后查看。喜欢就下载吧 ……