感受微软外包项目（二）

HOOK API
端午假期一过,我们就开始展开最初的项目预研工作，第一步当然是API HOOK。关于如何实现WinAPI HOOK，有无数的技术文档可以借鉴，但基本的技术实现差不多都需要一个额外的独立服务进程，这样做的好处是简单，但使得目标应用关联于一个预先启动的EXE文件，因此给人以不自然的感觉，此外，一旦服务进程崩溃则会带来很严重的问题，因此这个想法可以用来实验，但最终是不可取的方案。
对MSN而言，目前有两款非常出色的Shell，一款是著名的MSN Shell，另外一款也许是一位出生在法国的加拿大人开发的MSN Plus。MSN Shell通过提供一个CRYPTNET.dll副本来实现API HOOK，而MSN Plus则采取了类似的技术（MSN Plus提供了msimg32.dll副本）。如果我们安装了这两个Shell，我们会在MSN安装目录这发现这些动态链接库副本，而MSN原本需要的对应动态链接库存在于Windows/System32系统文件夹之中，有兴趣的朋友可以直接对照相关的原件与副本，看看他们的区别（用Visual Studio提供的实用程序DEPENDS.EXE即可）。从结果上看，MSN Shell与MSN 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/SizeofResource等API函数，我们很快在OC上创建了新UI元素）
这部分工作是由骆归具体实现的，至于我仅仅提出了原始的构想。