KZTechs.COM - Smallfrogs' Technical BLOG

一个奇怪的不能搜索的现象

smallfrogs — Mon, 06 Oct 2008 16:45:36 GMT

今天有一个同事的电脑上出现了问题，表现为不能搜索特定文件服务器上的文件，详情如下：

文件服务器FS和本地客户端是通过VPN连接的（不在一个物理地区），文件服务器的操作系统应该是Windows Server 2003（未经证实）。

在客户端这边，有一台XP系统，访问文件服务器FS的一个共享目录Share，访问方式是直接使用内网的IP访问，登录帐号是一个域帐号，域控制器在文件服务器所在的物理地区。

现象是这样的：

机器A使用Explorer，在地址栏输入\\IP\Share ，登录以后，Explorer 能够列举出共享目录里面的所有文件，而且很正常。
但是列表以后，点击机器A的Explorer的搜索按钮，文件名里面输入任何内容，点击搜索，都会返回搜索到0个文件。
把文件服务器FS的共享目录映射成一个驱动器，在机器A里面的命令行下面使用dir /s 命令搜索，没有问题。但是使用机器A的Explorer搜索隐射盘还是返回0个文件。
使用机器A的Explorer搜索本地磁盘里面的文件，一切正常。
使用机器A的Explorer搜索本地局域网里面的文件，一切正常。
换一台XP机器B，使用同样的访问方式、同样的域帐号访问文件服务器FS的共享目录，使用Explorer的搜索功能搜索，也很正常……
……

折腾了半天，没有搞定。比较奇怪，先记录下来，等有空的时候研究看看 Explorer 的搜索和普通的文件遍历有啥特别之处……

简单看了看机器A的环境，很普通，没有什么不正常的，我抓狂了……

捉鬼记：深入 Norton UAC Tool 实现原理

smallfrogs — Mon, 15 Sep 2008 12:29:00 GMT

张康宗（Smallfrogs）
http://www.KZTechs.com

刚刚看到 Asuka 的一篇文章《Norton UAC Tool原理剖析》，文章中已经很好的解释了Norton UAC是如何做到 Don't ask me again的，从开发的角度上看，这个要实现不是很难，但是我感兴趣的地方是： Norton 是如何把 Microsoft 的 Consent.EXE 给截获的，如果能够截获 Consent.EXE，就很容易实现 Norton 的功能了。

下面就让我带领大家深入这个工具的实现细节吧：

下载安装过程很简单，不停的Next就可以了。
安装完成以后，我找了一个会启动 UAC 的软件试了试，果然出现了 Norton 的 UAC 提示框。Microsoft Windows Vista 的那个 UAC提示框不见了。当时很诧异！！
当 Norton UAC 提示框正在询问的时候，用 Process Explorer 看了看进程，惊讶发现 Process Explorer 进程列表里面显示的是 Symconsent.EXE，但是这个进程的相信信息里面 Image 指向的是 Windows Vista 的 Consent.EXE。惊讶～～！

发现上述的内容，Smallfrogs 第一反应是想到碰到鬼了～
但是根据 Smallfrogs 多年的经验分析，得出这个“鬼”一定是人为的。看来 Norton UAC Tool 这个东东有搞头，于是乎马上振作精神，开始进一步的分析。
启动 Process Monitor，开始检测进程的创建过程，果然，鬼情出现了：在触发 UAC 的时候，Consent.EXE 进程加载的时候，Consent.EXE 会执行一个 LoadImage 动作，但是发现 LoadImage 对象不是 system32\consent.exe，而是 system32\symconsent.exe，如下图：

这是一个非常重要的现象，根据这个现象，Smallfrogs 当机立断，有东东做了 Hook。
使用 Image File Execution Options 技术，对 consent.exe 设置了调试器通知，确认在触发 UAC 的时候，系统的确调用了 consent.exe 进程，而且进一步发现，调试器模式下，挂接 consent.exe 进程以后，Norton UAC Tool 的提示框没有出现。

Smallfrogs 当时想：这只鬼很神奇啊～～难道要逼迫 Smallfrogs 做复杂、烦琐的内核调试吗？Smallfrogs 环顾四周，周围只有一台用了2年的本本，看来又要伤机器了。
正在准备开启VMWare的时候，Smallfrogs 突然想起忘记看看安装程序做了什么事情了，于是乎对安装程序 NUACx86.exe 进行了一个简单的分析，发现不就是一个普通的EXE嘛，而且这个EXE不是 symconsent.exe，看来这个EXE 有隐藏的东东。在 Exescope 的帮助下，果然发现 NUACx86.exe 有附带几个资源二进制文件，解出来一看，哈哈，这只鬼终于现身了。

Norton UAC Tool 安装了一个文件过滤驱动，叫做 SymAFR，当然，这个驱动通过了 Microsoft WHQL 认证（这只鬼做的还挺标准的），数字签名日期是 2008年2月29日 22:47:48。驱动的文件名叫做 SymAFR.sys。

Norton UAC Tool 可能是这样实现的（有不对的地方请大家指正）：

1、当 UAC 触发的时候，Windows Vista 尝试加载 system32\constent.exe。

2、SymAFR.sys 截获了这个操作，然后转而让系统加载 symconstent.exe。

3、symconstent.exe 成功的代替了 Windows Vista 的 constent.exe 进程，后面的事情就简单了。

