在什么情况下用__stdcall这种方式,有什么好处?

aneird 2005-07-07 07:00:03
请问:关注中
...全文
1032 22 打赏 收藏 转发到动态 举报
写回复
用AI写文章
22 条回复
切换为时间正序
请发表友善的回复…
发表回复
joinrry 2005-07-21
  • 打赏
  • 举报
回复
关于约定:

动态库输出函数的约定有两种:调用约定和名字修饰约定。

1)调用约定(Calling convention):决定函数参数传送时入栈和出栈的顺序,由调用者还是被调用者把参数弹出栈,以及编译器用来识别函数名字的修饰约定。

函数调用约定有多种,这里简单说一下:

1、__stdcall调用约定相当于16位动态库中经常使用的PASCAL调用约定。在32位的VC++5.0中PASCAL调用约定不再被支持(实际上它已被定义为__stdcall。除了__pascal外,__fortran和__syscall也不被支持),取而代之的是__stdcall调用约定。两者实质上是一致的,即函数的参数自右向左通过栈传递,被调用的函数在返回前清理传送参数的内存栈,但不同的是函数名的修饰部分(关于函数名的修饰部分在后面将详细说明)。

_stdcall是Pascal程序的缺省调用方式,通常用于Win32 Api中,函数采用从右到左的压栈方式,自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀,在函数名后加上"@"和参数的字节数。

2、C调用约定(即用__cdecl关键字说明)按从右至左的顺序压参数入栈,由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的(正因为如此,实现可变参数的函数只能使用该调用约定)。另外,在函数名修饰约定方面也有所不同。

_cdecl是C和C++程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码,所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下划线前缀。是MFC缺省调用约定。

3、__fastcall调用约定是“人”如其名,它的主要特点就是快,因为它是通过寄存器来传送参数的(实际上,它用ECX和EDX传送前两个双字(DWORD)或更小的参数,剩下的参数仍旧自右向左压栈传送,被调用的函数在返回前清理传送参数的内存栈),在函数名修饰约定方面,它和前两者均不同。

_fastcall方式的函数采用寄存器传递参数,VC将函数编译后会在函数名前面加上"@"前缀,在函数名后加上"@"和参数的字节数。

4、thiscall仅仅应用于“C++”成员函数。this指针存放于CX寄存器,参数从右到左压。thiscall不是关键词,因此不能被程序员指定。

5、naked call采用1-4的调用约定时,如果必要的话,进入函数时编译器会产生代码来保存ESI,EDI,EBX,EBP寄存器,退出函数时则产生代码恢复这些寄存器的内容。naked call不产生这样的代码。naked call不是类型修饰符,故必须和_declspec共同使用。

关键字 __stdcall、__cdecl和__fastcall可以直接加在要输出的函数前,也可以在编译环境的Setting...\C/C++ \Code Generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时,直接加在输出函数前的关键字有效。它们对应的命令行参数分别为/Gz、/Gd和/Gr。缺省状态为/Gd,即__cdecl。

要完全模仿PASCAL调用约定首先必须使用__stdcall调用约定,至于函数名修饰约定,可以通过其它方法模仿。还有一个值得一提的是WINAPI宏,Windows.h支持该宏,它可以将出函数翻译成适当的调用约定,在WIN32中,它被定义为__stdcall。使用WINAPI宏可以创建自己的APIs。

2)名字修饰约定

1、修饰名(Decoration name)

“C”或者“C++”函数在内部(编译和链接)通过修饰名识别。修饰名是编译器在编译函数定义或者原型时生成的字符串。有些情况下使用函数的修饰名是必要的,如在模块定义文件里头指定输出“C++”重载函数、构造函数、析构函数,又如在汇编代码里调用“C””或“C++”函数等。

修饰名由函数名、类名、调用约定、返回类型、参数等共同决定。

2、名字修饰约定随调用约定和编译种类(C或C++)的不同而变化。函数名修饰约定随编译种类和调用约定的不同而不同,下面分别说明。

a、C编译时函数名修饰约定规则:

