转自安焦
【相关文章:获取本机的本地上网IP地址】=====[ 1. 内容 ]============================================= 【扩展阅读:使用Cookie传递数据】
【扩展信息:在WEB程序中设置个性化,容错提示窗口】1. 内容 2. 介绍 3. 挂钩方法 3.1 运行前挂钩 3.2 运行时挂钩 3.2.1 使用iat挂钩本进程 3.2.2 改写入口点挂钩本进程 3.2.3 保存原始函数 3.2.4 挂钩其它进程 3.2.4.1 dll注入 3.2.4.2 独立的代码 3.2.4.3 原始修改 4. 结束语 =====[ 2. 介绍 ]==================================================== 这篇文章是有关在os windows下挂钩api函数的方法。所有例子都在基于nt技术的windows版本nt 4.0及以上有效(windows nt 4.0, windows 2000, windows xp)。可能在其它windows系统也会有效。 你应该比较熟悉windows下的进程、汇编器、pe文件结构与一些api函数,才能明白这篇文章里的内容。 这里使用"hooking api"这个术语表示对api的完全修改。当调用被挂钩的api时,我们的代码能立刻被执行。我将写下完全的挂钩过程。 =====[ 3. 挂钩方法 ]============================================== 一般来说我们的目的是用我们的代码取代一些函数里的代码。这些问题有时可以在进程运行前解决。这些大多数时候可以用我们运行的用户级进程来完成,目的可以是修改程序的行为。举个例子应用程序的破解,比方说有些程序会在启动时需要原光盘,我们想要不用光盘就启动它。如果我们修改获取驱动类型的函数我们就可以让程序从硬盘启动。 当我们挂钩系统进程时(比如说服务)这些不可能做到或者我们不打算这么做,或者在这个例子里我们不知道哪个进程才是目标。这时我们就要用到动态挂钩(在运行时挂钩)的技术。使用的例子有rootkit或者病毒里的反杀毒软件的技术。 =====[ 3.1 运行前挂钩 ]=========================================== 这里修改我们想要修改函数来自的物理模块(大多数时候是.exe或.dll)。在这里我们至少有3种可能的做法。 第一种可能是找到函数的入口点然后重写它的代码。这会因为函数的大小而受限制,但我们能动态加载其它一些模块(api loadlibrary),所以应该足够了。 内核函数(kernel32.dll)是通用的因为windows中每个进程都有这个模块的拷贝。另一个好处是如果我们知道哪些模块在某版本中会修改,我们可以在一些api如loadlibrarya中使用直接的指针。这是因为kernel模块在内存中地址在相同windows版本中是固定的。我们同样也能用动态加载的模块的作用。在这里它的初始化部分在加载进内存后立刻就运行。在新模块的初始化部分我们不受限制。 第二种可能是在模块中被代替的函数只是原函数的扩展。然后我们选择要么修改开始的5个字节为跳转指令或者改写iat。如果改为跳转指令,那么将会改变指令执行流程转为执行我们的代码。如果调用了iat记录被修改的函数,我们的代码能在调用结束后被执行。但模块的扩展没那么容易,因为我们必须注意dll首部。 下一个是修改整个模块。这意味着我们创建自己的模块版本,它能够加载原始的模块并调用原始的函数,当然我们对这个不感兴趣,但重要的函数都是被更新的。这种方法对于有的模块过大有几百个导出函数的很不方便。 =====[ 3.2 运行时挂钩 ]========================================== 在运行前挂钩通常都非常特殊,并且是在内部面向具体的应用程序(或模块)。如果我们更换了kernel32.dll或ntdll.dll里的函数(只在nt操作系统里),我们就能完美地做到在所有将要运行的进程中替换这个函数。但说来容易做起来却非常难,因为我们不但得考虑精确性与需要编写比较完善的新函数或新模块,但主要问题是只有将要运行的进程才能被挂钩(要挂钩所有进程只能重启电脑)。另一个问题是如何进入这些文件,因为nt操作系统保护了它们。比较好的解决方法在进程正在运行时挂钩。这需要更多的有关知识,但最后的结果相当不错。在运行中挂钩只对能够写入它们的内存的进程能成功。为了能写入它自己我们使用api函数writeprocessmemory。现在我们开始运行中挂钩我们的进程。 =====[ 3.2.1 使用iat挂钩本进程 ]=================================== 这里有很多种可能性。首先介绍如何用改写iat挂钩函数的方法。接下来这张图描述了pe文件的结构: +-------------------------------+ - offset 0 | ms dos标志("mz") 与 dos块 | +-------------------------------+ | pe 标志 ("pe") | +-------------------------------+ | .text | - 模块代码 | 程序代码 | | | +-------------------------------+ | .data | - 已初始化的(全局静态)数据 | 已初始化的数据 | | | +-------------------------------+ | .idata | - 导入函数的信息与数据 | 导入表 | | | +-------------------------------+ | .edata | - 导出函数的信息与数据 | 导出表 | | | +-------------------------------+ | 调试符号 | +-------------------------------+ 这里对我们比较重要的是.idata部分的导入地址表(iat)。这个部分包含了导入的相关信息与导入函数的地址。有一点很重要的是我们必须知道pe文件是如何创建的。当在编程语言里间接调用任意api(这意味着我们是用函数的名字来调用它,而不是用它的地址),编译器并不直接把调用连接到模块,而是用jmp指令连接调用到iat,iat在系统把进程调入内存时时会由进程载入器填满。这就是我们可以在两个不同版本的windows里使用相同的二进制代码的原因,虽然模块可能会加载到不同的地址。进程载入器会在程序代码里调用所使用的iat里填入直接跳转的jmp指令。所以我们能在iat里找到我们想要挂钩的指定函数,我们就能很容易改变那里的jmp指令并重定向代码到我们的地址。完成之后每次调用都会执行我们的代码了。这种方法的缺点是经常有很多函数要被挂钩(比方说如果我们要在搜索文件的api中改变程序的行为我们就得修改函数findfirstfile与findnextfile,但我们要知道这些函数都有ansi与wide版本,所以我们不得不修改findfirstfilea、findfirstfilew、findnextfilea与filenextfilew的iat地址。但还有其它类似的函数如findfirstfileexa与它的wide版本findfirstfileexw,也都是由前面提到的函数调用的。我们知道findfirstfilew调用findfirstfileexw,但这是直接调用,而不是使用iat。再比如说shellapi的函数shgetdesktopfolder也会直接调用findfirstfilww或findfirstfileexw)。如果我们能获得它们所有,结果就会很完美。 我们通过使用imagehlp.dll里的imagedirectoryentrytodata来很容易地找到iat。 pvoid imagedirectoryentrytodata( in lpvoid base, in boolean mappedasimage, in ushort directoryentry, out pulong size ); 在这里base参数可以用我们程序的instance(instance通过调用getmodulehandle获得): hinstance = getmodulehandlea(null); directoryentry我们可以使用恒量image_directory_entry_import。 #define image_directory_entry_import 1 函数的结果是指向第一个iat记录指针。iat的所有记录是由image_import_descriptor定义的结构。所以函数结果是指向image_import_descriptor的指针。 typedef struct _image_thunk_data { union { pbyte forwarderstring; pdword function; dword ordinal; pimage_import_by_name addressofdata; } ; } image_thunk_data,*pimage_thunk_data; typedef struct _image_import_descriptor { union { dword characteristics; pimage_thunk_data originalfirstthunk; } ; dword timedatestamp; dword forwarderchain; dword name; pimage_thunk_data firstthunk; } image_import_descriptor,*pimage_import_descriptor; image_import_descriptor里的name成员变量是模块名字的指针。如果我们想要挂钩某个函数比如是来自kernel32.dll我们就在导入表里找属于名字kernel32.dll的描述符号。我们先调用imagedirectoryentrytodata然后找到名字是"kernel32.dll"的描述符号(可能不只一个描述符号是这个名字),最后我们在这个模块的记录里所有函数的列表里找到我们想要的函数(函数地址通过getprocaddress函数获得)。如果我们找到了就必须用virtualprotect函数来改变内存页面的保护属性,然后就可以在内存中的这些部分写入代码了。在改写了地址之后我们要把保护属性改回来。在调用virtualprotect之前我们还要先知道有关页面的信息,这通过virtualquery来实现。我们可以加入一些测试以防某些函数会失败(比方说如果第一次调用virtualproctect就失败了,我们就没办法继续)。 pcstr pszhookmodname = "kernel32.dll",pszsleepname = "sleep"; hmodule hkernel = getmodulehandle(pszhookmodname); proc pfnnew = (proc)0x12345678, //这里存放新地址 pfnhookapiaddr = getprocaddress(hkernel,pszsleepname); ulong ulsize; pimage_import_descriptor pimportdesc = (pimage_import_descriptor)imagedirectoryentrytodata( hkernel, true, image_directory_entry_import, &ulsize ); while (pimportdesc->name) { pstr pszmodname = (pstr)((pbyte) hkernel + pimportdesc->name); if (stricmp(pszmodname, pszhookmodname) == 0) break; pimportdesc++; } pimage_thunk_data pthunk = (pimage_thunk_data)((pbyte) hkernel + pimportdesc->firstthunk); while (pthunk->u1.function) { proc* ppfn = (proc*) &pthunk->u1.function; bool bfound = (*ppfn == pfnhookapiaddr); if (bfound) { memory_basic_information mbi; virtualquery( ppfn, &mbi, sizeof(memory_basic_information) ); virtualprotect( mbi.baseaddress, mbi.regionsize, page_readwrite, &mbi.protect) ) *ppfn = *pfnnew; dword dwoldprotect; virtualprotect( mbi.baseaddress, mbi.regionsize, mbi.protect, &dwoldprotect ); break; } pthunk++; } 调用sleep(1000)的结果如例子所示: 00407bd8: 68e8030000 push 0000003e8h 00407bdd: e812faffff call sleep sleep: ;这是跳转到iat里的地址 004075f4: ff25bca14000 jmp dword ptr [00040a1bch] 原始表: 0040a1bc: 79 67 e8 77 00 00 00 00 新表: ... 下一页