如上篇blog中所述，由于朋友笔记本的性能问题，无意中发现QQ可能在用户的计算机上，留下了常驻内存的代码。为了验证该问题，笔者在新装的Windows XP SP2虚拟机上，进行了试验。
分析结果表明，在QQ2006 Beta3安装程序中，默认包含了搜搜地址栏。如果按照QQ安装向导的默认设置，完成安装，搜搜地址栏也会被安装到计算机上。而他们的反安装程序是独立的。因此如果用户从控制面板——添加/删除程序中仅仅卸载了QQ，搜搜地址栏会依然运行于用户的计算机上。由于该程序的存在，用户在IE地址栏中输入关键字时，将会被导向Tencent的Soso。
在添加/删除程序中，可以卸载掉搜搜地址栏。但与一般应用程序有所不同的是，搜搜地址栏具有反删除功能，如果用户没有注意到添加/删除程序中的卸载选项，而是想直接从文件系统中删掉相关程序文件的话，将会遇到很大的困难。因为即使删除了该系统的部分文件或者注册表启动选项之后，它也会自动恢复这些内容。
技术上，该系统的文件主要位于C:\Program Files\Tencent\Adplus目录下。根据测试的情况，部分文件的部分作用如下：
SSAddr.dll：以Shell Extension的形式驻留Explorer进程，作为URL Extension控制了IE地址搜索功能。
Adplus.dll：驻留Explorer以及其他用户进程。
stup.exe：进行某些初始化操作，使Adplus.dll能够驻留在各用户进程中。为了让stup在计算机启动时自动运行，在注册表HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run中，存在名为stup的启动选项，值为C:\Program Files\Tencent\Adplus\stup.exe。
系统各模块相互作用，防止被清除。根据笔者的测试，如果删除了注册表中stup启动选项，它会被自动恢复；而在连入互联网的情况下，被删除的stup.exe文件也会重新生成。
在分析过程中，还有两个令笔者不安的发现：
---通过Windows提供的Task机制，腾讯在拥有Local System权限的service进程中运行了部分代码
---该应用读取并复制了Kernel32.dll
基于个人的经验，这两者更多的被用于病毒木马等恶意软件，很难想象普通的应用程序为何需要采取上述两种行为。说搜搜是病毒木马缺乏事实，不过它的行为的确有些邪气。一个能想出的理由是，IE地址栏就那么一个，盯着它的不仅仅是腾讯一家（比如3721什么的），未免大家有磕磕碰碰的时候。设计这么复杂一个东西出来，大概是为了对决或者群殴？
从朋友计算机的遭遇和网上的一些用户反馈来看，腾讯的这个遗留系统可能会导致用户的系统性能大幅度下降。如果需要使用QQ，最好在安装向导中仅仅选择安装QQ。至少在QQ2006 Beta3中，这种情况下不会安装搜搜。如果已经安装了QQ2006，可以查看控制面板——添加/删除程序中是否有卸载搜搜地址栏的选项。
本文后面部分是一些关键的测试和分析过程，如有troubleshooting类似问题的可以参考（在测试环境中的状况与我在朋友计算机上遇到的并不完全一致，估计是由于QQ不同的版本实现该系统的方式不完全一致。但总体方法上大致相同）。
试验环境是运行于Virtual PC上的Windows XP SP2虚拟机，干净的系统，默认状况下与互联网断开连接。
从www.qq.com下载新版的QQ，安装程序名称为qq2006beta3。
运行安装程序，看看许可协议：
按照安装向导的默认选项，完成安装。
运行msconfig，在注册表startup选项中，发现新增了两项与腾讯相关内容，其中之一名为stup，指向C:\Program Files\Tencent\Adplus\stup.exe。
重启计算机，从添加/删除程序中，卸载QQ（注意添加/删除程序中还有搜搜地址栏的卸载工具，如果也运行了该选项，可以将搜搜地址栏卸载，也不会出现下文的状况）。
卸载之后，运行msconfig，stup依然存在于注册表startup选项中。于是我清除掉了stup选项，以阻止它自动运行。在重启计算机后，运行msconfig，在注册表的启动选项中，又出现了新的stup！
显然是有驻留的应用程序在监控注册表中的startup选项，并且在发现stup项目被删除后，重新生成了该启动项目。我首先查看了msconfig中的“服务”标签，但是没有发现可疑的服务。
打开stup中指向的C:\Program Files\Tencent\Adplus目录，有启动选项中指定的stup.exe，以及其他几个文件，其中包括Adplus.dll、SSAddr.dll。
尝试删除Adplus目录，但系统报错，提示Adplus.dll访问被拒绝。
根据这种现象，猜测Tencent使用了Dll Injection技术，将Adplus.dll注入到其他进程中。导致系统无法删除该文件。
检查hkey_local_machine\software\microsoft\windows nt\currentversion\windows\Appinit_Dlls，没有发现相关的键值。
为了验证我的猜测，运行notepad，然后运行Process Explorer查看进程信息，有如下发现：
Adplus.dll驻留在进程notepad.exe中；Adplus.dll、SSAddr.dll驻留在进程explorer.dll中。
为了更多地了解Adplus被访问的情况，我关闭了刚刚打开的Notepad。下载并运行Filemon，监控文件系统的活动，然后运行Notepad。
从Filemon的输出显示，进程ID为872的svchost进程，也访问了Adplus.dll。从Process Explorer中，看出svchost.exe:872是host windows主要服务的进程。但是并没有Adplus.dll或者任何其他Tencent的dll驻留在该进程中。这意味着很可能svchost.exe是为了运行Adplus.dll中的代码而访问该文件。
而比较常见的在该svchost.exe环境下执行代码的方式，是通过Task Scheduler Service。为了验证我的猜测，我禁用掉了Task Scheduler Service，然后重新运行Notepad。在这种情况下，svchost.exe不再访问Adplus.dll。而一旦enable Task Scheduler，则Filemon中又显示出svchost.exe访问Adplus.dll的记录。由此推断，搜搜工具条通过Task Schedule运行了部分代码。
考虑到svchost.exe是运行在Local System帐号下，对于本地系统有相当高的特权，对于这一发现我感到不安。而在将Filemon的日志导入Excel作进一步分析的时候，我注意到了另外一个现象。Notepad进程读取并复制了kernel32.dll文件（复制文件名为s88..dll，而svchost曾经尝试访问该复制的kernel32.dll。同时，svchost还尝试访问过另外几个命名规则跟s88..dll类似的文件。
为进一步查明搜搜地址栏的启动流程，对于ADPLUS目录，我启用了NTFS文件审计，然后重启计算机，打开安全日志。重启之后Adplus下第一个被审核记录的文件，是stup.exe，由explorer.exe访问。
?
从Adplus中删除stup.exe，能够正常删除。等待三分钟，资源管理器中没有再次出现该文件，关闭计算机。几分钟之后重新开机。在Adplus目录中依然没有stup.exe（后来的测试表明，如果计算机连接到互联网上，那么stup.exe将会被重新生成）。
打开Notepad，运行Process Explorer，这次Adplus.dll没有出现在进程的dl列表中。但是，在Explorer.exe中，依然驻留着SSAddr.dll。
打开Filemon，设置Filter，使之仅仅显示包含adplus或者ssaddr的访问记录。运行Notepad，然后关闭。在Filemon的输出界面中，依然存在Adplus.dll的访问信息。
由于看到搜搜曾经复制过Kernel32.dll，我怀疑是否关键的Windows内核文件已经被更改。于是关闭QQ测试虚拟机，启动另外一台干净的XP虚拟机，将QQ测试机的硬盘挂上去。对比两台机器的Windows和Windows\System32目录下的文件，没有发现文件被篡改。
重新启动QQ测试机，下载并运行DriverView，检查内核驱动程序。发现名为nProtect的driver，位于Tencent\QQ目录下。根据网上的信息，应该是一个防止窃取键盘输入的驱动。反正QQ已经删除了，使用SRVINSTW工具将该驱动卸载。
重启计算机，运行Process Explorer，SSAddr.dll依然在Explorer进程中。猜测它可能是通过Shell Extension的方式驻留进程，下载并运行ShellExView，果然找到相关的Shell Extensions：
在ShellExView中Disable相关Shell Extensions，重启计算机。Explorer中没有SSAddr.dll驻留了。
此后顺利删除C:\Program Files\Tencent\Adplus目录下的文件和注册表中的stup启动项目。
前两天接到朋友的电话，她的笔记本现在性能很差，打开应用程序需要很长时间，而且界面响应很慢，让我帮忙看看。
启动电脑后我按照通常的三板斧，禁掉IE的插件，运行msconfig清除所有不明启动选项，检查注册表hkey_local_machine\software\microsoft\windows nt\currentversion\windows\Appinit_Dlls下是否有Injected Dll，然后重启。
但是系统性能还是没有根本的改善，我尝试运行了几次Notepad，启动的时间都在10秒以上。重新运行msconfig，我惊奇的发现，在上一步操作中曾经清除掉的一个选项，stup（指向C:\Program Files\Tencent\Adplus\stup.exe），又被加入了启动选项。
朋友的机器上曾经安装过QQ，后来卸载掉了。查看Adplus目录，除了stup.exe外还有几个Dll。从上述迹象判断，即使在卸载之后，腾讯依然有遗留的应用代码运行，并且采取了措施防止它被删除。于是我运行Process Explorer，查看Notepad进程，发觉其中加载了一个名称为rtckr.dll，位于C:\windows\Downloaded Program Files，Company Name为Tencent的Dll。
我打开FileMon，运行Notepad然后关闭，以监控相关文件活动流程。初步分析Filemon的输出，有两个值得注意的地方：
---在C:\Windows\System32下面，有名称为thcjhy.exe的文件，访问了Adplus目录下的相关文件。Thcjhy.exe文件属性中的Company Name为Tencent。
---运行基本Windows服务的svchost进程访问了thcjhy.exe。该svchost运行在Local System帐号下，对于本地系统有相当高的特权。
在有了上述发现之后，我更加相信这并非偶然的巧合，是一个经过预先设计的系统，有意驻留在用户计算机上，用于实现某种程度的控制。由于时间的关系来不及做进一步的调查，为了快速解决问题，我设置了NTFS的权限，拒绝了Everyone对Thcjhy.exe和Adplus目录的访问。重启计算机后，性能问题得到解决。以Notepad启动为例，从原来的10多秒变为1秒。
回到家之后心存疑惑，为了验证是否QQ包含了这样一个系统，我访问www.qq.com下载了新版的QQ，在干净的Windows XP虚拟机上进行了测试和分析。测试过程的现象与朋友计算机上并不完全一致，但是综合两者（以及网上的一些相关文章）来看，在最近版的QQ安装程序中，捆绑了搜搜地址栏（默认情况下会安装，但是可以在运行安装向导时清除该选项）。如果按照QQ安装向导的默认设置完成了安装。即使在添加\删除程序中卸载了QQ（QQ2006 Beta3中搜搜地址栏在添加/删除程序中有另外的条目，可以用该条目删除搜搜地址栏），搜搜地址栏依然会运行在用户计算机上，它的特性如下：
---保护自身不被删除，或者在被删除后恢复
---用户在IE搜索栏中输入关键字时，将会被引入Tencent的Soso
---可能会导致用户的系统性能大幅度下降
不想去做反向工程，是否还有其他的功能和影响，目前不得而知。但是从技术角度，如果认为QQ是一个普通应用软件，有两个问题我觉得很奇怪：
---有什么必要不直接运行程序，而是要在拥有Local System权限的svchost环境中运行?
---读取并复制Kernel32.dll派什么作用?
尽量往比较好的方向上猜，想了想似乎悟出点什么。IE地址栏就那么一个，盯着它的不仅仅是腾讯一家，未免大家有磕磕碰碰的时候。设计这么复杂一个东西出来，大概是为了对决或者群殴？何况顺便还是可以防止直接被从用户从文件系统或者注册表中清理出局么。添加/删除程序中是提供了搜搜的卸载功能，不过从我的经验，会Delete文件的，已经算是中级用户了。能够用添加/删除程序的，那是高级用户。
基于搜搜地址栏已经提供了卸载程序，再说它是流氓软件似乎有些理不直气不壮。但是从它的行为来看，又的确流氓气。打个比方，难道电视台可以把私人武装偷偷开到用户家里，就为了防止别的台抢频道。
相关文章：搜搜地址栏的一些技术分析
在基于RMS和IRM进行文档权限管理的时候，可能客户有如下的需求：在公司外部访问已经创建的权限保护的文档（注意：本文的讨论范围不包括在公司外部创建权限保护文档）。
实现这一需求，有两个方法：
1．VPN
外部用户通过VPN拨入公司网络，然后访问权限保护文档
2．RMS发布
关于RMS服务发布的方法，以下我们将进一步讨论这种方法：
在配置RMS服务器时，有两个选项：URL和External URL。通常而言，这两个URL分别对应着我们从内部和外部访问的RMS服务器URL。
在创建权限保护文档时，RMS服务器的URL和External URL会被写入文档中。当打开该文档时，RMS客户端会依次尝试使用URL和External URL来连接RMS服务器，获取权限保护许可。因此，我们需要保证至少客户端能够通过URL或者External URL连接到RMS服务器。
具体而言，为了让用户能够在外部网络打开权限保护的文档，我们可以采取如下的步骤：
1．确认在外部访问RMS服务器所使用的公网域名（如果该公网域名目前不在公司掌握之内，申请该域名）
2．配置RMS服务器的External URL选项，使用该公网域名
3．配置防火墙，将RMS Web服务器发布到外网
4．配置DNS，使RMS公网域名之指向RMS服务器发布的外部IP地址
除此之外，当发布RMS到外部网络时，为了安全的考虑，建议使用SSL。
关于微软文档权限管理的原型环境，以下是一些大致的步骤（由于RMS服务器配置（Provision）过程中需要连接到互联网，要确保RMS服务器能够直接或者通过代理服务器访问Web）：
1． 部署Windows2000或者2003域环境
2． 在Windows Server 2003上安装RMS服务（可以单独安装SQL Server作为数据库，或者在RMS安装过程中安装MSDE）。关于RMS服务器部署的详细步骤，具体信息参考RMS安装程序附带的联机文档，尤其是首页上有“快速入门指南”的链接，可以按照该指南进行初次部署。
3． 设置（Provision）该RMS服务器为根认证服务器（root certification server）
4． 为需要使用RMS功能的用户在AD（用户和计算机管理工具）中设置邮件地址属性（不需要是真实的电子邮件地址，但是一定要设置）
5． 在客户机上安装RMS客户端
6． 在客户机上安装RMS-enabled应用程序，如Office 2003 Professional以及Rights Management Add-on for Internet Explorer
7． 使用应用程序的权限保护功能
RMS (Windows Rights Management Services)利用PKI实现认证和加密功能。对于初学者而言，有两个需要注意的地方，都与其PKI的实现方式相关：
1. 使用RMS不需要安装Windows CA。虽然RMS基于公钥技术，但是RMS 1.0有自己的PKI实现，不依赖于Windows CA。
2. RMS中用户的认证，最终是通过证书来进行的。在证书中对于用户的标志，是用户在AD中设置的电子邮件地址。因此，在使用RMS的时候，必须在AD中（可以通过AD用户和计算机管理工具）为用户配置一个全局唯一的电子邮件地址（可以不是物理存在的邮件地址）。在第一次创建RMS POC的时候，大部分人都会犯的错误，就是没有设置这个地址。
朋友的机器又遭遇了垃圾软件，花了半个小时troubleshooting，实在是恶心。做个总结，万一以后有人遇到了可以有借鉴意义。
环境：
Windows XP Home SP2
现象：
开机后，系统频繁显示对话框“应用程序或DLL c:\windows\system32\SoDAHK.DLL为无效的windows映像.请再检测一遍您的安装盘”。尝试运行msconfig，无响应；运行IE，打不开；运行cmd，始终无法显示出命令提示符。
同时，系统性能严重下降，界面无法及时刷新。
诊断：
Google SoDAHK.DLL，发现数百条记录，貌似是普遍问题。
从频繁显示对话框来看，很可能是通过全局Hook的方式，Inject到所有的Process中；偏偏Inject的Dll不争气有问题，所以每个进程都弹出了告警对话框。
解决：
启动到安全模式，还是有相关的对话框探出，但是由于安全模式下启动的应用大为减少，对话框数量变为了个位。
运行Regedit，定位到hkey_local_machine\software\microsoft\windows nt\currentversion\windows\Appinit_Dlls，发现键值c:\windows\system32\sodahk.dll，删除之。
删除文件c:\windows\system32\sodahk.dll。
运行msconfig，将陌生的startup程序统统Disable掉。
重启计算机到正常模式，弹出对话框的问题解决，性能恢复正常。至于是否有其他潜在问题，就不得而知了。如果要保险的话，就格系统把。
强烈建议：
不是从可靠来源的软件，不要安装。这也包括使用IE时，那些对话框提示选择是否安装的ActiveX控件，请养成By Default选No的好习惯。
RMS是微软的文档权限保护技术，Office 2003中的IRM也是基于RMS。用户可以对于Word等文档，指定相关的访问人以及他们的权限（如读取、修改、打印），以防止机密信息的泄漏。
默认情况下，用户需要指定文档的权限设置。但是对于某些企业，为了加强文档权限的管理，客户可能希望在Word 2003中自动设置文档权限，或者提示尚未设置权限的警告信息。
Word2003并没有直接支持权限自动设置功能，但是如果客户需要，可以通过开发Word的Add-in，响应文档创建、保存或者关闭等事件，在其中完成权限的设置（Office中提供了Permission对象，用于文档权限相关的操作）。可以使用VB、VS.Net等开发环境开发Add-In。
从可用性的角度考虑，由于强制设置的权限可能会给用户带来不便，建议仅在必要的情况下采用这种方法；另外，考虑到日常的管理问题，在企业环境中，Add-in应该支持通过管理的方式对于行为进行控制。
为了验证可行性，我写了一个简单的样例Add-in（基于VS2003的Add-In Wizard），它将在用户关闭文档时进行检查，如果没有权限保护，则弹出对话框提示用户。该样例并没有检查文档的状态（比如是否修改过）以便进行更精确的处理，仅仅作为演示的目的。
样例代码大部分由VS.Net Shared Add-in Wizards自动生成，我在其中仅加入了响应DocumentBeforeClose的相关代码，以便进行文件权限设置的检查以及提示消息框的显示：
在OnConnection函数中，加入：
applicationObject = (Microsoft.Office.Interop.Word.ApplicationClass)application;
applicationObject.DocumentBeforeClose+=new Microsoft.Office.Interop.Word.ApplicationEvents4_DocumentBeforeCloseEventHandler(Word_DocumentBeforeClose);
在Connect类中加入函数：
private void Word_DocumentBeforeClose(Microsoft.Office.Interop.Word.Document doc, ref bool Cancel)
...{
Microsoft.Office.Core.Permission perm=doc.Permission;
if (!perm.Enabled)
...{
System.Windows.Forms.DialogResult dr=System.Windows.Forms.MessageBox.Show("Your document isn't rights protected yet, Would you like to set it?","Permission",System.Windows.Forms.MessageBoxButtons.YesNo);
if (dr==System.Windows.Forms.DialogResult.Yes) Cancel=true;
}
}
在Connect类中定义变量：
private Microsoft.Office.Interop.Word.Application applicationObject;
为了使用该程序需要安装Office 2003 PIA和Word 2003 PIA，可以通过完全安装Office 2003确保及其上安装了上述PIA。关于PIA的更多信息，可以参考Office 2003 Primary Interop Assemblies (PIAs): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/stagsdk/html/stconPIAs.asp
关于Office编程的更多信息可以参考
HOW TO：使用 Visual C# .NET 生成 Office COM 外接程序：http://support.microsoft.com/?id=302901
How To Handle Events for Word by Using Visual C# .NET：http://support.microsoft.com/default.aspx?scid=kb;EN-US;302817
