一个处于原型期的debugger的简单分析

最近在看《软件调试》这本书，为了加深理解，就到google code里搜了一个叫opendbg的开源debugger看看代码。这个项目的最后更新日期是08年8月，似乎又烂尾了，这种烂尾开源项目真是数不胜数，不过幸好opendbg的整体架构已经搭出来了。

让我们直接进ring0，看作为一个debugger需要在内核里做什么事情
要进ring0，一定要写driver，driver的入口多半是DriverEntry，果然一搜就搜到在src\kernel\sys里有DriverEntry函数。这个函数非常简单，就做了三件事情：先后调用init_dbg_item，init_debug，和init_syscall函数。init_dbg_item函数初始化了一个dbg_item_list，所谓的dbg_item是用来替代windows中原有的debug port和debug消息循环的，open dbg的作者似乎想完全脱离windows的原生debug支持，全部重新写一套。i

nit_debug调用了几次set_sdt_hook函数，替换了几个系统调用，把ZwTerminateProcess，ZwCreateThread和KiDispatchException函数hook成自己的函数。我们知道断点，单步等都是走异常这条路的，再加上线程的创建和销毁，基本上常有的时间都能被捕获到了，但是没见到有fake create等的事件，所以该opendbg应该是不支持attach to process功能的。

set_sdt_hook函数非常简单，因为你已经在ring0了，在这个空间里只有想不到的，没有做不了的，好的坏的什么事情都能做。让我们看看set_sdt_hook都干了些什么：

void set_sdt_hook(int num, void *np, void *op)
{
	u64 cr0;

	cr0          =  mem_open();
	ppv(op)[0]   = SYSCALL(num);
	SYSCALL(num) = np;
	mem_close(cr0);
}

关键一步就是把系统调用表里的num号指定的项替换成参数np，替换后，相应的系统调用就会走np指定的那条路。

SYSCALL是一个宏，原型如下

#define SYSCALL(function) KeServiceDescriptorTable->ntoskrnl.ServiceTable[function]

KeServiceDescriptorTable是系统的一个全局变量，指向系统调用表。SYSCALL(num) = np; 就是替换的关键语句。

hook住关键系统调用后，debug引擎就能开始正常运转了。比如debugee程序触发一个断点后，被替换掉的KiDispatchException就会被调用到，新的KiDispatchException函数检测是否是用户态程序触发的异常（也就是说该opendbg不支持内核调试），如果是便转入dbg_process_exception函数。

static
int dbg_process_exception(
	   PEXCEPTION_RECORD except_record,
	   BOOLEAN           first_chance
	   )
{
	dbg_item *debug   = NULL;
	int       handled = 0;
	u32       i, code = except_record->ExceptionCode;
	dbg_msg   msg;
	cont_dat  cont;

	do
	{
		if ( (debug = dbg_find_item(NULL, IoGetCurrentProcess())) == NULL ) {
			break;
		}

		/* check event mask */
		if ( (debug->filter.event_mask & DBG_EXCEPTION) == 0 ) {
			break;
		}

		/* check exception filters */
		for (i = 0; i < debug->filter.filtr_count; i++)
		{
			if ( (code >= debug->filter.filters[i].filtr_from) &&
				 (code <= debug->filter.filters[i].filtr_to) )
			{
				break;
			}
		}

		/* setup debug message */
		msg.process_id             = PsGetCurrentProcessId();
		msg.thread_id              = PsGetCurrentThreadId();
		msg.event_code             = DBG_EXCEPTION;
		msg.exception.first_chance = first_chance;

		/* copy exception record */
		fastcpy(
			&msg.exception.except_record, except_record, sizeof(EXCEPTION_RECORD)
			);

		/* send debug message and recive replay */
		if (channel_send_recv(debug->chan, &msg, &cont) == 0) {
			break;
		}

		if (cont.status & RES_CORRECT_FRAME)
		{
			/* correct exception record */
			fastcpy(
				except_record, &cont.new_record, sizeof(EXCEPTION_RECORD)
				);
		}

		if (cont.status & RES_CONTINUE) {
			handled = 1;
		}
	} while (0);

	if (debug != NULL) {
		dbg_deref_item(debug);
	}

	return handled;
}

dbg_process_exception函数首先寻找本线程上是否附着了debug_item，如果有，则说明自己正在被调试，于是便准备好一个dbg_item结构，往里边填充processid，threadid，event_type，first_chance等，然后调用channel_send_recv函数。channel_send_recv函数会一直等待直到debugger有回应让线程继续执行或者终止或者怎样。在此过程中，debugger程序可以利用ReadProcessMemory，WriteProcessMemory等一系列函数对debuggee程序进行监控，修改等。

至此，opendbg的核心内容就做完了，剩下一堆跟用户交互啥的事情没有处理。即使作为原型它也还是有不少需要解决的问题，比如整个过程中，触发异常的线程都没有采取措施让其他线程也挂起等。考虑到原作者似乎也没什么动力继续更新了，我看这些问题被解决的可能性也很渺茫了吧。