第二節 反跟蹤技術
1、Anti-Debug
1.MeltICE子類型
類型:檢測SoftICE、TRW2000
平臺:Windows9x、Windows NT
原理:用CreateFileA( )或_lopen( )函數試圖獲得SoftICE的驅動程序"\\.\SICE"(Windows9X版本)、"\\.\SIWDEBUG"、"\\.\NTICE"(Windows NT版本)、"\\.\SIWVID"等的句柄,如果成功則說明SoftICE駐留在內存中。
2.VWIN32_Int41Dispatch子類型
類型:檢測SoftICE
平臺:Windows9x
原理:VWIN32.VxD(其VxD ID為0x002A)提供一個名為VWIN32_Int41Dispatch的VxD service(其service ID為0x002A),系統內核使用此服務來與系統級調試器如WinDBG、SoftICE等進行通信。其中0x4F號子功能是用來查詢調試器是否已經駐留內存并能否處理保護模式程序,如果是的話則調試器應返回0xF386。
3.給SoftICE發送命令
類型:檢測SoftICE
平臺:Windows9x、Windows NT
原理:通過調試中斷int 3給SoftICE發送命令讓其執行,其中SI和DI寄存器中放的分別是固定值0x4647("FG")和0x4A4D("JM")。AX中存放的是子功能號,值為0x0911則表示讓SoftICE執行命令,此時DX指向一個命令字符串如"HBOOT"等。AX還可以為其它子功能號,比如讓SoftICE修改斷點設置等。
4、BoundsChecker后門
類型:檢測SoftICE
平臺:Windows9x、Windows NT
原理:這是SoftICE為BoundsChecker留的一個公開的接口,入口參數EBP = 0x4243484B(即"BCHK"),AL =4,如果SoftICE在內存中則應返回AL = 0。
這種方法一般也要結合SEH?(結構異常處理)來實現,否則當SoftICE不存在時就會引起非法操作。
5.ICECream子類型
類型:檢測SoftICE、TRW2000
平臺:Windows9x
原理:調試器駐留后修改INT 1和INT 3的入口,指向它自己的處理程序,所以入口高位偏移與其他中斷不同。其他所有中斷入口高位偏移都相同。
6.INT 68h子類型
類型:檢測SoftICE
平臺:Windows9x
原理:
MOV AH, 43h
INT 68h
CMP AX, 0F386h ;檢測此處是否被調試器設置0F386h
JZ SoftICE_is_here
7.搜索特征串
類型:檢測SoftICE
平臺:Windows9x
原理:通過在內存中搜索SoftICE的特征串來發現SoftICE,這一般要結合SEH一起使用,以防止引起內存保護出錯而使得程序被終止。這種方法在DOS下是可行的。由于Windows95之后的操作系統中的每個ring 3進程的地址空間是獨立的,使得這種方法受到限制。比如在內存中搜索"WINICE.BR"。
8.IsDebuggerPresent子類型
類型:檢測SoftICE
平臺:Windows NT
原理:調用kernel32.dll輸出的函數IsDebuggerPresent()來檢測是否有調試器存在。這個函數只能檢查使用Debug API來跟蹤程序的調試器,無法檢測SoftICE之類的系統級調試器。
2、Anti-靜態分析
1.死循環語句
類型:對付W32Dasm
平臺:Windows9x 、Windows NT
原理:下面是故意在程序中插入的一個死循環,可能會使W32Dasm的某些版本停止響應:
0401000 JMP 00401005
……
00401005 JMP 00401000
對策:W32Dasm進入死循環后,用Bpx hmempcy設斷,來到死循環代碼處,將其跳出死循環,或用IDA來反匯編。
2.利用花指令
花指令是對付靜態分析的重要手段。以下是一段匯編源程序:
|
此時把源程序進行編譯,然后用W32Dasm進行反匯編,得到的反匯編結果完全正常。接著我們將上述源程序作如下修改:
|
再把源程序進行編譯,然后用W32Dasm進行反匯編,來看一下反匯編后的結果:
| :00401000 83F001 :00401003 83C002 :00401006 7503 :00401008 7401 :0040100A E883F00383 :0040100F C00483F0 |
xor eax, 00000001 add eax, 00000002 jne 0040100B je 0040100B call 83440092 rol byte ptr [ebx+4*eax], F0 |
結果令人很吃驚,會發現W32Dasm反匯編的結果和事先寫的匯編指令不一樣,從反匯編的結果中已經無法理解程序的"真實"的功能了,W32Dasm給出了一個意想不到的答案。 這是因為上述改動是為了在W32Dasm的反匯編工作中做點手腳,從而使得它犯下錯誤。那么W32Dasm為什么會因此而犯下這樣的錯誤呢?
不同的機器指令包含的字節數并不相同,有的是單字節指令,有的是多字節指令。對于多字節指令來說,反匯編軟件需要確定指令的第一個字節的起始位置,也就是操作碼的位置,這樣才能正確地反匯編這條指令,否則它就可能反匯編成另外一條指令了。 如果在程序中加入一些無用的字節來干擾反匯編軟件的判斷,從而使得它錯誤地確定指令的起始位置,那么也就達到了干擾W32Dasm反匯編工作的目的。
通過前面的介紹,知道由于"無用的字節"干擾了W32Dasm對指令起始位置的判斷,從而導致反匯編的錯誤結果,所以如果能讓W32Dasm正確地識別出指令起始位置,也就達到了去除花指令的目的了。比如可以把那些無用的字節都替換成單字節指令,最常見的一種替換方法是把無用的字節替換成 NOP 指令,即十六進制數 90。
| 共7頁: 1 [2] [3] [4] [5] [6] [7] 下一頁 | ||
|


