CSDN博客

img sunhui

感受微软外包项目(二)

发表于2008/10/3 22:36:00  8161人阅读

分类: 编程杂谈

HOOK API

         端午假期一过,我们就开始展开最初的项目预研工作,第一步当然是API HOOK。关于如何实现WinAPI HOOK,有无数的技术文档可以借鉴,但基本的技术实现差不多都需要一个额外的独立服务进程,这样做的好处是简单,但使得目标应用关联于一个预先启动的EXE文件,因此给人以不自然的感觉,此外,一旦服务进程崩溃则会带来很严重的问题,因此这个想法可以用来实验,但最终是不可取的方案。

         MSN而言,目前有两款非常出色的Shell,一款是著名的MSN Shell,另外一款也许是一位出生在法国的加拿大人开发的MSN PlusMSN Shell通过提供一个CRYPTNET.dll副本来实现API HOOK,而MSN Plus则采取了类似的技术(MSN Plus提供了msimg32.dll副本)。如果我们安装了这两个Shell,我们会在MSN安装目录这发现这些动态链接库副本,而MSN原本需要的对应动态链接库存在于Windows/System32系统文件夹之中,有兴趣的朋友可以直接对照相关的原件与副本,看看他们的区别(用Visual Studio提供的实用程序DEPENDS.EXE即可)。从结果上看,MSN ShellMSN Plus之间也许是彼此借鉴了,至于谁借鉴了谁,我们无从考证,但从这两款软件的这些特征上看无疑给我们以启发,但Office Communicator毕竟与MSN有极大的区别,因此我们必须选择合适的DLL才可能实现类似的效果。以上的分析归根结底是希望实现一种HOOK API的途径,同时确保这个实现途径不会影响其他进程,也不依赖其他进程。那么选择什么库作为入口点呢?

         选择一个合适的“DLL”进行合理的替换,也许是一种明智的选择,但候选的dll应该足够简明,这样重新实现对应的副本就会是一件相对容易的工作。MSN Plus选择msimg32.dll的原因可能是因为msimg32.dll的原件很小(4,608 字节),而MSN Shell选择了CRYPTNET.dll则很可能是加密会话的需要。安装了Office Communicator之后,Communicator.exe所在的目录中仅包含有限的几个dll库,我们选择了RTMPLTFM.dll,这个库仅包含了4个输出函数,尽管这个库的尺寸比较大(5.07M)。

         一旦原理分析清楚,具体的实现工作就踏实了许多。具体的实现工作在第一天的试验中就有了结果,当微软的朋友打电话给我的时候,我们已经顺利的实现了第一步预想的工作,如图所示:

(通过HOOK LoadResource/FindResource/SizeofResourceAPI函数,我们很快在OC上创建了新UI元素)

这部分工作是由骆归具体实现的,至于我仅仅提出了原始的构想。

0 0

相关博文

我的热门文章

img
取 消
img