4、验证方法很简单，执行 sc stop symafr 命令以后，再看看你还能够看到 Norton UAC Tool 的提示吗？呵呵。

Smallfrogs 评论：恩，这是一个非常巧妙的方法！实现简单，稳定，有效～

注意：Norton UAC Tool 是会把每一个触发 UAC 的程序的信息上报给 Norton 信息收集中心的。

--------------------------------

20080916 Update:

1、原文写的是 IEFO 劫持技术为笔误，实为 IFEO，即 Image File Execution Options
2、Exescope 是一个查看资源文件的工具，类似的还有 Resource Hacker 等
3、细心的朋友会发现，我的第一副截图里面的参数和 Asuka 的截图的参数不一样，他的截图里面指向的是一个 XML文件，针对这个问题，我做了一些分析，发现：当Norton UAC Tool 出现的时候，如果点击 Cancel，会创建一个新的 Symconsent.exe进程，新的进程的参数就是 Asuka 发现内容。新创建的 Symconsent.exe 进程应该是用于上报数据用的。感觉Gdier的报告！！

磁盘碎片整理以后出现 BOOTMGR is missing

smallfrogs — Mon, 08 Sep 2008 15:42:01 GMT

在昨天的文章里面，我提到我的系统在处理 MFT 表的时候用了近10秒钟时间，怀疑和磁盘碎片有关。虽然我一直在定期的对磁盘碎片进行整理，但是之前整理完成以后都没有测试过实际的用处。这次有了xperf工具，能够更准确的分析数据了。

由于涉及MFT相关的内容，而系统自带的工具是不能够整理MFT表的，因此我安装了 Diskeeper 2008，用这个软件对MFT进行整理。

Diskeeper 2008 的磁盘碎片整理是用一个 Native 应用程序实现的，启动时间应该是在 smss.exe 启动之后，Win32子系统启动之前。整理的过程很顺利，整理完成以后，系统重启，结果一重启，就提示我：

“BOOTMGR is missing, Press Ctrl+Alt+Del to restart”。

Bootmgr 是 Windows Vista 引入的一个新的引导组件。很明显，我的引导程序坏了。也就是说 Diskeeper 的 Boot Defrag 弄坏了 BootMgr 相关的记录信息。因为我使用的是 MFT 整理功能，看到这个提示以后，非常担心 MFT 表损坏。因为一旦 MFT 表损坏，整个系统盘的数据就丢失了。

解决方法：

找来一张 Windows Vista 安装光盘，用这个安装光盘引导机器
选择自动修复
经过漫长的等待以后，修复完成，提示重启
拿出光盘重启，熟悉的 Windows Vista 启动界面出现了……

弄完以后，我又搜索了相关的记录，发现还是有不少人出现了这个类似的现象。导致的原因大部分是因为使用了 Diskeeper 的 Boot Defrag 功能对MFT进行整理，最不幸的人是整理以后真的导致 MFT 损坏，结果C盘无法访问了……

这个软件的这个BUG真的很可怕……以后再也不使用这个功能了。

Windows Vista 性能分析：如何使用 xperf 获取精确的启动性能数据

smallfrogs — Sun, 07 Sep 2008 17:46:00 GMT

张康宗（Smallfrogs）
http://www.KZTechs.com

最近一段时间，我笔记本上Windows Vista的启动速度越来越慢了，启动时候的滚动条需要滚数十圈才能完成，而到 Explorer 显示完桌面，系统启动全部完成，需要4分多钟，已经慢的不可忍受了。本想重装系统，但是重装的代价也太大了，我需要重新配置太多东西，于是乎我就想如果找到启动性能的关键瓶颈，对这个瓶颈进行优化以后应该能够解决一些问题。

要解决问题，就需要准确的收集相关的性能信息，我们知道，在Windows XP时代，可以使用 Bootvis 工具收集相关的信息。

Bootvis：一个专门用于收集和分析 Windows XP 启动速度的工具。曾经很不幸的被错误的认为是 Windows XP 的启动速度优化工具。

但是由于 Windows Vista 内核体系的变革，加上全新的引导模式的引入，BootVis 肯定是不能胜任的，看来需要找到一个更好的获取 Windows Vista 相关性能数据的办法了。

Microsoft Windows Performance Toolkit（简称xperf），一个全新的Windows 性能分析工具在这个时候走入我的视线。

Microsoft Windows Performance Toolkit 是微软最近一段时间内推荐的丈量 Windows 性能的一个全新的工具，适合于 Windows Vista 或更高版本。最新版本是 4.1.1.1，可以在 http://www.microsoft.com/whdc/system/sysperf/perftools.mspx 免费下载到。

安装 Microsoft Windows Performance Toolkit 的过程非常的简单，安装完成以后，就需要开始收集相关的性能数据了。本次我关注的是 Windows Vista 的启动速度，因此我需要收集的是Boot阶段的数据。

用管理员模式启动 cmd.exe，然后进入 Microsoft Windows Performance Toolkit 安装目录，输入下面的命令：

xbootmgr.exe -trace boot

输入这个命令以后，xbootmgr 会自动重启系统，然后开始收集相关的启动信息数据。重启完成以后，xbootmgr 会等待 explorer 全部启动完成以后，生成一个日志文件（扩展名是：etl）到 Microsoft Windows Performance Toolkit 安装目录下面。下面我们需要对这个文件进行分析。

