wireshark源代码的结构分析

本文深入探讨了Wireshark系统的核心技术,包括层次化的数据包协议分析方法和基于插件技术的协议分析器。介绍了Wireshark如何采用协议树结构和特征字来解析复杂的网络协议,并通过插件技术实现协议分析器的快速扩展和模块化设计。同时,指出了Wireshark在协议识别方面的局限性和改进空间。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

wireshark源代码的结构分析

分类: 网络通信   97人阅读  评论(1)  收藏  举报

一、层次化的数据包协议分析方法
  取得捕包函数捕回的数据包后就需要进行协议分析和协议还原工作了。由于OSI的7层协议模型,协议数据是从上到下封装后发送的。对于协议分析需要从下至上进行。首先对网络层的协议识别后进行组包还原然后脱去网络层协议头。将里面的数据交给传输层分析,这样一直进行下去直到应用层:

 IP
 / \
 TCP UDP
 /     \
  HTTP     TFTP
  由于网络协议种类很多,就WireShark所识别的500多种协议来说,为了使协议和协议间层次关系明显。从而对数据流里的各个层次的协议能够逐层处理。WireShark系统采用了协议树的方式。上图就是一个简单的协议树。如果协议A的所有数据都是封装在协议B里的,那么这个协议A就是协议B是另外一个协议的儿子节点。我们将最低层的无结构数据流作为根接点。那么具有相同父节点的协议成为兄弟节点。那么这些拥有同样父协议兄弟节点协议如何互相区分了?WireShark系统采用协议的特征字来识别。每个协议会注册自己的特征字。这些特征字给自己的子节点协议提供可以互相区分开来的标识。比如tcp协议的port字段注册后。 Tcp.port=21就可以认为是ftp协议, 特征字可以是协议规范定义的任何一个字段。比如ip协议就可以定义proto字段为一个特征字。
  在WireShark中注册一个协议解析器首先要指出它的父协议是什么。另外还要指出自己区别于父节点下的兄弟接点协议的特征。比如ftp协议。在WireShark中他的父接点是tcp协议,它的特征就是tcp协议的port字段为21。
  这样当一个端口为21的tcp数据流来到时。首先由tcp协议注册的解析模块处理,处理完之后通过查找协议树找到自己协议下面的子协议,判断应该由那个子协议来执行,找到正确的子协议后,就转交给ftp注册的解析模块处理。这样由根节点开始一层层解析下去。
  由于采用了协议树加特征字的设计,这个系统在协议解析上由了很强的扩展性,增加一个协议解析器只需要将解析函数挂到协议树的相应节点上即可。

二、基于插件技术的协议分析器 
  所谓插件技术,就是在程序的设计开发过程中,把整个应用程序分成宿主程序和插件两个部分,宿主程序与插件能够相互通信,并且,在宿主程序不变的情况下,可以通过增减插件或修改插件来调整应用程序的功能。运用插件技术可以开发出伸缩性良好、便于维护的应用程序。它著名的应用实例有:媒体播放器winamp、微软的网络浏览器ie等。
  由于现在网络协议种类繁多,为了可以随时增加新的协议分析器,一般的协议分析器都采用插件技术,这样如果需要对一个新的协议分析只需要开发编写这个协议分析器并调用注册函数在系统注册就可以使用了。通过增加插件使程序有很强的可扩展性,各个功能模块内聚。
  在协议分析器中新增加一个协议插件一般需要插件安装或者注册,插件初始化,插件处理3个步骤,下面以WireShark为例进行分析如何利用插件技术新增加一个协议分析模块。
  WireShark由于采用插件技术,一个新加入开发的程序员开发一种新的协议分析模块的时候不需要了解所有的代码,他只需要写好这个协议模块的函数后,写一个格式为proto_reg_handoff_XXX的函数,在函数内调用注册函数告诉系统在什么时候需要调用这个协议模块。比如
  你事先写好了一个名为dissect_myprot的协议解析模块,它是用来解析tcp协议端口为250的数据。可以利用这些语句来将这个解析器注册到系统中
proto_reg_handoff_myprot(void)
{
    dissector_handle_t myprot_handle;

    myprot_handle = create_dissector_handle(dissect_myprot,
      proto_myprot);
    dissector_add("tcp.port", 250, myprot_handle);
}
这段代码告诉系统当tcp协议数据流端口为250的时候要调用dissect_myprot这个函数模块。
  在WireShark中有一个角本专门来发现开发者定义的类式proto_reg_handoff_xxx这样的注册函数名,然后自动生成调用这些注册函数的代码。这样开发者不需要知道自己的注册函数如何被调用的。这样一个新的协议分析模块就加入到系统中了。
  由于采用了插件方式,WireShark良好的结构设计让开发者只需要关系自己开发的协议模块,不需要关心整个系统结构,需要将模块整合进系统只需要写一个注册函数即可,连初始化时调用这个注册函数都由脚本自动完成了。正是因为有很好的体系结构,这个系统才能够开发出如此多的协议解析器

  尽管WireShark是目前最好的开放源码的网络分析系统,但WireShark仍然有一些可以改进的地方,一个优秀的网络分析器,尽可能的正确分析出数据协议和高效的处理数据是两个重要的指标。在协议识别方面WireShark大多采用端口识别,有少量协议采用内容识别。这就让一些非标准端口的协议数据没有正确解析出来。比如ftp协议如果不是21端口的话,WireShark就无法识别出来,只能作为tcp数据处理。另外对于内容识别式。WireShark是将所以内容识别的函数组成一张入口表。每次协议数据需要内容识别时,按字母顺序逐个调用表里的每个识别函数。比如对于识别yahoo massanger协议。主要是看数据前几个字节是不是’ymsg’.由于协议名为y开头。所以当识别出协议时已经把所有内容识别函数调用了一遍。这些都是由于WireShark没有实现tcp协议栈,无法做到流级别的识别。导致在协议识别方面有点缺陷。

