Isaiah大牛提及了1下,能不能自己构造一套调试的框架呢？不依赖于操作系统的提供的机制。比如调试事件。
于是偶发1个讨论帖子,看看有无大牛对这些东西感兴趣,指点1下

我们的目的.一些加壳软件使用自调试,比如arm的copymem2,我们不能方便的调试子进程,因为调试端口已经被占用,OllyDbg不能attach,我们希望实现1个自己的调试器注入进去,实现windbg类似的入侵调试功能,我的想法的制作1个开源debuger计划,欢迎大家帮助开发完善这个小工具,这个小工具并不打算替代OllyDbg,仅仅是在某些OllyDbg一时无法使用的时候作为临时debuger使用

SoftICE是完全自己实现了调试过程
OllyDbg则是利用Platform SDK和最新的DbgHelp.dll提供的API作为引擎写的debugger，也即是的debugger的Host端
其实CPU为Debug提供了强力的支持，比如设单步跟踪的标志,还有Drx机制
我们来看看
OllyDbg使用了下面的一系列API
================
        GetThreadContext
        SetThreadContext
        DebugActiveProcess
        ReadProcessMemory
        WriteProcessMemory
        CreateProcess with DEBUG_PROCESS flag
        WaitForDebugEvent
================
       其中一些API不是调试特有的,我们可以继续使用
我们需要修正的是DebugActiveProcess和WaitForDebugEvent
简单起见,我们只模拟attach过程
       一个调试器,当DebugActiveProcess上一个进程以后,被调试进程主线程被挂起,这种状况将持续到我们的程序调用WaitForDebugEvent为止

背景知识: user-mode debuger工作流程
<1>debuger创建一个新进程，或attach一个正在运行的进程。我们称这个进程为B。
<2>debuger等待进程B产生debug事件
<3>进程B产生debug事件，发送消息给debuger，进程挂起，等待debuger指令。
<3>debuger处理debug事件，发送消息给进程B。
<4>进程B接受debuger发送的消息，进程复苏。
<5>循环2-4
消息传递是通过lpc port来进行的，流程如下所示：
debuger <--> kernel <--> process B

上面所说的消息结构如下：
typedef struct _DEBUG_MESSAGE
{
PORT_MESSAGE PORT_MSG;
DEBUG_EVENT DebugEvent;
}DEBUG_MESSAGE, *PDEBUG_MESSAGE;

typedef struct _PORT_MESSAGE
{
USHORT DataSize;//数据长度
USHORT MessageSize;//总长度
USHORT MessageType;
USHORT DataInfoOffset;
CLIENT_ID ClientId;
ULONG MessageId;
ULONG SectionSize;
//UCHAR Data[];
}PORT_MESSAGE, *PPORT_MESSAGE;

在\Microsoft SDK\samples\winbase\Debug目录下有几个简单的user-mode debuger的源代码,
大家可以参考一下。

背景知识:
EXCEPTION_DEBUG_EVENT：产生调试例外
CRATE_THREAD_DEBUG_EVENT：新的线程产生
CREATE_PROCESS_DEBUG_EVENT：新的进程产生。注：在DEBUG_ONLY_THIS_PROCESS时只有一次，
在DEBUG_PROCESS时如果该程序启动了子进程就可能有多次。
EXIT_THREAD_DEBUG_EVENT：一个线程运行中止
EXIT_PROCESS_DEBUG_EVENT：一个进程中止。注：在DEBUG_ONLY_THIS_PROCESS时只有一次，
在DEBUG_PROCESS可能有多次。
LOAD_DLL_DEBUG_EVENT：一个DLL模块被载入。
UNLOAD_DLL_DEBUG_EVENT：一个DLL模块被卸载。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课