__stdcall调用约定在输出函数名前加上一个下划线前缀,后面加上一个“@”符号和其参数的字节数,格式为_functionname@number。

__cdecl调用约定仅在输出函数名前加上一个下划线前缀,格式为_functionname。

__fastcall调用约定在输出函数名前加上一个“@”符号,后面也是一个“@”符号和其参数的字节数,格式为@functionname@number。

它们均不改变输出函数名中的字符大小写,这和PASCAL调用约定不同,PASCAL约定输出的函数名无任何修饰且全部大写。

b、C++编译时函数名修饰约定规则:

__stdcall调用约定:
1、以“?”标识函数名的开始,后跟函数名;
2、函数名后面以“@@YG”标识参数表的开始,后跟参数表;
3、参数表以代号表示:
X--void ,
D--char,
E--unsigned char,
F--short,
H--int,
I--unsigned int,
J--long,
K--unsigned long,
M--float,
N--double,
_N--bool,
....
PA--表示指针,后面的代号表明指针类型,如果相同类型的指针连续出现,以“0”代替,一个“0”代表一次重复;
4、参数表的第一项为该函数的返回值类型,其后依次为参数的数据类型,指针标识在其所指数据类型前;
5、参数表后以“@Z”标识整个名字的结束,如果该函数无参数,则以“Z”标识结束。

其格式为“?functionname@@YG*****@Z”或“?functionname@@YG*XZ”,例如
int Test1(char *var1,unsigned long)-----“?Test1@@YGHPADK@Z”
void Test2() -----“?Test2@@YGXXZ”

__cdecl调用约定:
规则同上面的_stdcall调用约定,只是参数表的开始标识由上面的“@@YG”变为“@@YA”。

__fastcall调用约定:
规则同上面的_stdcall调用约定,只是参数表的开始标识由上面的“@@YG”变为“@@YI”。

VC++对函数的省缺声明是"__cedcl",将只能被C/C++调用.
joinrry 2005-07-21
  • 打赏
  • 举报
回复
其实主要是因为他们压栈的方式不同。

DLL(Dynamic Link Libraries)专题:

比较大的应用程序都由很多模块组成,这些模块分别完成相对独立的功能,它们彼此协作来完成整个软件系统的工作。可能存在一些模块的功能较为通用,在构造其它软件系统时仍会被使用。在构造软件系统时,如果将所有模块的源代码都静态编译到整个应用程序EXE文件中,会产生一些问题:一个缺点是增加了应用程序的大小,它会占用更多的磁盘空间,程序运行时也会消耗较大的内存空间,造成系统资源的浪费;另一个缺点是,在编写大的EXE程序时,在每次修改重建时都必须调整编译所有源代码,增加了编译过程的复杂性,也不利于阶段性的单元测试。

Windows系统平台上提供了一种完全不同的较有效的编程和运行环境,你可以将独立的程序模块创建为较小的DLL(Dynamic Linkable Library)文件,并可对它们单独编译和测试。在运行时,只有当EXE程序确实要调用这些DLL模块的情况下,系统才会将它们装载到内存空间中。这种方式不仅减少了EXE文件的大小和对内存空间的需求,而且使这些DLL模块可以同时被多个应用程序使用。Windows自己就将一些主要的系统功能以DLL模块的形式实现。

一般来说,DLL是一种磁盘文件,以.DLL、.DRV、.FON、.SYS和许多以.EXE为扩展名的系统文件都可以是DLL。它由全局数据、服务函数和资源组成,在运行时被系统加载到进程的虚拟空间中,成为调用进程的一部分。如果与其它DLL之间没有冲突,该文件通常映射到进程虚拟空间的同一地址上。DLL模块中包含各种导出函数,用于向外界提供服务。DLL可以有自己的数据段,但没有自己的堆栈,使用与调用它的应用程序相同的堆栈模式;一个DLL在内存中只有一个实例;DLL实现了代码封装性;DLL的编制与具体的编程语言及编译器无关。

