關於偵錯程式中int3斷點引發異常的思考

int3斷點是利用0xcc指令實現的，cpu在執行0xcc指令時會引發斷點異常偵錯程式會捕捉這個異常。

int3斷點引發的異常屬於陷阱型異常，在執行完0xcc指令後eip指向下一條指令。但是系統對int3有特殊處理，當異常第一次分發時如果偵錯程式沒有處理那麼第二次異常分發之前系統會令eip-1。

下面寫個除錯程式來看一下。

#include
#include
using namespace std;
int flag =0;
//標誌是第一次斷點異常，還是第二次斷點異常
intmain()
; cout<<
"請輸入需要除錯的目標程式的路徑："
; cin>>a;
process_information pi;
//接受新程序的一些有關資訊
startupinfo si;
//指定新程序的主窗體如何顯示
debug_event devent;
//訊息事件
context stcontext;
//執行緒資訊塊
getstartupinfo
(&si)
;createprocessa
( a,
null
,null
,null
, false,
// 不可繼承
debug_only_this_process | debug_process,
// 除錯模式啟動 
null
,null
,&si,
&pi )
; cout<<
"建立程序成功"
<
while
(true)
if(devent.u.exception.dwfirstchance ==0)
//第二次異常分發
break;}
break;}
}if(flag ==1)
//如果是第一次碰見int3斷點異常，我們不處理他，讓他直接繼續進行第二次異常分發
continuedebugevent
(devent.dwprocessid, devent.dwthreadid, dbg_exception_not_handled)
;else
//如果是第二次碰見int3斷點異常或者是其他除錯事件我們直接返回讓程式繼續執行
}return0;
}

將乙個不存在異常處理的程式第一條指令變為int3指令。

用上方程式作為例子進行除錯，因為我們在第二次異常分發的時候返回dbg_continue來讓系統認為我們處理了異常所以eip又會指向int3指令處，至此以後一直迴圈產生異常

我們把剛才的例子程式在od中執行並設定int3異常不交給程式處理

執行程式發現eip指向int3的下一條指令，這說明od在int3異常第一次分發時因為eip指向了下一條指令，這時od返回dbg_continue意思是異常不交給程式處理直接返回。

如果設定忽略int3異常，即int3異常傳遞給程式處理。

因為程式沒有異常處理所以第一次異常傳給程式後，異常又會進行二次分發。我們執行程式發現eip依然指向int3指令處，繼續執行發現程式依然指向int3處，這說明od預設第二次異常返回dbg_continue然後一直迴圈產生int異常（和我們文章開始寫的那個除錯程式一樣）。

如果第二次異常時od沒有返回dbg_continue來向系統說明異常已處理，而返回dbg_exception_not_handled的話異常將不會繼續分發，程式將會被終止執行。（異常傳到頂層異常處理處，執行了預設的異常處理函式結束執行）

我們把文章開始的偵錯程式修改一下，把讓第二次異常處理時返回dbg_exception_not_handled。

if (flag ==1) //如果是第一次碰見int3斷點異常，我們不處理他，讓他直接繼續進行第二次異常分發 continuedebugevent (devent.dwprocessid, devent.dwthreadid, dbg_exception_not_handled) ;else //如果是第二次碰見int3斷點異常或者是其他除錯事件我們直接返回讓程式繼續執行

再次拿原來的那個程式當例子進行除錯，我們發現在第二次異常偵錯程式返回dbg_exception_not_handled後除錯程式結束執行。

開始除錯前

開始除錯後，異常第二次分發後異常沒有繼續分發，並且程式結束執行

關於偵錯程式中int3斷點引發異常的思考

int 3 斷點原理

斷點的本質 INT 3

INT 3 異常反除錯

關於偵錯程式中int3斷點引發異常的思考

int 3 斷點原理

斷點的本質 INT 3

INT 3 異常反除錯

相關推薦