分析的过程有很多方法，最简单的方法就是进入命令行模式，切换到 Microsoft Windows Performance Toolkit 安装目录下，输入 xperf -i boot_BASE+CSWITCH_1.etl -o boot.xml -a boot 命令自动分析，然后输出一个 xml 的报告文件。这个

下面我要说的是一个更细致的分析过程。

打开 etl 文件：使用 xperfview boot_BASE+CSWITCH_1.etl 命令，会调用 xperfview 工具对 etl 文件进行详细的解析。etl 文件是 Microsoft Windows Performance Toolkit 原始的性能数据文件，里面记录了所有收集到的数据。
xperfview 解析完成以后，会看到类似于下方的图片：

找到 process lifetimes 分类（如上图），会发现到50多秒的时候，系统里面的第一个用户态进程smss.exe才启动（进程ID：748），之前的时间都花费在 system 上。换句话说，运行在内核态的各种驱动程序，包括 Windows 内核和执行体用了 50 多秒才完成启动子系统之前的初始化动作，这个时间花费的也太长了。
由于初始化 Windows 内核和执行体等动作用了 50 多秒，这个非常的不正常，因为我们需要看看在这50秒内的详情。

在 Disk Utilization by process 里面，选择 0-50 秒这个时间段：
然后点击鼠标右键，选择 Detail Graph，会出现下面的图：
在这个图片里面，可以看在 0-50 秒内磁盘访问最高的区域是什么，C盘中间部分的访问频度非常的高。更细致的数值分析就需要使用另外一张报表了。
在 Disk Utilization by process 里面，还是选择 0-50 秒这个时间段：点击鼠标右键，选择 Summary Table，xprefview 会显示如下图所示的报告，这个报告对于分析性能分析来说，会显得会更为直观一点。

这张图标给了我们一个非常详细的性能分析和解释数据。在 0-50 秒时间内，system 进程花费了 42445587.434 us 的时间，其中，花费最多的时间是在处理 MFT 表的时候，尽然用了近10秒的时间。
根据上面的数据，我们已经找到了在启动最开始的50秒时间内，有10秒钟的时间花费在了出来MFT表上面，另外，读取一些字体文件的时间也非常的慢。
知道数值以后，后面就是优化过程了。根据 xperf 给出的数据初步判断：开机慢的原因和文件IO速度变慢是相关的。有人会问，而影响文件IO速度慢的原因有很多，但是请注意一点，在前50秒内，由于没有任何的用户态进程介入，因此IO速度慢的原因就很简单了，大部分原因是因为磁盘碎片导致的，也有可能是由于硬盘坏道导致的。根据 xperf 的数据，处理MFT表用了10秒钟时间，如果能够把MFT的处理时间加快，同时减小碎片数量，系统的启动速度就能加快不少了。

在进行系统性能优化和分析的过程中，数据的收集是至关重要的。业界有很多性能数据收集工具，Microsoft也出了不少类似的软件，但是易用性都不是很好。Microsoft Windows Performance Toolkit 作为一款新型的面向于Windows Vista 或更高平台的性能工具，以其简单的操作和友好的界面，希望能够得到更多的使用和更广泛使用。

在本次的 Windows Vista 性能分析里面，我介绍了一个使用 xperf 对Windows Vista 启动速度进行分析的过程，在后续的 Windows Vista 性能分析系列BLOG文章里面，我还会持续关注在更多的和 Windows Vista 性能相关的话题上面，希望能够让大家对 Windows 性能有一个更好的认识。

IE8 新特性分析：IE8的稳定性源自何处

smallfrogs — Thu, 28 Aug 2008 03:58:54 GMT

MS宣称IE8增强了很多稳定性方面的改进，今天我抽了点时间，对这个问题进行了一个分析。

从Windows 2000开始，Windows提供了一种新的机制对多个进程进行统一的管理。这种机制被命名为Job（作业）。作业的一个最大特点是能够对一个进程组进行统一的管理。

对比之前IE版本的多标签页实现，之前版本的每个Tab页是基于线程的方式进行的，这种方式最大的问题是一旦某一个线程发生问题，整个IE进程都会出现问题。而且这种问题是很难彻底解决的。在IE8里面，MS终于把Job（作业）的思想进行了一次比较大规模的运用，每一个（或几个）Tab页会对应一个进程，然后有一个总的进程进行管理（如下图）

这种设计的好处就是一个Tab崩溃以后，只会影响这个Tab，对于其他的Tab是不影响的。同时，最外面的框架进程能够知道子Tab的情况，也就能够很好的实现“灾难恢复”了。

下面是父框架进程和子进程的启动参数的不同，可以看到，Job里面的进程是通过一些特殊的参数进行启动的。

当然，IE8的这种结构也带来了一些问题：

从开发的角度上看，带来的最大问题就是进程间的通信和管理问题，不过我相信，这一点对于恐龙级别的MS来说是小菜一碟了。
从用户的角度上来看，进程对资源的消耗还是很大的。换句话说，同样的浏览模式，IE8对内存资源的消耗应该会大于IE7或者更早的版本。换来的好处是更加的稳定。

IE8，Good！

Smallfrogs
http://www.KZTechs.com

Hyper-V 网络故障存档

smallfrogs — Mon, 07 Jul 2008 17:05:38 GMT

