跟踪，跟踪，总是跟踪！程序中肯定有比跟踪更好玩的事情！我写了个跟踪调试器。。。
这句话可有似曾相识的感觉，如果是说明你还小，或者已老了。

言归正传，逆向大多的时候是确实很枯燥。上一篇说到过掉游戏保护，在调试驱动时，其实有个简单而且带源码的调试器还是很有必要的。

R3应用层的调试其实没多少深度，操作系统内核会将异常发给调试器，调试会用一个线程来处理异常，这里简单的说一下一个调试器的核心流程，具体的大家自己找资料了：

先定义一个扩展的调试事件，在分发异常时传递给异常处理程序。

struct DEBUG_EVENT_EX : public DEBUG_EVENT
{
 CBreakPointMap  _BreakPointMap;    // 软件断点
 CDebugRegistersMap _DebugRegistersMap;   // 硬件断点
 
 //
 // 更多自定义数据
 //
 ......
};

用一个线程将程序异常分发给处理程序。这个是线程的核心部分伪代码，并不是入口函数，CreateProcess，DebugActiveProcess有不同的入口函数，但最后都会调用这个核心函数。这个线程用 WaitForDebugEvent 侦听异常，然后调用OnDebugEvent，根据返回值再调用 ContinueDebugEvent 函数。

DWORD WINAPI DebugEventThread( CDbgDocument* pDocument, PROCESS_INFORMATION pi )
{
 DEBUG_EVENT_EX   dbgex;
 while (WaitForDebugEvent(&dbgex, INFINITE) && (dbgex.dwDebugEventCode != EXIT_PROCESS_DEBUG_EVENT))
 {
  DWORD dwContinueStatus = pDocument->OnDebugEvent();
  ontinueDebugEvent(dbgex.dwProcessId, dbgex.dwThreadId, dwContinueStatus );
 }

 CloseHandle(pi.hProcess);
 CloseHandle(pi.hThread);

 return 0;
};

创建调试进程并起动线程的相关代码：

附加调试到进程并起动线程的相关代码：

这儿贴出我的调试器的调试核心线程以作参考，跟踪的核心部也在这里面。

好了，这儿就不展开如何做一个调试器，进入正题，谈谈如何跟踪，跟踪并不神秘，OD的RunTrace就是一个跟踪，简单而言就是自动单步，然后把寄存器记录下来，但是如何把结果组织起来就有讲究了。
我的调试器跟踪用以下几种方法实现：

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！