在Win32环境中,每个进程都复制了自己的读/写全局变量。如果想要与其它进程共享内存,必须使用内存映射文件或者声明一个共享数据段。DLL模块需要的堆栈内存都是从运行进程的堆栈中分配出来的。Windows在加载DLL模块时将进程函数调用与DLL文件的导出函数相匹配。Windows操作系统对DLL的操作仅仅是把DLL映射到需要它的进程的虚拟地址空间里去。DLL函数中的代码所创建的任何对象(包括变量)都归调用它的线程或进程所有.

一、关于调用方式:

1、静态调用方式:由编译系统完成对DLL的加载和应用程序结束时DLL卸载的编码(如还有其它程序使用该DLL,则Windows对DLL的应用记录减1,直到所有相关程序都结束对该DLL的使用时才释放它),简单实用,但不够灵活,只能满足一般要求。

隐式的调用:需要把产生动态连接库时产生的.LIB文件加入到应用程序的工程中,想使用DLL中的函数时,只须说明一下。隐式调用不需要调用LoadLibrary()和FreeLibrary()。程序员在建立一个DLL文件时,链接程序会自动生成一个与之对应的LIB导入文件。该文件包含了每一个DLL导出函数的符号名和可选的标识号,但是并不含有实际的代码。LIB文件作为DLL的替代文件被编译到应用程序项目中。当程序员通过静态链接方式编译生成应用程序时,应用程序中的调用函数与LIB文件中导出符号相匹配,这些符号或标识号进入到生成的EXE文件中。LIB文件中也包含了对应的DLL文件名(但不是完全的路径名),链接程序将其存储在EXE文件内部。当应用程序运行过程中需要加载DLL文件时,Windows根据这些信息发现并加载DLL,然后通过符号名或标识号实现对DLL函数的动态链接。所有被应用程序调用的DLL文件都会在应用程序EXE文件加载时被加载在到内存中。可执行程序链接到一个包含DLL输出函数信息的输入库文件(.LIB文件)。操作系统在加载使用可执行程序时加载DLL。可执行程序直接通过函数名调用DLL的输出函数,调用方法和程序内部其他的函数是一样的。


2、动态调用方式:是由编程者用API函数加载和卸载DLL来达到调用DLL的目的,使用上较复杂,但能更加有效地使用内存,是编制大型应用程序时的重要方式。

显式的调用:是指在应用程序中用LoadLibrary或MFC提供的AfxLoadLibrary显式的将自己所做的动态连接库调进来,动态连接库的文件名即是上面两个函数的参数,再用GetProcAddress()获取想要引入的函数。自此,你就可以象使用如同本应用程序自定义的函数一样来调用此引入函数了。在应用程序退出之前,应该用FreeLibrary或MFC提供的AfxFreeLibrary释放动态连接库。直接调用Win32 的LoadLibary函数,并指定DLL的路径作为参数。LoadLibary返回HINSTANCE参数,应用程序在调用GetProcAddress函数时使用这一参数。GetProcAddress函数将符号名或标识号转换为DLL内部的地址。程序员可以决定DLL文件何时加载或不加载,显式链接在运行时决定加载哪个DLL文件。使用DLL的程序在使用之前必须加载(LoadLibrary)加载DLL从而得到一个DLL模块的句柄,然后调用GetProcAddress函数得到输出函数的指针,在退出之前必须卸载DLL(FreeLibrary)。

Windows将遵循下面的搜索顺序来定位DLL:
1.包含EXE文件的目录,
2.进程的当前工作目录,
3.Windows系统目录,
4.Windows目录,
5.列在Path环境变量中的一系列目录。
JonneyR 2005-07-21
  • 打赏
  • 举报
回复
结分吧
aneird 2005-07-12
  • 打赏
  • 举报
回复
哦 明白
gohappy_1999 2005-07-11
  • 打赏
  • 举报
回复
并不是所有的语言都支持_cdcel调用规则,但是都支持_sdtcall调用规则,
windows api都是_stdcall调用规则
sdbtb 2005-07-11
  • 打赏
  • 举报
回复
回复人: aneird(vccc) ( ) 信誉:100 2005-07-11 09:16:00 得分: 0

那为什么 把这个DLL被其他语言也能调用的话,VB.DEPHI.PB.. 就得约定声明为__stdcall呢

