Ethereal的报文格式【转】

fenghai

etherreal的文件头格式关键词：
ethreal
   
文件头
                                          
闲来无事分析了一下etherreal，也就是现在改名成了wireshark的软件的文件头。
不过后来找了一下原来网上就有。
怕费事的看看这个链接。
http://lists.linux-wlan.com/pipermail/linux-wlan-devel/2003-September/002701.html
下面是我的分析过程，之前分析hca的比这个麻烦多了
1
最开始有40个字节不知道是什么，
然后接下来是第一个报文的以太网地址开始（对比vi和ethreal的显示）
第一个报文完了之后有16个字节的空档，后面是第二个报文的以太网地址。
中间这16个字节的含义是
前8个字节未知，后8个字节开始的第一个字节是下一个报文大小。也可能这连续的两个字节都存放的是报文大小，一个字节太小，256,short可存65535个字节的大小。
这里有一个问题是，后8个字节开始存放的是下一个报文的大小，比如这几个字节在vi里面显示出来是d301 0000 d301 0000,这表示下一个报文的大小是467字节，这里字节序需要调整一下，应该是0x01d3 0x0000即0x000001d3 ,这里看了几个报文都是重复的。
第一个sip报文与它前面的一个报文中间的数据是
166c 6145 2311 0400 d301 0000 d301 0000
标明这个sip报文的大小为0x000001d
比如我当前看的这个报文的第一个报文和第二个报文中间的间隔数据为
126c 6145 c5c7 0a00 a600 0000 a600 0000
标明第二个报文的大小为0x000000a6大小为116字节。
0x000a=10
0x000ac7c5=706501
再分析前面四个字节。注意字节序
这里可能存的是时间，获取到的可能是gettimeofday，是一个整形的值，而不是格式化的时间。
第二个报文和第三个报文之间的间隔为
126c 6145 b755 0c00 5c00 0000 5c00
标明第三个报文大小为92字节0x0000005c
而ethereal中显示第二个报文和第三个报文的时间间隔为
第二个报文的起始时间为0.301700
第三个报文的起始时间为0.403574
这里基本判断是时间，如果是gettimeofday的话，
存放时间是一个结构
strut timeval {
long tv_sec; /* 秒数 */
long tv_usec; /* 微秒数 */
};
需要至少32位来存放秒数，至少32位来存放微秒数，
即总共需要64个位，刚好为8个字节。
至于字节序
先写个程序看看，当前这个报文是前几天抓的，差不多比较接近
ailantian@vax:~/mypg$ cat gettime.c
#include
//#include
#include
int main()
{
struct timeval tp;
gettimeofday(&tp,NULL);
printf("Used Time:%d\n",tp.tv_sec);
printf("Used Time:%d\n",tp.tv_usec);
exit(0);
}
ailantian@vax:~/mypg$
ailantian@vax:~/mypg$ ./gettime
Used Time:1164274164
Used Time:322401
ailantian@vax:~/mypg$
秒数可以参考一下，微秒数差别就大了，不用看
116427416=0x456569F4
这样就看出来了，前面四个字节存放的是秒数，上面的颠倒过来就可以了
应该为0x45 61 6c 12
后面的四个字节应当为微秒数，换算过来应该
0x00 0c 55 b7
当然第一个报文前面自然也应该有这16个字节的内容，
看看第一个报文前面的这些内容。
126c 6145 412d 0600 7a00 0000 7a00 0000
标明这第一个报文是在
0x45616c21秒
0x 00062d41微秒抓到的
而且这第一个报文的大小为0x0000007a
去掉这些之后，剩下最前面的24个字节
再往前回溯。
d4c3 b2a1 0200 0400 0000 0000 0000 0000
ffff 0000 0100 0000
这里面应该有ethereal的文件头，不然ethreal打开的时候就不会判断这个文件是不是ethreail抓的了。有一个标志位，可能占用几个字节。
可以多打开几个文件比较一下，前面这24个字节的相似与不同之处。
打开了多个，基本上都是以这个开头了，可能这个就是ethreal的标志位？
找到一个不同的
抓包的时候，设备选presodo，不选eth0的时候会有这些，一般的文件头都有这些，
hca的文件头里面会包含有几个网卡设备（注册表描述的），比如设备的个数，设备的名称hca都放在文件头里面了。
刚抓到的包报文头如下
d4c3 b2a1 0200 0400 0000 0000 0000 0000
ffff 0000 7100 0000
猜测ehtreal的文件头可能是d4c3 b2a1，后面的都是有其他含义的。
在网上找到这样一篇文章
http://www.ethereal.com/lists/ethereal-users/200501/msg00176.html
找到了一篇文章，重要的是这个
http://lists.linux-wlan.com/pipermail/linux-wlan-devel/2003-September/002701.html
libpcap format has a file header, followed by the packets, with each
packet consisting of a packet header followed immediately by the data in
the packet, with no padding between the file header and the first packet
header, the packet header and the packet data, or the packet data and
the header of the next packet, if any.
The file header consists of, in order:
a 32-bit "magic number";
a 16-bit major version number;
a 16-bit minor version number;
a 32-bit "time zone offset" field that's actually not used, so
you can (and probably should) just make it 0;
a 32-bit "time stamp accuracy" field that's not actually used,
so you can (and probably should) just make it 0;
a 32-bit "snapshot length" field;
a 32-bit "link layer type" field.
The magic number has the value hex a1b2c3d4. All the fields can be
written in either big-endian or little-endian format; the magic number
is one of those fields, so the program reading the file (tcpdump,
Ethereal, whatever) can infer from that fields value, when it reads it,
whether the file was written in the same byte order as the native byte
order of the machine reading the file or in the opposite byte order, and
can byte-swap the values if they're written in the opposite byte order
(both libpcap, the library tcpdump and many other programs use to read
those files, and the library Ethereal and the programs that come with it
use to read the file, do so).
All numbers in the headers are usually written in the byte order of the
processor on whatever device is saving the frames.
The major version number should have the value 2.
The minor version number should have the value 4.
The "time zone offset" and "time stamp accuracy" fields should both be
zero.
The "snapshot length" field should be the maximum number of bytes per
packet that will be captured. If the entire packet is captured, make it
65535; if you only capture, for example, the first 64 bytes of the
packet, make it 64.
The link-layer type depends on the type of link-layer header that the
packets in the capture file have:
0 BSD loopback devices, except for later OpenBSD
1 Ethernet, and Linux loopback devices
6 802.5 Token Ring
7 ARCnet
8 SLIP
9 PPP
10 FDDI
100 LLC/SNAP-encapsulated ATM
101 "raw IP", with no link
102 BSD/OS SLIP
103 BSD/OS PPP
104 Cisco HDLC
105 802.11
108 later OpenBSD loopback devices (with the AF_
value in network byte order)
113 special Linux "cooked" capture
114 LocalTalk
If you need a new type for a new link-layer header, send mail to
tcpdump-workers at tcpdump.org asking for one; do *not* pick one yourself,
as you may pick one that's already in use, or reserved for future use.
Immediately following that header are the actual frames.
Each frame consists of a frame header followed by the raw bytes of the
frame.
The frame header consists of:
a time stamp, consisting of:
a UNIX-format time-in-seconds when the packet was
captured, i.e. the number of seconds since January 1,
1970, 00:00:00 GMT (that's GMT, *NOT* local time!);
the number of microseconds since that second when the
packet was captured;
a 32-bit value giving the number of bytes of packet data that
were captured;
a 32-bit value giving the actual length of the packet, in bytes
(which may be greater than the previous number, if you're not
saving the entire packet).
All those numbers must be in the same byte order as the numbers in the
file header.
***************************************************************/
So my question is if I prepend my 802.11 frames which i composed earlier by
this file header and each frame by the header it mentions.. will ethereal be
able to decompose the frames?
If there is any better approach to do this, lemme know.
Thanks in advace,
我忘记考虑的有，版本号。时区。
按这上面的解释的话，我这个文件头
d4c3 b2a1 0200 0400 0000 0000 0000 0000
ffff 0000 0100 0000
a1b2c3d4这个是magic number
0x0002是主版本号
0x0004是次版本号
0x0000 0000
0x0000 0000
上面这两个必须都是全0
后面的0x0000 ffff是每个报文抓取的最大长度，
比如每个报文只想抓前面的64字节，那就填64,而这里是抓所有的整个报文，一般都不超过65535个字节。
再后面0x0000 0001标明链路类型是1,为以太网。
帧间间隔这里也讲到了
有一个时间戳，
还有一个32位的长度，表示抓取到报文的字节数目
然后是一个32位的长度，表示真正抓到的报文的长度。后面这个值可能会比前面的值大，
如果你保存的不是一个完整的包的话。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/18262/showart_295910.html