如果你不按照这些游戏规则玩的话,你注定会使目的进程挂掉!记住,不要妄想远程进程中的任何数据会和你本地进程中的数据存放在相同内存地址!(参看附录F)
让我们看以下它的部分代码,特别是注入的数据和代码。为了简单起见,没有包含支持Unicode的代码。
INJDATA 是要注入远程进程的数据。在把它的地址传递给SendMessageA之前,我们要先对它进行初始化。幸运的是unse32.dll在所有的进程中(如果 被映射)总是被映射到相同的地址,所以SendMessageA的地址也总是相同的,这也保证了传递给远程进程的地址是有效的。
ThreadFunc是远程线程实际执行的代码。
如何用该技术子类(subclass)一个远程控件
让我们来讨论一个更复杂的问题:如何子类属于其他进程的一个控件?
首先,要完成这个任务,你必须复制两个函数到远程进程:
然 而,最主要的问题是如何传递数据到远程的NewProc。因为NewProc是一个回调(callback)函数,它必须符合特定的要求(译者注:这里指 的主要是参数个数和类型),我们不能再简单地传递一个INJDATA的指针作为它的参数。幸运的我已经找到解决这个问题的方法,而且是两个,但是都要借助 于汇编语言。我一直都努力避免使用汇编,但是这一次,我们逃不掉了,没有汇编不行的。
不 知道你是否注意到了,INJDATA紧挨着NewProc放在NewProc的前面?这样的话在编译期间NewProc就可以知道INJDATA的内存地 址。更精确地说,它知道INJDATA相对于它自身地址的相对偏移,但是这并不是我们真正想要的。现在,NewProc看起来是这个样子:
然而,还有一个问题,看第一行:
pData被硬编码为我们进程中NewProc的地址,但这是不对的。因为NewProc会被复制到远程进程,那样的话,这个地址就错了。
用C/C++没有办法解决这个问题,可以用内联的汇编来解决。看修改后的NewProc:
这 是什么意思?每个进程都有一个特殊的寄存器,这个寄存器指向下一条要执行的指令的内存地址,即32位Intel和AMD处理器上所谓的EIP寄存器。因为 EIP是个特殊的寄存器,所以你不能像访问通用寄存器(EAX,EBX等)那样来访问它。换句话说,你找不到一个可以用来寻址EIP并且对它进行读写的操 作码(OpCode)。然而,EIP同样可以被JMP,CALL,RET等指令隐含地改变(事实上它一直都在改变)。让我们举例说明32位的Intel和 AMD处理器上CALL/RET是如何工作的吧:
当我们用CALL调用一个子程序时,这个子程序的地址被加载进EIP。同时,在 EIP被改变之前,它以前的值会被自动压栈(在后来被用作返回指令指针[return instruction-pointer])。在子程序的最后RET指令自动把这个值从栈中弹出到EIP。
现在我们知道了如何通过CALL和RET来修改EIP的值了,但是如何得到他的当前值?
a. 一个假的函数调用;仅仅跳到下一条指令并且(译者注:更重要的是)把EIP压栈。
这 样一来,不管被复制到什么地方,NewProc总能正确计算自身的地址了!然而,要注意从NewProc的入口点到“pop ECX”的距离可能会因为你的编译器/链接选项的不同而不同,而且在Release和Degub版本中也是不一样的。但是,不管怎样,你仍然可以在编译期 知道这个距离的具体值。
一些蹩脚的破解者用类似的方法来修改可执行文件的机器码,但是一个程序一旦载入内存,就不能再更改自身的机器码(一个可执行文件的.text段是写保护 的)。我们能修改远程进程中的NewProc是因为它所处的那块内存在分配时给予了PAGE_EXECUTE_READWRITE属性。
通 过CreateRemoteThread和WriteProcessMemory来注入代码的技术,和其他两种方法相比,不需要一个额外的DLL文件,因 此更灵活,但也更复杂更危险。一旦你的ThreadFunc中有错误,远程线程会立即崩溃(看附录F)。调试一个远程的ThreadFunc也是场恶梦, 所以你应该在仅仅注入若干条指令时才使用这个方法。要注入大量的代码还是使用另外两种方法吧。
再说一次,你可以在文章的开头部分下载到WinSpy,InjectEx和它们的源代码。
最后,我们总结一些目前还没有提到的东西:
1. 很明显,你不能给一个没有消息队列的线程挂钩。同样SetWindowsHookEx也对系统服务不起作用(就算它们连接了USER32)。
大概就这些了吧。还有一点你需要牢记在心:你注入的代码(特别是存在错误时)很容易就会把目的进程拖垮。记住:责任随权利而来(Power comes with responsibility)!
这篇文章中的很多例子都和密码有关,看过这篇文章后你可能也会对Zhefu Zhang(译者注:大概是一位中国人,张哲夫??)写的Supper Password Spy++感兴趣。他讲解了如何从IE的密码框中得到密码,也说了如何保护你的密码不被这种攻击。
最后一点:读者的反馈是文章作者的唯一报酬,所以如果你认为这篇文章有作用,请留下你的评论或给它投票。更重要的是,如果你发现有错误或bug;或你认为什么地方做得还不够好,有需要改进的地方;或有不清楚的地方也都请告诉我。
当 链接器生成EXE或DLL时,它假定这个文件会被加载到一个特定的地址,也就是所谓的假定/首选加载/基地址(assumed/preferred load/base address)。内存映像(image)中的所有绝对地址都时基于该“链接器假定加载地址”的。如果由于某些原因,映像没有加载到这个地址,那么PE加 载器(PE loader)就不得不修正该映像中的所有绝对地址。这就是“.reloc”段存在的原因:它包含了一个该映像中所有的“链接器假定地址”与真正加载到的 地址之间的差异的列表(注意:编译器产生的大部分指令都使用一种相对寻址模式,所以,真正需要重定位[relocation]的地方并没有你想像的那么 多)。如果,从另一方面说,加载器可以把映像加载到链接器首选地址,那么“.reloc”段就会被彻底忽略。
但是,因为每一个Win32程序都需要kernel32.dll,大部分需要user32.dll,所以如果总是把它们两个映射到其首选地址,那么加载器就不用修正kernel32.dll和user32.dll中的任何(绝对)地址,加载时间就可以缩短。
让我们用下面的例子来结束这个讨论:
为什么?当一个进程被创建时,Win2000 和WinXP的加载器会检查kernel32.dll和user32.dll是否被映射到它们的首选地址(它们的名称是被硬编码进加载器的),如果没有, 就会报错。在WinNT4 中ole32.dll也会被检查。在WinNT3.51或更低版本中,则不会有任何检查,kernel32.dll和user32.dll可以被加载到任 何地方。唯一一个总是被加载到首选地址的模块是ntdll.dll,加载器并不检查它,但是如果它不在它的首选地址,进程根本无法创建。
总结一下:在WinNT4或更高版本的操作系统中:
当 /GZ被使用时,编译器会在每个函数,包含函数调用中添加额外的代码(添加到每个函数的最后面)来检查ESP栈指针是否被我们的函数更改过。但是,等 等,ThreadFunc中被添加了一个函数调用?这就是通往灾难的道路。因为,被复制到远程进程中的ThreadFunc将调用一个在远程进程中不存在 的函数。
请 注意在上面的例子中ESP(栈指针)是如何被改变的。但是如果一个函数有多于4K的局部变量该怎么办?这种情况下,栈指针不会被直接改变,而是通过一个函 数调用来正确实现ESP的改变。但是就是这个“函数调用”导致了ThreadFunc的崩溃,因为它在远程进程中的拷贝将会调用一个不存在的函数。
让我们来看看文档关于栈探针(stack probes)和/Gs编译选项的说明:
如果一个函数需要大于size指定的局部变量空间,它的栈探针将被激活。默认的size为一个页的大小(在80x86上为4k)。这个值可以使一个Win32程序和Windows NT的虚拟内存管理程序和谐地交互,在运行期间向程序栈增加已提交的内存总数。
我 能确定你们对上面的叙述(“栈探针将温和地按照存储函数局部变量所需要的空间大小来移动”)感到奇怪。这些编译选项(他们的描述!)有时候真的让人很恼 火,特别是当你想真的了解它们是怎么工作的时候。打个比方,如果一个函数需要12kb的空间来存放局部变量,栈上的内存是这样“分配”的
..现在为什么文档中说“这个值可以使一个Win32程序和Windows NT的虚拟内存管理程序和谐地交互”也很清楚了。
E) 为什么我要把多于3个case分支的swith分割开来呢?
现在,你可能认为上面的情况仅仅是因为case常量选择得比较好,(1,2,3,4,5)。幸运的是,现实生活中的大多数例子都可以应用这个方案,只是偏移的计算复杂了一点而已。但是,有两个例外:
有趣的地方:如果你曾经为case后面只能跟常量而迷惑的话,现在你应该知道为什么了吧。这个值必须在编译期间就确定下来,这样才能创建地址表。
JMP使用了绝对地址!也就是说,它的其中一个操作数(在这里是0040102C)代表一个绝对地址。还用多说吗?现在远程的ThreadFunc会盲目第在地址表中004101C然后跳到这个错误的地方,马上使远程进程挂掉了。
F) 到底是什么原因使远程进程崩溃了?
不管在什么情况下,你使用CreateRemoteThread & WriteProcessMemory技术时必须万分的小心,特别是编译器/连接器的设置,它们很可能会给你的ThreadFunc添加一些带来麻烦的东西。
PLC远程通讯功能集锦(互联网、局域网)
第一章OPC概述········································1
征集OPC客户程序的Delphi,C++ Builder及其它语言OPC客户程序实例及编写文档,在新版本推出时加入这些实例,提供稿费,并在编者中加入您的大名。
Linux下常用的系统监控软件有Nagios、Cacti、Zabbix、Monit等,这些开源的软件,可以帮助我们更好的管理机器,在第一时间内发现,并警告系统维护人员。 zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。
版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。