MIME协议(六) -- MIME实例分析

MIME实例分析

了解MIME协议的基本组织结构后，下面用Outlook Express撰写出一封显示效果如图4所示的电子邮件，然后分析该邮件的源文件，以便读者更加深入地了解MIME协议。

1. 启动Outlook Express，单击工具栏中的“创建邮件”按钮，在打开的“新邮件”对话框中输入收件人地址、主题和邮件正文，然后选中邮件正文，单击编辑窗口的工具栏上的“》”按钮，在弹出的菜单栏中单击表示超链接的图标，如图7所示。

图7

2. 在打开的“超级链接”对话框中输入如图8所示的内容，然后单击“OK”按纽。

图8

3. 再次单击编辑窗口的工具栏上的“》”按钮，在打开的如图7所示的菜单栏中单击表示图片的图标，在打开的“图片”对话框中单击“浏览”按钮，然后通过打开的对话框选择一个图片文件，结果如图9所示。

4. 单击图9中的“OK”按钮，结果如图10所示。

图9

图10

5. 单击图10所示窗口中的“插入”“文件附件”菜单项，在打开的“插入附件”对话框窗口中选择需要发送的附件，如图11所示。

单击“附件”按钮，插入所选中的附件。

6. 单击图10所示窗口中的“文件”“保存”菜单项，在Outlook Express主窗口的“草稿”目录中就可以看到这封邮件，如图12所示。

图11

图12

7. 将这封邮件从“草稿”目录中移动到“发件箱”目录中，接着按照1节中讲解的查看邮件源文件步骤，打开刚才撰写的这封邮件的源文件。或者在“草稿”目录中选中这封邮件，将它另存为一个eml文件，再用任意一种文本编辑程序打开这个eml文件，这样也可以查看到刚才撰写的这封邮件的源文件。为了便于读者看清邮件内容的组织结构关系，笔者专门为此画了一个描述邮件中的各个MIME消息分隔符的层次关系的示意图，如图13所示。

从图13中可以看出，在MIME组合消息的消息体中的每个消息单元都要以一个分割符开始，在组合消息的消息体结束时还需要用一个结束分割符。MIME消息中的分隔符的层次关系与一篇文章中的标题之间的层次关系非常相似，只是在每个组合消息结束时还要增加一个结束“标题”。为了便于讲解，笔者对刚才撰写的邮件源文件内容进行了适当修改，并添加了相应的注释，如下所示：

图13

1：From: "it315" <it315_test@sohu.com>

2：To: <it315_test@sohu.com>

3：Subject: =?gb2312?B?TUlNRdCt0unLtcP308q8/g==?=

4：Date: Thu, 1 Dec 2005 20:46:53 +0800

5：MIME-Version: 1.0

6：Content-Type: multipart/mixed;//定义邮件体类型为mixed

7： boundary="----=_NextPart_000_0050_01C"//定义整个邮件内容的分隔符

8：X-Priority: 3

9：X-MSMail-Priority: Normal

10：X-Mailer: Microsoft Outlook Express 6.00.2900.2670

11：X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670

12：

13：This is a multi-part message in MIME format.//邮件注释

14：

//整个邮件内容的第一部分（即邮件正文）的开始标记

15：------=_NextPart_000_0050_01C

16：Content-Type: multipart/related;

17： type="multipart/alternative";

18： boundary="----=_NextPart_001_0051_01C"//定义邮件正文内部的分隔符

19：

//邮件正文内部的第一部分的开始标记

20：------=_NextPart_001_0051_01C

21：Content-Type: multipart/alternative;

//定义邮件正文内部的第一部分的内部分隔符

22： boundary="----=_NextPart_002_0052_01C"

23：

//邮件正文内部的第一部分的第一部分的开始标记

24：------=_NextPart_002_0052_01C

25：Content-Type: text/plain;

26： charset="gb2312"

27：Content-Transfer-Encoding: base64

28：

29：u7bTrbTzvNK3w87KztLDx7XEzfjVvg0KDQog

//经BASE64编码后的文本格式的邮件正文

30：

//邮件正文内部的第一部分的第二部分的开始标记

31：------=_NextPart_002_0052_01C

32：Content-Type: text/html;

33： charset="gb2312"

34：Content-Transfer-Encoding: base64

35：

36：PCFET0NUWVBFIEhUTUwgUFVC......//经BASE64编码后的HTML格式的邮件正文

37：

//邮件正文内部的第一部分的的结束标记

38：------=_NextPart_002_0052_01C--

39：

//邮件正文内部的第二部分（HTML中的内嵌资源）的开始标记

40：------=_NextPart_001_0051_01C

41：Content-Type: image/gif;

42： name="logo.gif"

43：Content-Transfer-Encoding: base64

44：Content-ID: <004f01c5f675$4e210300$b501a8c0@zxx>

45：

46：R0lGODlh/ABGAOYAADdhmaekZjxsq0N4vHik

47：xK27z9CtCJWpxCZEa3aczejr7......

// HTML中内嵌的经BASE64编码后的图片数据

48：

//邮件正文的结束标记

49：------=_NextPart_001_0051_01C—

50：

//整个邮件内容的第二部分（第一个附件）的开始标记