上周，我在公司环境里面部署的2台Hyper-V RTM服务器里面，有一台出现了问题，问题现象是：虚拟机里面的网卡无法从DHCP服务器获得IP地址，在虚拟机里面使用 ipconfig /renew 命令，报告无法找到 DHCP 服务器，重启虚拟机也无法解决问题。

整个过程是这样的：

我的一台基于Realtek 网卡的Hyper-V服务器外接的交换机出现问题，导致Hyper-V服务器断网了，同样，Hyper-V里面运行的虚拟机的网络也断了。这台Hyper-V服务器和里面的虚拟机的IP获取方式均是通过外部的DHCP服务器获取的。
经过数十分钟以后，网络恢复了，Hyper-V服务器的网络恢复正常，但是奇怪的是，3台虚拟机里面的网络都未能恢复。
我先怀疑是虚拟机的问题，于是用ipconfig/renew命令和重启，均未能维护网络。
由于Hyper-V服务器上还运行着其他自己编写的服务端程序，不能重启系统，于是我重启了Hyper-V的网络管理服务，结果无效。
最后不得已，我重启了Hyper-V服务器，重启以后，虚拟机里面的网络终于恢复了。

由于当时的时间很紧，我没有研究具体的原因，仅仅是找到了一个解决方法，今天把过程记录下面，大家可以看看具体原因是怎么回事？我目前也不知道。只不过感觉和网卡有关，因为我另外一台使用的是Intel网卡Hyper-V服务器，就没有碰到类似问题。

AppInit_Dlls，一个特殊的注册表键值

smallfrogs — Sun, 15 Jun 2008 18:25:58 GMT

Smallfrogs
http://www.KZTechs.com

如果你对计算机安全有所了解，那么各种各样的注册表启动项应该会有所了解，今天我会细述一个很著名的启动项：AppInit_Dlls键值。

AppInit_Dlls键值位于注册表 HKLM\Microsoft\Windows NT\CurrentVersion\Windows下面，相对于其他的注册表启动项来说，这个键值的特殊之处在于任何使用到User32.dll 的EXE、DLL、OCX等类型的PE文件都会读取这个地方，并且根据约定的规范将这个键值下指向的DLL文件进行加载，加载的方式是调用 LoadLibrary。

验证方法有很多，最容易想到的就是使用调试器，在LoadLibrary调用的时候下断点，你会发现User32.DLL读取了这个键值并且使用了LoadLibrary去调用这个键值指向的DLL文件。一个更好的方法就是看看 KB197571 的介绍了。

AppInit_Dlls的键值是一个非常危险的键值，从某种程度上来说，这是一个Windows最容易被人利用的漏洞，因为只要有任何的恶意软件在这里进行了修改，那么就意味着任何使用到User32.DLL的进程都会被AppInit_DLLs指向的DLL所注入。因为进程内部的DLL是共享整个进程空间的，因此意味着进程里面的DLL是可以控制整个进程的行为的。由于User32.DLL是一个非常非常通用的DLL，它提供了大多数Win32用户界面、消息相关的功能，只有极少数的程序不会使用User32.DLL，因此一旦有恶意软件修改了AppInit_Dlls键值，那么整个系统都有可能处于非常危险的状态。

众所周知，Windows服务程序的启动时机是可以非常早的，往往在用户登录之前就完成启动了，而这个时候最常见的Run键值还不一定被处理完，而且Windows服务程序拥有相当高的权限（默认是Local System，可以对系统里面所有的资源进行操作），因此如果一个恶意软件被加载到Windows服务里面，那么是会非常危险的。前文提到，任何进程使用了User32.DLL，都会对AppInit_Dlls键值指向的DLL进行加载，如果是一个Windows服务程序，也不例外！

由于AppInit_Dlls是一种系统全局性的Hook（system-wide hook），要规避此类的Hook的确很困难，虽然使用驱动程序进行保护能够规避此类问题，但也不是非要使用驱动程序进行处理的。前文说过，只有当使用到User32.DLL这个模块的时候才会触发读取AppInit_Dlls指向的DLL，如果不使用User32.DLL，那么AppInit_Dlls是不会被使用到的。但是要让一个程序不使用User32.DLL会变得非常困难（命令行窗口没有使用User32.DLL），因为任何的窗口、消息都和这个模块有关，为了保证有良好的用户体验，100%的窗口程序都和这个模块有关。从开发角度来说，最好的一种解决办法就是将程序功能逻辑和界面逻辑完全分离，功能逻辑模块负责功能，界面逻辑模块负责界面显示，2者之间采用IPC机制进行交互，功能逻辑模块不依靠User32.DLL,，而且作为独立进程进行处理，这样就可以规避AppInit_Dlls造成的Hook了。

类似的Windows安全相关的缺陷点其实还有很多的，这些缺陷点的来源是为了保证向下的兼容性。相信MIcrosoft已经发现并正在修补这些地方，从Windows Vista上可以看到，AppInit_Dlls的键值在Windows Vista上是不起作用的，因此在Windows Vista里面，这个键值已经被抛弃了（改用另外一个键值执行类似的功能，但是增加了基于UAC的安全防护）。

Hyper-V RC1 升级补丁安装记

smallfrogs — Thu, 05 Jun 2008 15:16:32 GMT

惭愧啊，本blog很久不更新，都长草了。