wireshark源码分析问题这几天在看wireshark(ethereal)源代码。看源代码的主要兴趣点是它的分析模块(dissect)。分析之后他的数据存在哪儿,怎么打印的(-V参数)。我想把分析后的数据,提取出来,存在自己定义的数据结构里面,或者按我自己的格式写入文本中。 看了几天,对一些数据结构,似懂非懂,一些流程也是似懂非懂。可能由于经验不足的原因,搞来搞去就在几个函数,结构体里面打转。好几次以为找到切入点,发现又回来原来的起点。 这两天看晕了。有点打击,水平太差劲了。。呵呵。先这边问问,看看有没有熟悉的朋友。指点一下。先谢谢了。 这样问问题可能太细了。感觉也不大合适。 1. 我应该如何来看代码?如何找到突破点? 2. 有wireshark有了解的朋友,说说你们关于源码剖析的体会。 3. 说什么都可以,朋友觉得对我有用,有启发就好。千万别 “我顶,UP啊”。呵呵:emn23:我觉得重要的是看 pcap库 本帖最后由 peidright 于 2010-04-02 16:36 编辑 楼上说得对!。 看源代码之前,问下你自己,看代码的目的是什么? 对于 wireshark 来说,你是想学他写界面? 还是抓包? 还是业务逻辑? 界面的话,wireshark 还行 抓包的话,应该看pcap库 业务逻辑的话。不应该看wireshark,看tcpdump.看下啊,:em03:看看这个也许对你有帮助 添加一个基础的RDP解析器 下面我们将循序渐进地设计一个基础的RDP解析器。它依次包含如下构成要素: 包类型字段(占用8比特位,可能的值为:1,初始;2,终结;3,数据); 标志集字段(占用8比特位:0x01,开始包;0x02,结束包;0x04先包); 序列号字段(占用16比特位); 1. 创建解析器 首先您需要选择解析器的类型:内置型(包含在主程序中)或插件型。 插件是容易编写的,先做一个插件型解析器吧。 例1. 解析器初始设定. #ifdef HAVE_CONFIG_H #include "config.h" #endif #include #include void proto_register_rdp(); void proto_reg_handoff_rdp(); static void dissect_rdp(tvbuff_t *tvb,packet_info *pinfo,proto_tree *tree); static int proto_rdp=-1; static dissector_handle_t rdp_handle; static gint ett_rdp = -1; define TCP_PORT_RDP 3389 void proto_register_rdp(void) { proto_rdp=proto_register_protocol( "RDP Protocol", "RDP", "rdp"); } 现在来逐一分析这段代码。首先我们有一些常规的包含文件,最好依惯例在文件开始包含进来。随后是一些函数的前置声明,我们稍后定义它们。 接下来我们定义了一个整型变量"proto_rdp"用于记录我们的协议注册信息。它被初始化为"-1",当解析器注册到主程序中后,其值便会得到更新。这样做可保证我们方便地判断是否已经做了初始工作。将所有不打算对外输出的全局变量和函数声明为"static"是一个良好的习惯,因为这可以保证命名空间不被污染。通常这是容易做到的,除非您的解析器非常庞大以致跨越多个文件。 之后的模块变量"TCP_PORT_RDP"则包含了协议使用的TCP端口号,我们会对通过该端口的数据流进行解析。 solaris10下proc编译问题 >紧随其后的是解析器句柄"rdp_handle",我们稍后对它进行初始化。 至此我们已经拥有了和主程序交互的基本元素,接下来最好再把那些预声明的函数定义一下,就从注册函数"proto_register_rdp"开始吧。 首先调用函数"proto_register_protocol"注册协议。我们能够给协议起3个名字以适用不同的地方。全名和短名用在诸如"首选项(Preferences)"和"已激活协议(Enabled protocols)"对话框以及记录中已生成的域名列表内。缩略名则用于过滤器。 下面我们需要一个切换函数。 例2. 解析器切换. void proto_reg_handoff_rdp(void) { static gboolean initialized=FALSE; if(!initialized) { rdp_handle = create_dissector_handle(dissect_rdp, proto_rdp); dissector_add("tcp.port", TCP_PORT_RDP, rdp_handle); initialized=TRUE; } } 这段代码做了什么呢?如果解析器尚未初始化,则对它进行初始化。首先创建解析器。这时注册了了函数"dissect_rdp"用于完成实际的解析工作。之后将该解析器与TCP端口号相关联,以使主程序收到该端口的UDP数据流时通知该解析器。 至此我们终于可以写一些解析代码了。不过目前我们仅写点儿基本功能占个位置。 例3.解析 static void dissect_rdp(tvbuff_t *tvb,packet_info *pinfo,proto_tree *tree) { if(check_col(pinfo->cinfo, COL_PROTOCOL)) { col_set_str(pinfo->cinfo, COL_PROTOCOL, "RDP"); } if(check_col(pinfo->cinfo,COL_INFO)) { col_clear(pinfo->cinfo,COL_INFO); } } 该函数用于解析传递给它的数据包。包数据由"tvb"参数指向的特殊缓冲区保管。现在我们已深入到协议的细节,对它们您肯定是了若指掌。包信息结构参数"pinfo"包含了协议的基本数据,以供我们更新。参数"tree"则指明了详细解析发生的地方。 这里我们仅做了保证通过的少量工作。前两行检查UI中"协议(Protocol)"列是否已显示。如果该列已存在,就在这儿显示我们的协议名称。这样人们就知道它被识别出来了。另外,如果"信息(INFO)"列已显示,我们就将它的内容清除。 至此我们已经准备好一个可以编译和安装的基本解析器。不过它目前只能识别和标示协议。 为了编译解析器并创建插件,还需要在解析器代码文件"packet-rdp.c"所在目录下创建一些提供支持的文件: - Makefile.am - UNIX/Linux的makefile模板 - Makefile.common - 包含了插件文件的名称 - Makefile.nmake - 包含了针对Windows平台的Wireshark插件makefile - moduleinfo.h - 包含了插件版本信息 - moduleinfo.nmake - 包含了针对Windows平台的DLL版本信息 - packet-rdp.c - 这是您的解析器原代码文件 - plugin.rc.in - 包含了针对Windows平台的DLL资源模板 "Makefile.common"和"Makefile.am"文件中涉及到相关文件和解析器名称的地方一定要修改正确。"moduldeinfo.h"和"moduleinfo.nmake"文件中的版本信息也需要正确填充。一切准备妥善后就可以将解析器编译为DLL或共享库文件了(使用nmake工具)。在wireshark文件夹下的"plugins"文件夹中,建立"rdp"文件夹。将修改过的Makefile.common,Makefile.am,moduleinfo.nmake,moduldeinfo.h,Makefile.nmake及packet-rdp.c文件考到"rdp"文件夹下,然后进行编译,rdp插件自动生成完整,就可以正常工作了。 1. 解析协议细节 现在我们已经有了一个可以运用的简单解析器,让我们再为它添点儿什么吧。首先想到的应该就是标示数据包的有效信息了。解析器在这方面给我们提供了支持。 首先要做的事情是创建一个子树以容纳我们的解析结果。这会使协议的细节显示得井井有条。现在解析器在两种情况下被调用http://www.boomss.com:其一,用于获得数据包的概要信息;其二,用于获得数据包的详细信息。这两种情况可以通过树指针参数"tree"来进行区分。如果树指针为NULL,我们只需要提供概要信息;反之,我们就需要拆解协议完成细节的显示了。基于此,让我们来增强这个解析器吧。 例4 static void dissect_rdp(tvbuff_t *tvb,packet_info *pinfo,proto_tree *tree) { proto_item *ti=NULLV; if(check_col(pinfo->cinfo,COL_PROTOCOL)) { col_set_str(pinfo->cinfo,COL_PROTOCOL,"RDP"); } if(check_col(pinfo->cinfo,COL_INFO)) { col_clear(pinfo->cinfo,COL_INFO); } if(tree) { ti = proto_tree_add_item(tree, proto_rdp, tvb, offset, -1, FALSE);} } 这里我们为解析添加一个子树。它将用于保管协议的细节,仅在必要时显示这些内容。 我们还要标识被协议占据的数据区域。在我们的这种情况下,协议占据了传入数据的全部,因为我们假设协议没有封装其它内容。因此,我们用"proto_tree_add_item"函数添加新的树结点,将它添加到传入的协议树"tree"中,用协议句柄"proto_rdp"标识它,用传入的缓冲区"tvb"作为数据,并将有效数据范围的起点设为"0",长度设为"-1"(表示缓冲区内的全部数据)。至于最后的参数"FALSE",我们暂且忽略。 做了这个更改之后,在包明细面板区中应该会出现一个针对该协议的标签;选择该标签后,在包字节面板区中包的剩余内容就会高亮显示。 现在进入下一步,添加一些协议解析功能。在这一步我们需要构建一组帮助解析的表结构。这需要对"proto_register_rdp"函数做些修改。首先定义一组静态数组。 例5 定义数据结构 static hf_register_info hf[]= { { &hf;_rdp_version, { "TPKT Header:Version", "rdp.version",
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值