最近在看《軟件調試》這本書，為了加深理解，就到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的核心內容就做完了，剩下一堆跟用戶交互啥的事情沒有處理。即使作為原型它也還是有不少需要解決的問題，比如整個過程中，觸發異常的線程都沒有采取措施讓其他線程也掛起等。考慮到原作者似乎也沒什么動力繼續更新了，我看這些問題被解決的可能性也很渺茫了吧。