最近几个月实在忙得厉害，今天抽出1个小时更新一下最近的流水账吧。

由于工作环境的需要和出于对新技术的追求，最近我一直在研究基于硬件级别的虚拟机，说是研究，实际上还停留在很肤浅的应用层次。研究的对象是 Windows Server 2008 里面的Hyper-V虚拟机组件。

由于今天时间的关系，关于Hyper-V虚拟机组件的一些心得今天就没有时间和大家分享了，今天提及的问题是关于 Hyper-V RC1 升级补丁的安装问题。

Hyper-V RC1 补丁放出来很长一段时间了，我在发布的第2天就下载并进行了安装，安装过程进行了重启，重启以后，当时我很惊讶的发现虚拟机启动的时候还是显示着 RC0 的字样，当时我猜想是不是MS的显示错误，也就没有多关注，认为我已经把Hyper-V RC1补丁安装成功了。

但是今天我检查 WindowsUpdate 日志的时候，居然发现有一个Fail。一查，居然是在安装 Hyper-V RC1 的时候报告的安装失败。错误代码是：0x80070020。

既然安装失败了，那好，我再来安装一次，运行RC1安装包，一切正常的操作结束以后，重启以后发现还是提示安装失败，比较奇怪哦。

第二次尝试，把正在运行的2个虚拟机关闭，运行RC1安装包，一切正常的操作结束以后，重启以后发现还是提示安装失败，大惊。

算上第一次的失败，安装Hyper-V RC1升级包连续失败了3次了，好奇心油然而生，我就不信我搞不定这个补丁的安装。也罢，祭出本人法宝：Microsoft Exchange Server Error Code Look-up Tool，查询看看 0x80070020 错误号代表的字符串含义，查询到的结果是 STIERR_SHARING_VIOLATION，恩，共享违例。

知道错误号的详情以后，我就知道安装失败的原因了：安装的时候文件没法替换成功。解决方法也很简单：

关闭虚拟机；
停止Hyper-V相关的3个服务；
将上述3个服务的启动类型从自动改为手动；
运行Hyper-V RC1 升级包安装

执行上述操作以后，重启以后，哈哈，成功升级到Hyper-V RC1，然后再把3个服务启动类型设置为自动，启动这3个服务，启动虚拟机，一切恢复正常。

再回过去看看KB知识库的描述 KB450049，上面写的是：

...

All virtual machines must be shut down correctly before you install the Hyper-V Release Candidate 1 update

...

仅仅执行上述操作好像不行啊，不知道这篇KB的作者有没有自己尝试过呢？呵呵。

顺便抱怨一点的是，Hyper-V虽然提供了上层和底层两套API接口，底层的接口层次太低了，我不需要这么低的，而对于上层的接口，功能不够，虽然是基于WMI的，但是我跟喜欢纯C的接口类型，不知道是否是因为我跟不上时代的进步了。

BTW：Hyper-V RC0 挺稳定的，我的测试环境部署了2套虚拟机（Windows XP SP3 和 Windows Vista SP1），每天这2个虚拟机里面的工作环境会执行非常复杂的任务，每天需要从6：00——24：00连续执行任务，而且有大量的重启任务和高负载任务，但是经过这么多天的试用，运行Hyper-V机器没有发生过任何的不稳定情况，还是很不错的。

下次，我会进一步把现阶段学习到的知识分享给大家，时间上我尽可能在近期完成吧，敬请期待。

Smallfrogs
http://www.KZTechs.com

Microsoft Windows Vista UAC 之数字签名认证

smallfrogs — Wed, 05 Mar 2008 15:55:07 GMT

Smallfrogs[张康宗]
http://www.KZTechs.com

2007年12月份的时候，我曾经撰写过一篇文章《Windows Vista UAC 和可信任安全》（http://blogs.itecn.net/blogs/smallfrogs/archive/2007/12/31/windows-vista-uac.aspx）。文章中对4种UAC提示框分别作了一个说明，今天，我们继续这个话题，说说UAC提示框里面的数字签名认证部分的内容。

Windows Vista里面数字签名认证对于用户层和内核层是不同的，这一点我提前说明一下。

众多周知，UAC的用户态提示框是consent.exe进程触发的。UAC提示框会检查进程的数字签名信息，对于被信任的进程会显示绿色（系统模块）或者灰色（有数字签名的第三方模块），对于未知的数字签名信息显示黄色，对于被阻止的数字签名信息显示红色。

那么Windows是如何检测数字签名的呢？实际上，Windows内置了很多受信任的根证书，只要使用这些根证书对文件进行数字签名签署操作，就可以让Windows Vista这个文件所信任。

用KZTechs.COM - FileDigitalSignVerify工具扫描Windows Vista Windows目录，会发现所有的系统文件都是有数字签名的，签署者可能是 Microsoft Windows，也可能是 Microsoft XXX。对于使用Microsoft Windows证书签署的模块，UAC提示框一定是绿色的。如果不行，可以运行 regedit.exe 看看 ^_^

但是，有一个特例：IExplore.EXE。如果你用 Run as Adminisrator 方式启动IExplore.EXE，你会看到一个黄色的UAC提示框。