51：------=_NextPart_000_0050_01C

52：Content-Type: application/x-msdownload;

53： name="daemon.exe"

54：Content-Transfer-Encoding: base64

55：Content-Disposition: attachment;//声明内容类型为附件

56： filename="daemon.exe"

57：

58：TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAA

59：AAAA0AAAAA4fug4AtAnNAAAAAA......// 第一个邮件附件内容

60：

//整个邮件内容的第三部分（第二个附件）的开始标记

61：------=_NextPart_000_0050_01C

62：Content-Type: audio/wav;

63： name="sndrec.wav"

64：Content-Transfer-Encoding: base64

65：Content-Disposition: attachment;//声明内容类型为附件

66： filename="sndrec.wav"

67：

68：UklGRjIAAABXQVZFZm10IBIAAAABAAEAIlYAACJWAAABAAgAKABmYWN0

69：AA==AAAAAAAAAAAAAAAAAACCC......//第二个邮件附件内容

70：

//整个邮件内容的结束标记

71：------=_NextPart_000_0050_01C5F6B8.5C492500--

源文件中第1～11行为邮件的邮件头，第15～71行为邮件体。邮件体中的15～49行为邮件正文，第51-59行为邮件的第一个附件，第61～71行为第二个附件。读者只要对照图3.13来阅读，就很容易看出这个邮件源文件内容的组织结构。关于上述的邮件源文件内容，还需要做出如下三点补充解释：

（1）每个MIME组合消息的Content-type头字段中的boundary属性用于定义其中嵌套的各个MIME消息之间的分隔符，如源文件中的第7行、第18行和第22行等。在各个MIME组合消息内部的起始分隔符是在该MIME组合消息的Content-type头字段中的boundary属性值前面增加了两个减号（-）字符而形成的，如源文件中的第15行、第20行和第24行等；而每个MIME组合消息的结束分隔符则是在其起始分隔符的后面又添加两个减号（-）字符而形成的，如源文件中的第38行、第49行和第71行。

（2）在每个MIME组合消息的消息体之前（即第一个开始分隔符之前），可以有一些附加的文本行，这些文本行相当于MIME消息的注释，在解码时将被忽略，如源文件的13行。

（3）源文件中的第44行使用Content-ID头字段为内嵌的图片资源指定了一个唯一标识号，在HTML格式的正文中需要使用这个唯一标识号来引用相应的内嵌资源，其引用语句为<img src= "cid: 004f01c5f675$4e210300$b501a8c0@zxx">，但是由于整个HTML正文部分采用了Base64编码，所以在源文件的HTML正文部分无法看到原始的引用语句。

多学两招邮件传播病毒的原理

MIME协议其实就是一种邮件内容的组织协议，支持MIME协议的邮件阅读程序将根据MIME消息头中定义的MIME类型，调用相应的解析程序来处理消息体中的数据。例如MIME消息头中定义为邮件附件时，邮件阅读程序会提示用户保存消息体中的数据，如果定义为图像文件时，邮件阅读程序则把消息体中的数据作为一个图像文件自动打开。

由于邮件数据通常是经过BASE64编码后的ASCII码数据，邮件阅读程序只能通过分析数据的MIME消息头来获知数据类型，无法通过分析数据本身来获知数据的类型，因此，一些病毒制造者就可以把病毒程序进行BASE64编码后，再附加在邮件的MIME消息体中，然后在MIME消息头中将其MIME类型定义为图片或声音等类型，而文件名的扩展名却为.exe。这样，当邮件阅读程序解码带有病毒程序的MIME消息体后，将执行解码后得到的病毒程序。前些年曾经在全球范围内流行的Nimda病毒，就是通过这种方式进行传播的，其示意源代码如下：

MIME-Version: 1.0

Content-Type: multipart/related;//声明所包含内容为内嵌资源

type="multipart/alternative";

boundary="====_ABC1234567890DEF_===="

--====_ABC1234567890DEF_====

Content-Type: multipart/alternative;

boundary="====_ABC0987654321DEF_===="

--====_ABC0987654321DEF_====

Content-Type: text/html;

charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

</iframe></BODY></HTML>

--====_ABC0987654321DEF_====--

--====_ABC1234567890DEF_====

Content-Type: audio/x-wav; name="readme.exe"

//把exe文件定义成一个wav文件

Content-Transfer-Encoding: base64

Content-ID: <EA4DMGBP9p>

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAA……//经BASE64编码后的病毒源代码

--====_ABC1234567890DEF_====

这封邮件传播病毒的运行原理非常简单，如上面的源文件中的黑体字部分及相应注释所示，它就是将一个可执行文件（readme.exe）作为一个audio/x-wav类型的声音文件嵌入到HTML页面中。由于最初的Outlook Express程序没有检查MIME消息的Content-Type头字段定义的MIME类型与其中的name属性指定的文件扩展名是否匹配，于是导致用户打开邮件时将执行解码后的readme.exe程序，从而感染上了病毒。这个病毒程序又利用Outlook Express中的地址簿向别人发送带毒的邮件，这样一传十，十传百，Nimda蠕虫就大行其道了。

巴特西

MIME协议(六) -- MIME实例分析

MIME实例分析

最新文章

热门文章