Win32调试API第二部分

理论:
上一章我们学习了如何加载被调试的进程，以及如何处理进程中发生的事件。为了实用，我们的程序要有修改被调试程序的能力。为此有几个API函数。

ReadProcessMemory这个函数允许你读取指定进程的内存。函数的原型如下:
ReadProcessMemory Protohprocess:DWORD，LPBaseAddress: DWORD，LPBuffer: DWORD，NSize: DWORD，LPNumberOfBytesRead: DWORD。

要读取的hProcess的句柄。
lpBaseAddress目标进程中要读取的内存的起始地址。例如，如果您想从目标进程中的地址401000h读取4个字节，则该参数值应该设置为401000h。
lpBuffer接收缓冲区地址
nsize要读取的字节数。
lpNumberOfBytesRead记录实际读取的字节数的变量地址。如果不在乎这个值，就填NULL。

WriteProcessMemory是与ReadProcessMemory对应的函数，通过它可以写入目标进程的内存。其参数与ReadProcessMemory相同。
理解接下来的两个功能需要一些关于流程上下文的背景知识。在像Windows这样的多任务操作系统中，可能会同时运行几个程序。Windows为每个线程分配一个时间片。当时间片结束时，Windows将冻结当前线程，并切换到下一个有优先级的线程。在切换之前，Windows会保存当前进程的寄存器内容，这样当线程再次恢复运行时，Windows就可以还原上一次线程运行的*环境*。保存的寄存器内容总是被称为进程上下文。
现在我们回到正题。当调试事件发生时，Windows会暂停被调试的进程并保存其进程上下文。因为流程被挂起，所以我们可以确定它的流程上下文内容将保持不变。GetThreadContext可用于获取流程上下文内容，也可用于修改流程上下文内容。
这两个功能极其强大。有了它们，你将对被调试的进程拥有类似VxD的能力:比如，改变它的寄存器的内容，在被调试的程序恢复运行之前，这些值将被写回寄存器。在进程上下文中所做的任何更改都将反映在被调试的程序中。想象一下:你甚至可以改变eip寄存器的内容，这样你就可以让程序在任何你想运行的地方运行！正常情况下是不可能这样做的。

GetThreadContext proto hThread:DWORD，lpContext:DWORD

Htread你要获取上下文的线程句柄
当lpcontext函数成功返回时用来保存上下文内容的结构指针。

SetThreadContext参数相同。让我们来看看上下文的结构:

上下文结构

ContextFlags dd？
；-
；当ContextFlags包含CONTEXT_DEBUG_REGISTERS时，返回本节
；-
iDr0 dd？
iDr1 dd？
iDr2 dd？
iDr3 dd？
iDr6 dd？
iDr7 dd？

；-
；当ContextFlags包含CONTEXT_FLOATING_POINT时，返回本节
；-

FloatSave浮动_保存_区域

；-
；当ContextFlags包含CONTEXT_SEGMENTS时，返回本节
；-
regGs dd？
regFs dd？
regEs dd？
regDs dd？

；-
；当ContextFlags包含CONTEXT_INTEGER时，返回本节
；-
regEdi dd？
regEsi dd？
regEbx dd？
regEdx dd？
regEcx dd？
regEax dd？

；-
；当ContextFlags包含CONTEXT_CONTROL时，返回本节
；-
regEbp dd？
regEip dd？
regCs dd？
regFlag dd？
regEsp dd？
regSs dd？

；-
；当ContextFlags包含CONTEXT_EXTENDED_REGISTERS时，返回本节
；-
extended registers db MAXIMUM _ SUPPORTED _ EXTENSION dup(？)CONTEXT ENDS
可以看出，这个结构中的成员是对实际处理器的寄存器的模仿。在使用这个结构之前，指定哪些寄存器组用于在ContextFlags中读写。要访问所有寄存器，可以将ContextFlags设置为CONTEXT_FULL。或者只访问regebp、regeip、regcs、regflag、regsp或regSs，并将ContextFlags设置为CONTEXT_CONTROL