难道是IExplore.EXE没有数字签名？不，IExplore.EXE也有数字签名的，用KZTechs.COM - FileDigitalSignVerify (http://www.kztechs.com/filedsv/)工具可以清楚的显示数字签名相关信息以及证书链信息。

下图是使用 KZTechs.COM - FileDigitalSignVerify 工具 1.2 版本对 regedit.exe和iexplore.exe这2个文件的数字签名信息进行检查：

绿色部分是对iexplore.exe检查的结果，下半部分是对regedit.exe检查的结果。-p 参数是显示证书链信息。

从上图的证书链可以看到，这2个文件都被Microsoft Windows的数字签名所签署，而且证书是有效和合法的。而 Microsoft Windows 证书是由 Microsoft Windows Verification PCA 证书颁发的，而 Microsoft Root Certificate Authority 证书颁发了 Microsoft Windows Verification PCA 证书。Microsoft Root Certificate Authority 作为根证书，是被系统所信任的。

那么为什么以Run as Adminisrator 方式启动IExplore.EXE，你会看到一个黄色的UAC提示框？

我用google进行了相关搜索，结果是：未知

难道是Microsoft BUG？

Smallfrogs
http://www.KZTechs.COM

Windows Vista SP1 清理工具 vsp1cln.EXE 揭秘

smallfrogs — Mon, 03 Mar 2008 18:00:00 GMT

本文含有危险动作，仅供学习使用。本文所列数据或方案未经严格测试，仅供参考。

Microsoft在Windows Vista SP1 WAIK里面附带了一个新的工具：vsp1cln.EXE。这个工具是用于：在Vista RTM环境里面安装SP1之后，将Vista RTM文件清理用的。主要是给那些不再卸载Vista SP1的用户。

这个工具有594KB，体积不小，但是我更关心的是他的实现原理，经过简单的分析以后发现，vsp1cln.EXE的实现原理很简单，vsp1cln.EXE内置了所有的Vista RTM文件列表数据。

用资源编辑工具打开vsp1cln.EXE，会发现一个资源ID为256的节点，展开一看是一些很熟悉的字符：

对Windows熟悉的人一看就知道上述字符串是WinSxS的命名方式，换句话说vsp1cln.EXE的主要清理功能的数据来源就是上述列表。上述列表每一行对应一个Windows\WinSxS下的子目录。我统计了一下上述列表所对应的子目录全部加起来以后的文件大小：1445MB，基本符合执行vsp1cln.EXE以后的磁盘空间增加范围。vsp1cln.EXE的基本逻辑就那么简单，但是从引入表可以发现，vsp1cln.EXE实际上还会执行其他的动作，删除文件仅仅是一个中间的过程而已，呵呵。

Smallfrogs
http://www.KZtechs.com

Internet Explorer 7.0 的安全模式

smallfrogs — Sun, 02 Mar 2008 15:25:23 GMT

Windows 操作系统有安全模式，这一点大家都清楚。但是在IE7里面，Microsoft也引入了一种针对IE的安全模式。

如果我的记忆没有发生错误，那么从XPSP2开始，Microsoft就在IE里面引入了IE Addons管理功能来管理加载在IE里面的插件。

通过这个IE Add-ons设置，可以管理所有加载在IE里面的插件。

但是一个正常的IE里面，会存在很多很多很多的Add-ons，其中有微软的，也有第三方的。一个一个禁用显得非常麻烦，所以在IE7里面，Microsoft增加了一个开关用于控制IE add-ons。

在命令行提示符下运行：
"C:\Program Files\Internet Explorer\iexplore.exe" -extoff

将启动一个IE7的特殊模式：无插件模式。

在这个模式下，所有的插件将全部临时被禁用。而你不再需要一个一个的在add-ons界面里面禁用插件了。

Smallfrogs
http://www.kztechs.com

Windows Vista SP1 = Windows Server 2008

smallfrogs — Fri, 15 Feb 2008 15:58:51 GMT

不知道大家是否已经安装了Windows Vista SP1和Windows Server 2008。作为Windows Beta Tester，Smallfrogs 很早就安装了 RTM 版本的 Windows Vista SP1和Windows Server 2008。

安装完成 Windows Server 2008 以后，按照惯例，我首先会检查各个重要文件的版本号，结果发现：Windows Server 2008 RTM版本的系统重要文件的版本号、MD5值和 Windows Vista SP1 RTM 完全一致！

换句话说，Windows Server 2008 和 Windows Vista SP1 都建立在同一个平台上面。如下图所示：

依靠上述的层次结构，Microsoft能够大量的简化软件的研发代价，对于底层软件的开发商来说，也能够降低大量的开发和测试代价，对于用户来说，由于Windows 体系架构决定了大量的底层功能是在Core里面完成的，因此对于用户来说，Windows Vista SP1 和 Windows Server 2008 的底层功能和底层性能是完全一样的。换句话说，Microsoft是利用各种注册表设置和上层的文件差异来区分 Server 版本和 Client 版本的。

Smallfrogs
http://www.KZTechs.com

[2007/02/16 20:54 Update]
我简单统计了一下，总共有 3965 个PE文件（EXE、DLL、SYS、OCX等）文件是一样的，其他非PE文件我没有统计。

另外，Windows Server 2008 RTM Symbols 已经放出，从 Symbols 分析也可以得出 Windows Server 2008 和 Windows Vista SP1 底层文件完全一致。

Windows Vista UAC 和可信任安全

smallfrogs — Mon, 31 Dec 2007 09:28:54 GMT

Smallfrogs[张康宗]
http://www.KZTechs.COM

Level 200

UAC，Windows Vista 里面重要构成部分。对 Windows 安全保护起着绝对重要用途。

但是，UAC 不等于绝对安全，当你碰到UAC提示框的时候，请千万小心后面的陷阱：

众所周知，UAC提示框触发的时候，Windows 会检测新创建进程映象文件的数字签名：

如果新创建的进程的数字签名被阻止了，那么会显示一个红色的提示框：

如果新创建的进程没有合法的数字签名，那么会显示一个橘黄色的提示框。

如果新创建的进程拥有一个受信任的第三方数字签名，那么会显示一个灰色提示框。

如果新创建的进程拥有一个受信任的Microsoft数字签名，那么会显示一个绿色的提示框。

随着今后Windows Vista用户量的增多和培训的努力，大多数用户对于UAC的提示框都产生了一种条件反射：对于灰色或者绿色的UAC提示框完全信任，直接点击Continue按钮了。

这种做法产生了一种严重的安全问题点：UAC检查的是新创建的进程的映象文件。如果这个新创建的进程通过了UAC检查，那么他将获得完全的管理员权限，也就是说这个新创建的、通过UAC检查以后的进程，再创建其他的子进程，将不会触发UAC提示。

换句话说，如果利用某种手段，就可以让一个危险程序隐蔽的运行起来，而用户看到的UAC提示框不是直接针对这个危险程序的。

操作步骤：

在《如何将自身进程运行为admin模式》文中我说过，利用ShellExecute可以创建一个显式需要完整管理员权限的进程。
因此，我创建了一个Demo程序，显示的将命令行解析器 cmd.exe 创建为拥有完整管理员权限的进程。
先前说过，当一个进程拥有了完全管理员权限以后，它创建的子进程即使会触发UAC动作，也不会看到了。利用这个特性，我的Demo程序成功的将显示需要完整管理员权限且一定会触发UAC提示的 SREng 主程序创建起来了，且看到的UAC提示不是 SREng 的。

代码片段：

TCHAR szPath[] = _T("c:\\windows\\system32\\cmd.exe");
TCHAR szParam[] = _T("/c start d:\\Smallfrogs\\Codes\\SREng\\Product\\SREngPS.EXE");

ShellExecute(NULL, _T("runas"), szPath, szParam, NULL, SW_SHOW);

编译上述代码，运行以后会看到一个很有意思的现象：我希望运行SREng，但是不想看到SREng 的UAC，因此我用 cmd.exe 的UAC代替了SREng的UAC提示（如下图所示）：

大多数用户看到上述的UAC提示框的时候，都会点击Continue按钮，因为UAC提示框是绿色的，很少有用户会点击 Details 按钮，因为这个按钮很不显眼。但是当我们点击Details按钮以后，我们会看到别有一番天地：

Details里显示：程序利用 cmd.exe 的 /c 参数创建SREng进程，而 cmd.exe 又被显示的被赋予完整管理员权限，因此 cmd.exe 创建的 SREng 进程也继承了 cmd.exe 的管理员权限，且不会出现 UAC 询问对话框。

利用上述方法，UAC 提示框被成功替换了。

解决方法

既然我今天公布了这个方法，那自然会公布相应的解决方法：碰到UAC提示的时候，切记一定要点击 Details 按钮，看看命令行参数。如上图那样，如果看到 cmd.exe 后面跟了一些不属于预期内容的参数，请不要点击 Continue 按钮，否则UAC这层脆弱的防护措施就失效了。

强烈建议每次看到UAC提示框，无论什么情况，都点击Details按钮看看，以免恶意程序神不知鬼不觉的被运行了。

Smallfrogs
http://www.KZTechs.COM

IE7 for Windows Vista 内存泄漏？

smallfrogs — Wed, 26 Dec 2007 17:44:29 GMT

自从Windows Vista RTM的那天起，我的工作系统就换为Windows Vista了。

运行Windows Vista的机器配置应该算不错了，除了显卡一般以外，2G的物理内存以及足够Windows Vista流畅运行了。

但是我对 IE7 for Windows Vista 却异常郁闷，我明显的感觉到 IE7 for Windows Vista 有内存泄漏。

表现：

打开一个IE进程，主页为about:blank，检测这个时候的内存占用。
新建一个标签页，主页为about:blank，检测这个时候的内存占用。
关闭刚刚新建的标签，检测这个时候的内存占用。
重复2和3动作多次以后，观察内存占用曲线，会发现呈现的是一个递增的曲线。我知道可能有人会解释说是缓存的缘故，但是即使是缓存也不应该出现递增的趋势的，因为我已经把自己创建的新Tab关闭了。

下图是我运行IE近20分钟以后，打开多个TAB，然后关闭以后的内存占用量：

Working Set 居然占用了 200 多M。有人可能认为是IE的插件导致的，我最初也是怀疑是IE的插件导致的。但是当我使用插件管理器把所有第三方插件全部禁用以后，观察，内存还是呈现递增趋势。

内存递增不是最关键的问题。最麻烦的问题是：

当内存使用量上升到一定程度是，就不能再创建任何新的窗口了（这里说的窗口表示所有的窗口程序），必须关闭一些标签才能打开新的窗口（例如任务管理器）。

窗口的限制应该是Windows Vista 自身的一个机制导致的，我目前没有找到一个能够量化的指标。不过在我机器上，当IE进程的Working Set 到达 280M 左右的时候，我就不能够再创建任何窗口程序或者新建IE的标签页了。这个时候很有可能没法正常的关闭IE的全部标签页，最后我的解决方法是：结束IE进程。

由于IE这个麻烦的内存泄漏（至少我认为是这样的），我不得不写了一个小程序常驻内存，检测IE进程的内存使用量。如果达到一定的阀值就提示我准备关闭现有的IE进程，新建一个新的IE进程了。

Smallfrogs
http://www.KZTechs.com

如何将自身进程运行为admin模式

smallfrogs — Fri, 07 Dec 2007 00:02:38 GMT

张康宗
http://www.KZTechs.COM

Level:300

在Windows Vista里面，进程是分权限级别的。Windows会根据manifest内容、Windows Installer detection、兼容性数据库等方法判断一个进程是否需要一开始就运行在完整admin模式下。

但是不是所有的程序一开始就需要运行在完整admin模式下的，例如任务管理器TaskMgr.EXE。在Windows Vista里面，启动任务管理器以后，默认只能显示当前账户相关的进程信息，只有当点击下面这个按钮并回应UAC提示以后才能显示所有用户的进程信息：

请注意上面这张图片，Show processes from all users 按钮前面有一个Windows 安全中心的图标。这个表示这个操作需要触发UAC。这个倒是没有什么特别的。问题的关键在于：TaskMgr是怎么触发UAC的？

我们知道，一个没有完全admin权限的进程是没法直接创建更高权限进程的，也就是说一般权限下的进程是没法直接创建完全Admin权限进程的。因此CreateProcess API函数肯定是不能使用的。如果使用CreateProcessAsUser函数，那么需要提供一个比较高的令牌才能完成，这个需要有额外的来源，而TaskMgr显然不具备这种能力。那TaskMgr是怎么完成这个神秘的动作呢？

上述问题我思考了数个月，上网搜索也没有搜索到有价值的内容。直到昨天晚上才有空去调试一把，看看到底是怎么玩的。

我用windbg attach到 taskmgr 进程上，然后把所有的进程创建相关函数全部设置了断点，然后点击Show processes from all users 按钮，结果ShellExecuteExW函数被断下了，难道ShellExecuteExW有什么特殊的地方吗？查阅最新的MSDN关于ShellExecuteExW的说明文档，什么介绍都没有。是断点有问题吗？

继续使用windbg单步调试，当程序执行到下图的时候，有一个看起来很关键的函数调用：

call SHELL32!ShellExecuteNormal (7656e6ce)，看到这个名字我的第一个直觉是这个是真正的执行函数，前面还有很多操作仅仅是一些检查步骤。当执行完call SHELL32!ShellExecuteNormal (7656e6ce)指令以后，UAC框弹出了。看到UAC框的弹出，我已经可以确认任务管理器是使用ShellExecuteExW某个在MSDN上面没有公开的操作触发UAC的。根据前面的描述，call SHELL32!ShellExecuteNormal (7656e6ce)指令是一个关键指令，因此需要检查call SHELL32!ShellExecuteNormal (7656e6ce)指令之前的参数操作。

呵呵，这回我盯上了push esi指令了。

windbg里面查看esi对应的内存内容以后发现可能是一个结构体，由于是ShellExecuteExW函数里面执行的，因此我猜测这个结构体是 SHELLEXECUTEINFO，对照SHELLEXECUTEINFO结构体的定义，果然和esi内容相符。最后一步就是检查结构体里面各个参数的情况了。当我发现LPCTSTR lpVerb指向的参数内容（db 0xe5d93c命令）是“runas”这个字符串的时候，Taskmgr 将自身提示为完全admin权限的方法也就揭晓了：

在Windows Vista里面，ShellExecuteExW lpVerb的参数可以传入runas命令，使得系统调用 ShellExecuteExW 的时候，会强制将目标文件以完全admin模式启动，即使目标文件的manifest没有申明需要完全admin权限。

效果等同于在目标程序上右键点击，然后选择 run as administrator 菜单内容。

幕后：当全部搞定以后，我上网google了一下，发现这个方法早有人提及了，而且还是在 Vista Compatibility Team Blog 上面，我花的1个多小时全部白费了，为啥先前都没有搜索到呢？？郁闷。

KZTechs.COM - Smallfrogs' Technical BLOG

一个奇怪的不能搜索的现象

捉鬼记：深入 Norton UAC Tool 实现原理

磁盘碎片整理以后出现 BOOTMGR is missing

Windows Vista 性能分析：如何使用 xperf 获取精确的启动性能数据

IE8 新特性分析：IE8的稳定性源自何处

Hyper-V 网络故障存档

AppInit_Dlls，一个特殊的注册表键值

Hyper-V RC1 升级补丁安装记

Microsoft Windows Vista UAC 之数字签名认证

Windows Vista SP1 清理工具 vsp1cln.EXE 揭秘

Internet Explorer 7.0 的安全模式

Windows Vista SP1 = Windows Server 2008

Windows Vista UAC 和 可信任安全

操作步骤：

解决方法

IE7 for Windows Vista 内存泄漏？

如何将自身进程运行为admin模式

Windows Vista UAC 和可信任安全