如果约定大家使用cdecl调用规则,你是否也要问为什么要用这个规则呢?
我觉得这只是个规则,大家都遵守才可以互相沟通。
这和网络协议之类都差不多,总要定个规则,不同的参与者才能正常的通信。
lzf8977 2005-07-11
  • 打赏
  • 举报
回复
支持 JonneyR(lxc)

我记得这好象是一种约定,如果不这样做的话,,程序会出现莫明其妙的问题,,,,...
aneird 2005-07-11
  • 打赏
  • 举报
回复
那为什么 把这个DLL被其他语言也能调用的话,VB.DEPHI.PB.. 就得约定声明为__stdcall呢
gohappy_1999 2005-07-10
  • 打赏
  • 举报
回复
假如你用VC做了一个DLL,导出了某些函数,如果你想这个DLL被其他语言也能调用的话,VB.DEPHI.PB..
你的把他的调用约定声明为__stdcall
surstar 2005-07-08
  • 打赏
  • 举报
回复
所有的Win32 API函数都遵循该约定
JonneyR 2005-07-08
  • 打赏
  • 举报
回复
__stdcall实际上是Microsoft对编译器的一个扩展,任何一个支持开发Win32应用程序的编译器都会对此或与此等价的选项。用__stdcall标记的函数将使用标准的调用约定,即这些函数将在返加调用者之间将参数从栈中删除。常规的C/C++调用约定中,栈的清理工作则是由调用者完成的。大多数其他的编程语言,如VB缺省情况下使用的也是标准的调用约定。另外用此方法的原因是早期的Windows是运行于640KB系统上的
aneird 2005-07-08
  • 打赏
  • 举报
回复
那为什么这种约定能 让使用其他语言编写的程序也能够调用DLL中的这些函数呢?
krfstudio 2005-07-08
  • 打赏
  • 举报
回复
不是必须使用这种调用约定,用这种调用约定可以让使用其他语言编写的程序也能够调用DLL中的这些函数。
aneird 2005-07-08
  • 打赏
  • 举报
回复
关注。。。
aneird 2005-07-08
  • 打赏
  • 举报
回复
为什么 还没说呢
JonneyR 2005-07-08
  • 打赏
  • 举报
回复
答案已经出来啦
aneird 2005-07-08
  • 打赏
  • 举报
回复
继续a
aneird 2005-07-07
  • 打赏
  • 举报
回复
像dll com中的一些函数 ,为什么必须用__stdcall这种方式呢 ,
newbiestar 2005-07-07
  • 打赏
  • 举报
回复
Windows的API都是用这个的,主要特性是自己清栈,好像也没什么特别的好处。

反正用了C/C++的变参函数,就没办法用stdcall协议了,cdecl才能支持变参……
西山小月 2005-07-07
  • 打赏
  • 举报
