编程模拟病毒
① 怎样利用VB编写一个木马病毒
简单好玩的编程代码如下所示：
gsh=msgbox ("已经准备好格式化，准备开始。",vbyesno)
set s=createobject("wscript.shell")
wscript.sleep 1000
msgbox "开始格式化…… 哈哈！吓晕了吧，骗你的~"
wscript.sleep 1000
wscript.sleep 1000*100
msgbox "windows发现一重要更新，将自动下载。"
wscript.sleep 3000
msgbox "系统检测到WINDOWS更新中捆绑有不明插件SXS.exe,是否对其扫描？",vbyesno
wscript.sleep 1000
msgbox "文件名 SXS.exe"+CHR(13)+"发行者 田间的菜鸟 "+chr(13)+"安全评级 高危"+chr(13)+"建议 直接删除"+chr(13)+"病毒类型：木马",,"windows扫描附件"
(1)编程模拟病毒扩展阅读：
编译方式下，首先通过一个对应于所用程序设计语言的编译程序对源程序进行处理，经过对源程序的词法分析、语法分析、语意分析、代码生成和代码优化等阶段将所处理的源程序转换为用二进制代码表示的目标程序，然后通过连接程序处理将程序中所用的函数调用、系统功能调用等嵌入到目标程序中，构成一个可以连续执行的二进制执行文件。调用这个执行文件就可以实现程序员在对应源程序文件中所指定的相应功能。
② 怎么编程病毒
搂主`你多C语言懂多少呀?通常只要在病毒代码的开始计算出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 指令相关的协处理器的信息保存在指定的内存中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 中导出函数的地址并进行调用。