回复
dll,其他语言的程序也可以调用这个dll。
加载更多回复(2)
Windows用户层下拦截api的原理与实现(附源码) (2008-03-29 16:15:07)转载▼ 标签: computer 杂谈 声明:本页所发布的技术文章及其附件,供自由技术传播,拒绝商业使用。本页文章及其附件的所有权归属本文作者,任何使用文档中所介绍技术者对其后果自行负责,本文作者不对其承担任何责任。 Email:redcoder163.com 目录 1 摘要 2 win2000和xp的内存结构和进程地址空间 3 函数堆栈的一些知识 4 关于拦截的整体思路 5 附件代码下载以及说明 一:摘要 拦截api的技术有很多种,大体分为用户层和内核层的拦截.这里只说说用户层的拦截(内核层也可以用,关键是让你的拦截程序获得ring0特权).而用户层也分为许多种:修改PE文件导入表,直接修改要拦截的api的内存(从开始到最后,使程序跳转到指定的地址执行).不过大部分原理都是修改程序流程,使之跳转到你要执行的地方,然后再返回到原地址.原来api的功能必须还能实现.否则拦截就失去作用了.修改文件导入表的方法的缺点是如果用户程序动态加载(使用LoadLibrary和GetProcAddress函数),拦截将变得复杂一些.所以这里介绍一下第二种方法,直接修改api,当然不是全局的.(后面会说到)   需要了解的一些知识:   1.windows内存的结构属性和进程地址空间   2.函数堆栈的一些知识 二:win2000和xp的内存结构和进程地址空间 windows采用4GB平坦虚拟地址空间的做法。即每个进程单独拥有4GB的地址空间。每个进程只能访问自己的这4GB的虚拟空间,而对于其他进程的地址空间则是不可见的。这样保证了进程的安全性和稳定性。但是,这4GB的空间是一个虚拟空间,在使用之前,我们必须先保留一段虚拟地址,然后再为这段虚拟地址提交物理存储器。可是我们的内存大部分都还没有1GB,那么这4GB的地址空间是如何实现的呢?事实上windows采用的内存映射这种方法,即把物理磁盘当作内存来使用,比如我们打开一个可执行文件的时候,操作系统会为我们开辟这个4GB的地址空间:0x00000000--0xffffffff。其中0x00000000--0x7fffffff是属于用户层的空间.0x80000000--0xffffffff则属于共享内核方式分区,主要是操作系统的线程调度,内存管理,文件系统支持,网络支持和所有设备驱动程序。对于用户层的进程,这些地址空间是不可访问的。任何访问都将导致一个错误。开辟这4GB的虚拟地址空间之后,系统会把磁盘上的执行文件映射到进程的地址空间中去(一般是在地址0x00400000,可以通过修改编译选项来修改这个地址)而一个进程运行所需要的动态库文件则一般从0x10000000开始加载。但是如果所有的动态库都加载到这个位置肯定会引起冲突。因此必须对一些可能引起冲突的dll编译时重新修改基地址。但是对于所有的操作系统所提供的动态库windows已经定义好了映射在指定的位置。这个位置会随着版本的不同而会有所改变,不过对于同一台机器上的映射地址来说都是一样的。即在a进程里映射的kernel32.dll的地址和在进程b里的kernel32.dll的地址是一样的。对于文件映射是一种特殊的方式,使得程序不需要进行磁盘i/o就能对磁盘文件进行操作,而且支持多种保护属性。对于一个被映射的文件,主要是使用CreateFileMapping函数,利用他我们可以设定一些读写属性:PAGE_READONLY,PAGE_READWRITE,PAGE_WRITECOPY.第一参数指定只能对该映射文件进行读操作。任何写操作将导致内存访问错误。第二个参数则指明可以对映射文件进行读写。这时候,任何对文件的读写都是直接操作文件的。而对于第三个参数PAGE_WRITECOPY顾名思义就是写入时拷贝,任何向这段内存写入的操作(因为文件是映射到进程地址空间的,对这段空间的读写就相当于对文件进行的直接读写)都将被系统捕获,并重新在你的虚拟地址空间重新保留并分配一段内存,你所写入的一切东西都将在这里,而且你原先的指向映射文件的内存地址也会实际指向这段重新分配的内存,于是在进程结束后,映射文件内容并没有改变,只是在运行期间在那段私有拷贝的内存里面存在着你修改的内容。windows进程运行所需要映射的一些系统dll就是以这种方式映射的,比如常用的ntdll.dll,kernel32.dll,gdi32.dll.几乎所有的进程都会加载这三个动态库。如果你在一个进程里修改这个映射文件的内容,并不会影响到其他的进程使用他们。你所修改的只是在本进程的地址空间之内的。事实上原始文件并没有被改变。 这样,在后面的修改系统api的时候,实际就是修改这些动态库地址内的内容。前面说到这不是修改全局api就是这个原因,因为他们都是以写入时拷贝的方式来映射的。不过这已经足够了,windows提供了2个强大的内存操作函数ReadProcessMemory和WriteProcessMemory.利用这两个函数我们就可以随便对任意进程的任意用户地址空间进行读写了。但是,现在有一个问题,我们该写什么,说了半天,怎么实现跳转呢?现在来看一个简单的例子: MessageBox(NULL, "World", "Hello", 0); 我们在执行这条语句的时候,调用了系统api MessageBox,实际上在程序中我没有定义UNICODE宏,系统调用的是MessageBox的ANSI版本MessageBoxA,这个函数是由user32.dll导出的。下面是执行这条语句的汇编代码: 0040102A push 0 0040102C push offset string "Hello" (0041f024) 00401031 push offset string "World" (0041f01c) 00401036 push 0 00401038 call dword ptr [__imp__MessageBoxA@16 (0042428c)] 前面四条指令分别为参数压栈,因为MessageBoxA是__stdcall调用约定,所以参数是从右往左压栈的。最后再CALL 0x0042428c 看看0042428c这段内存的值: 0042428C 0B 05 D5 77 00 00 00 可以看到这个值0x77d5050b,正是user32.dll导出函数MessageBoxA的入口地址。 这是0x77D5050B处的内容, 77D5050B 8B FF mov edi,edi 77D5050D 55 push ebp 77D5050E 8B EC mov ebp,esp 理论上只要改变api入口和出口的任何机器码,都可以拦截该api。这里我选择最简单的修改方法,直接修改qpi入口的前十个字节来实现跳转。为什么是十字节呢?其实修改多少字节都没有关系,只要实现了函数的跳转之后,你能把他们恢复并让他继续运行才是最重要的。在CPU的指令里,有几条指令可以改变程序的流程:JMP,CALL,INT,RET,RETF,IRET等指令。这里我选择CALL指令,因为他是以函数调用的方式来实现跳转的,这样可以带一些你需要的参数。到这里,我该说说函数的堆栈了。 总结:windows进程所需要的动态库文件都是以写入时拷贝的方式映射到进程地址空间中的。这样,我们只能拦截指定的进程。修改目标进程地址空间中的指定api的入口和出口地址之间的任意数据,使之跳转到我们的拦截代码中去,然后再恢复这些字节,使之能顺利工作。 三:函数堆栈的一些知识 正如前面所看到MessageBoxA函数执行之前的汇编代码,首先将四个参数压栈,然后CALL MessageBoxA,这时候我们的线程堆栈看起来应该是这样的: | | <---ESP |返回地址| |参数1| |参数2| |参数3| |参数4| |.. | 我们再看MessageBoxA的汇编代码, 77D5050B 8B FF mov edi,edi 77D5050D 55 push ebp 77D5050E 8B EC mov ebp,esp 注意到堆栈的操作有PUSH ebp,这是保存当前的基址指针,以便一会儿恢复堆栈后返回调用线程时使用,然后再有mov ebp,esp就是把当前esp的值赋给ebp,这时候我们就可以使用 ebp+偏移 来表示堆栈中的数据,比如参数1就可以表示成[ebp+8],返回地址就可以表示成[ebp+4]..如果我们在拦截的时候要对这些参数和返回地址做任何处理,就可以使用这种方法。如果这个时候函数有局部变量的话,就通过减小ESP的值的方式来为之分配空间。接下来就是保存一些寄存器:EDI,ESI,EBX.要注意的是,函数堆栈是反方向生长的。这时候堆栈的样子: |....| |EDI| <---ESP |ESI| |EBX| |局部变量| |EBP | |返回地址| |参数1| |参数2| |参数3| |参数4| |.. | 在函数返回的时候,由函数自身来进行堆栈的清理,这时候清理的顺序和开始入栈的顺序恰恰相反,类似的汇编代码可能是这样的: pop edi pop esi pop ebx add esp, 4 pop ebp ret 0010 先恢复那些寄存器的值,然后通过增加ESP的值的方式来释放局部变量。这里可以用mov esp, ebp来实现清空所有局部变量和其他一些空闲分配空间。接着函数会恢复EBP的值,利用指令POP EBP来恢复该寄存器的值。接着函数运行ret 0010这个指令。该指令的意思是,函数把控制权交给当前栈顶的地址的指令,同时清理堆栈的16字节的参数。如果函数有返回值的话,那在EAX寄存器中保存着当前函数的返回值。如果是__cdecl调用方式,则执行ret指令,对于堆栈参数的处理交给调用线程去做。如wsprintf函数。 这个时候堆栈又恢复了原来的样子。线程得以继续往下执行... 在拦截api的过程之中一个重要的任务就是保证堆栈的正确性。你要理清每一步堆栈中发生了什么。 四:形成思路 呵呵,不知道你现在脑海是不是有什么想法。怎么去实现拦截一个api? 这里给出一个思路,事实上拦截的方法真的很多,理清了一个,其他的也就容易了。而且上面所说的2个关键知识,也可以以另外的形式来利用。 我以拦截CreateFile这个api为例子来简单说下这个思路吧: 首先,既然我们要拦截这个api就应该知道这个函数在内存中的位置吧,至少需要知道从哪儿入口。CreateFile这个函数是由kernel32.dll这个动态库导出的。我们可以使用下面的方法来获取他映射到内存中的地址: HMODULE hkernel32 = LoadLibrary("Kernel32.dll"); PVOID dwCreateFile = GetProcAddress(hkernei32, "CreateFileA"); 这就可以得到createfile的地址了,注意这里是获取的createfile的ansic版本。对于UNICODE版本的则获取CreateFileW。这时dwCreateFile的值就是他的地址了。对于其他进程中的createfile函数也是这个地址,前面说过windows指定了他提供的所有的dll文件的加载地址。 接下来,我们该想办法实现跳转了。最简单的方法就是修改这个api入口处的代码了。但是我们该修改多少呢?修改的内容为什么呢?前面说过我们可以使用CALL的方式来实现跳转,这种方法的好处是可以为你的拦截函数提供一个或者多个参数。这里只要一个参数就足够了。带参数的函数调用的汇编代码是什么样子呢,前面也已经说了,类似与调用MessageBoxA时的代码: PUSH 参数地址 CALL 函数入口地址(这里为一个偏移地址) 执行这2条指令就能跳转到你要拦截的函数了,但是我们该修改成什么呢。首先,我们需要知道这2条指令的长度和具体的机器代码的值。其中PUSH对应0x68,而CALL指令对应的机器码为0xE8,而后面的则分别对应拦截函数的参数地址和函数的地址。注意第一个是一个直接的地址,而第二个则是一个相对地址。当然你也可以使用0xFF0x15这个CALL指令来进行直接地址的跳转。 下面就是计算这2个地址的值了, 对于参数和函数体的地址,要分情况而定,对于对本进程中api的拦截,则直接取地址就可以了。对于参数,可以先定义一个参数变量,然后取变量地址就ok了。 如果是想拦截其他进程中的api,则必须使用其他一些方法,最典型的方法是利用VirtualAllocEx函数来在其他进程中申请和提交内存空间。然后用WriteProcessMemory来分别把函数体和参数分别写入申请和分配的内存空间中去。然后再生成要修改的数据,最后用WriteProcessMemory来修改api入口,把入口的前10字节修改为刚刚生成的跳转数据。比如在远程进程中你写入的参数和函数体的内存地址分别为0x00010000和0x00011000,则生成的跳转数据为 68 00 00 01 00 E8 00 10 01 00(PUSH 00010000 CALL 00011000),这样程序运行createfile函数的时候将会先运行PUSH 00010000 CALL 00011000,这样就达到了跳转的目的。此刻我们应该时刻注意堆栈的状态,对于CreateFile有 HANDLE CreateFile( LPCTSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile ); 可以看到其有7个参数,于是在调用之前,堆栈应该已经被压入了这7个参数,堆栈的样子: |....| <---ESP |createfile执行后的下一条指令地址| |参数1| |参数2| |参数3| |参数4| |参数5| |参数6| |参数7| |..| 这是执行到我们的跳转语句:PUSH 00010000,于是堆栈又变了: |....| <---ESP |00010000| |createfile执行后的下一条指令地址| |参数1| |参数2| |参数3| |参数4| |参数5| |参数6| |参数7| |..| 接着执行CALL 00011000,堆栈变为: |...| <---ESP |api入口之后的第六个字节的指令的地址| |00010000| |createfile执行后的下一条指令地址| |参数1| |参数2| |参数3| |参数4| |参数5| |参数6| |参数7| |..| 接下来就到了我们的拦截函数中拉,当然,函数肯定也会做一些类似动作,把EBP压栈,为局部变量分配空间等。这时候堆栈的样子又变了: |EDI| <---ESP |ESI| |EBX| |局部变量| |EBP| dwMessageBox; pfnMessageBox(NULL, PFileName, PFileName, MB_ICONINFORMATION |MB_OK); //输出要打开的文件的路径..... } 对于你要使用的其他函数,都是使用同样的方式,利用这个参数来传递我们要传递的函数的绝对地址,然后定义这个函数指针,就可以使用了。 好了,接下来我们该让被拦截的api正常工作了,这个不难,把他原来的数据恢复一下就可以了。那入口的10个字节。我们在改写他们的时候应该保存一下,然后也把他放在参数中传递给拦截函数,呵呵,参数的作用可多了。接着我们就可以用WriteProcessMemory函数来恢复这个api的入口了,代码如下: PFN_GETCURRENTPROCESS pfnGetCurrentProcess = (PFN_GETCURRENTPROCESS)pRP->dwGetCurrentProcess; PFN_WRITEPROCESSMEMORY pfnWriteProcessMemory = (PFN_WRITEPROCESSMEMORY)pRP->dwWriteProcessMemory; if(!pfnWriteProcessMemory(pfnGetCurrentProcess(), (LPVOID)pfnConnect, (LPCVOID)pRP->szOldCode, 10, NULL)) pfnMessageBox(NULL, pRP->szModuleName1, pRP->szModuleName2, MB_ICONINFORMATION | MB_OK); 其中这些函数指针的定义和上面的类似。 而参数中的szoldcode则是在源程序中在修改api之前保存好,然后传给拦截函数,在源程序中是用ReadProcessMemory函数来获取他的前10个字节的: ReadProcessMemory(GetCurrentProcess(), (LPCVOID)RParam.dwCreateFile, oldcode, 10, &dwPid) strcat((char*)RParam.szOldCode, (char*)oldcode); 接下来如果你还继续保持对该api的拦截,则又该用WriteProcessMemory 来修改入口了,跟前面的恢复入口是一样的,只不过把szOldCode换成了szNewCode了而已。这样你又能对CreateFile继续拦截了。 好了,接下来该进行堆栈的清理了,也许你还要做点其他事情,尽管做去。但是清理堆栈是必须要做的,在函数结束的时候,因为在我们放任api恢复执行之后,他又return 到我们的函数中来了,这个时候的堆栈是什么样子呢? |EDI| <---ESP |ESI| |EBX| |局部变量| |EBP| <---EBP |api入口之后的第六个字节的指令的地址| |00010000| |createfile执行后的下一条指令地址| |参数1| |参数2| |参数3| |参数4| |参数5| |参数6| |参数7| |..| 我们的目标是把返回值记录下来放到EAX寄存器中去,把返回地址记录下来,同时把堆栈恢复成原来的样子。 首先我们恢复那些寄存器的值,接着释放局部变量,可以用mov esp, ebp.因为我们不清楚具体的局部变量分配了多少空间。所以使用这个方法。 __asm {POP EDI POP ESI POP EBX //恢复那些寄存器 MOV EDX, [NextIpAddr]//把返回地址放到EDX中,因为待会儿 //EBP被恢复后,线程中的所有局部变量就不能正常使用了。 MOV EAX, [RetValue]//返回值放到EAX中,当然也可以修改这个返回值 MOV ESP, EBP//清理局部变量 POP EBP//恢复EBP的值 ADD ESP, 28H //清理参数和返回地址,注意一共(7+1+1+1)*4 PUSH EDX //把返回地址压栈,这样栈中就只有这一个返回地址了,返回之后栈就空了 RET } 这样,一切就完成了,堆栈恢复了应该有的状态,而你想拦截的也拦截到了。 五:后记 拦截的方式多种多样,不过大体的思路却都相同。要时刻注意你要拦截的函数的堆栈状态以及在拦截函数中的对数据的引用和函数的调用(地址问题)。

16,550

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Creator Browser
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