一，网络抓包

Android 手机抓包

adb shell tcpdump -p -vv -s 0 -w /sdcard/capture.pcap

adb pull /sdcard/capture.pcap

电脑模式：方法一

1.手机必须 ROOT 然后连接电脑 确保已经安装驱动

2.下载 tcpdump

(tcpdump:)

3.然后将 tcpdump 复制到手机 /data/local/目录里

-a.直接在手机里复制进去 然后修改 tcpdump 权限为读写

-b.使用 adb 命令 直接在电脑里复制进去

-b.1 adb devices 获取手机 ID

-b.2 adb root (如果提示 adbd cannot run as root in production builds) 提权

解决方法：

-b.2.1 使用 superuser 提权

-b.2.2 如果 superuser 无法提权成功 表示手机 ROM 包原版已锁 ROOT 必须手动在手机里复制进去

-b.3 adb push [电脑里 tcpdump 位置] [手机里/data/local/目录] (eg. adb push c:/tcpdump /data/local/tcpdump)

-b.4 adb shell 进入手机目录

-b.5 su 提权 成功符号是# -b.6 chmod 777 /data/local/tcpdump 修改 tcpdump 权限

4.开始抓包

修改 tcpdump 权限全选上

打开电脑的 DOS 窗口

-adb shell

-su

-[tcpdump 路径] -p -vv -s 0 -w [输出位置] (eg. /data/local/tcpdump -p -vv -s 0 -w /sdcard/capture.pcap)

5.成功后 可以在手机里开始操作要抓包的游戏或软件

6.抓完包后按 ctrl+c 停止

7.将手机里的封包文件传送到电脑上查看

-adb pull[手机里封包位置] [电脑上要存放的位置] (eg. adb pull /sdcard/capture.pcap c:/ok.pcap)

8.然后使用 WIRESHARK 开始分析封包文件

方法二

1.下载 Fiddler 免 ROOT 然后手机连接电脑

(Fiddler: (NET.Framework 4))

2.打开 Fiddler 进行配置

-Tools 选项卡->Fiddler Options

-在 HTTPS 选项卡里 选中"Decrypt https traffic" 和 "Ignore server certificate errors" (允许 Fidder 截取 HTTPS 包) -在 Connection 选项卡里 选中 "Allow remote computers to connect" (允许截取到的封包网电脑上接收)

3.进行完配置后 点 OK 然后重启 Fiddler

4.确认电脑的 IP 地址 可以在 DOS 下使用 IPCONFIG 查看或网络连接里查看 (eg. 我的是 192.168.1.4)

5.手机打开 WIFI 连接列表 长按已经连接的 WIFI 会弹窗选项 选择"修改网络"

6.选中显示高级选项 然后按 “代理设置” 选择手动

7."代理服务器主机名" 写上电脑的 IP 地址 (eg. 192.168.1.4) 端口 默认为 8888 设置完毕点保存

8.在手机里打开游览器 输入 192.168.1.4:8888 如果访问成功会看到"Fiddler Echo Service"

9.然后往下些会看到 FiddlerRoot certificate (这是证书) 点击下载到 SDCARD 根目录

10.然后在手机的 设置-> 安全 里面有个证书安装 点一下 如果没设置过密码 在安装的时候会提示要先设置一个密码 如果已设置过密码 必须输入密

码才能进入

11.设置玩密码后可以开始安装 安装成功后就可以收到 HTTPS 包 如果没安装证书 只能手到 HTTP 包

12.现在可以开始运行要抓包的游戏或软件了 Fiddler 会截取

手机模式：

1.到 Google 商店下载 Shark 和 Shark Reader 手机必须 ROOT

(shark root:)

(shark reader:)

2.安装完毕后打开 运行软件获得 ROOT 权限

3.点 START 就可以开始抓包了

4.抓完包后点 "open capture file"即可查看

tcpdump 的使用，包括 http 抓包

简介

用简单的话来定义 tcpdump，就是：dump the traffic on a network，根据使用者的定义对网络上的数据包进行截获的包分析工具。tcpdump 可以将网络中传送的数据包的“头”完全截获下来提供分析。它支 持针对网络层、协议、主机、网络或端口的过

滤，并提供 and、or、not 等逻辑语句来帮助你去掉无用的信息。

实用命令实例tcpdump tcp -i eth0 -t -s 0 and port 8080 -w ./bb.cap ，然后下载到 windows ，wireshak 打开即可【本人测试，OK】默认启动tcpdump普通情况下，直接启动 tcpdump 将监视第一个网络接口上所有流过的数据包。

监视指定网络接口的数据包

tcpdump -i eth1

如果不指定网卡，默认 tcpdump 只会监视第一个网络接口，一般是 eth0，下面的例子都没有指定网络接口。

监视指定主机的数据包

打印所有进入或离开 sundown 的数据包.

tcpdump host sundown

也可以指定 ip,例如截获所有 210.27.48.1 的主机收到的和发出的所有的数据包tcpdump host 210.27.48.1

打印 helios 与 hot 或者与 ace 之间通信的数据包

tcpdump host helios and hotoracehotorace

截获主机 210.27.48.1 和主机 210.27.48.2 或 210.27.48.3 的通信tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \)

打印 ace 与任何其他主机之间通信的 IP 数据包, 但不包括与 helios 之间的数据包.

tcpdump ip host ace and not helios

如果想要获取主机 210.27.48.1 除了和主机 210.27.48.2 之外所有主机通信的 ip 包，使用命令：

tcpdump ip host 210.27.48.1 and ! 210.27.48.2

截获主机 hostname 发送的所有数据

tcpdump -i eth0 src host hostname

监视所有送到主机 hostname 的数据包

tcpdump -i eth0 dst host hostname

监视指定主机和端口的数据包

如果想要获取主机 210.27.48.1 接收或发出的 telnet 包，使用如下命令

tcpdump tcp port 23 host 210.27.48.1

对本机的 udp 123 端口进行监视 123 为 ntp 的服务端口

tcpdump udp port 123

监视指定网络的数据包

打印本地主机与 Berkeley 网络上的主机之间的所有通信数据包(nt: ucb-ether, 此处可理解为'Berkeley 网络'的网络地址,此表

达式最原始的含义可表达为: 打印网络地址为 ucb-ether 的所有数据包)tcpdump net ucb-ether

打印所有通过网关 snup 的 ftp 数据包(注意, 表达式被单引号括起来了, 这可以防止 shell 对其中的括号进行错误解析)

tcpdump 'gateway snup and (port ftp or ftp-data)'打印所有源地址或目标地址是本地主机的 IP 数据包

(如果本地网络通过网关连到了另一网络, 则另一网络并不能算作本地网络.(nt: 此句翻译曲折,需补充).localnet 实际使用时要真正替换成本地网络的名字)

tcpdump ip and not net localnet

监视指定协议的数据包

打印 TCP 会话中的的开始和结束数据包, 并且数据包的源或目的不是本地网络上的主机.(nt: localnet, 实际使用时要真正替换成本地网络的名字))tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'打印所有源或目的端口是 80, 网络层协议为 IPv4, 并且含有数据,而不是 SYN,FIN 以及 ACK-only 等不含数据的数据包.(ipv6 的版本的表达式可做练习)tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'(nt: 可理解为, ip[2:2]表示整个 ip 数据包的长度, (ip[0]&0xf)<<2)表示 ip 数据包包头的长度(ip[0]&0xf 代表包中的 IHL 域, 而此域的单位为 32bit, 要换算成字节数需要乘以 4, 即左移 2. (tcp[12]&0xf0)>>4 表示 tcp 头的长度, 此域的单位也是 32bit, 换算成比特数为((tcp[12]&0xf0) >> 4) << ２, 即 ((tcp[12]&0xf0)>>2). ((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0 表示: 整个 ip 数据包的长度减去ip 头的长度,再减去tcp 头的长度不为 0, 这就意味着, ip 数据包中确实是有数据.对于 ipv6 版本只需考虑 ipv6 头中的'Payload Length' 与 'tcp 头的长度'的差值, 并且其中表达方式'ip[]'需换成'ip6[]'.)

打印长度超过 576 字节, 并且网关地址是 snup 的 IP 数据包

tcpdump 'gateway snup and ip[2:2] > 576'

打印所有 IP 层广播或多播的数据包， 但不是物理以太网层的广播或多播数据报

tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

打印除'echo request'或者'echo reply'类型以外的 ICMP 数据包( 比如,需要打印所有非 ping 程序产生的数据包时可用到此表达式 .

(nt: 'echo reuqest' 与 'echo reply' 这两种类型的 ICMP 数据包通常由 ping 程序产生))

tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'tcpdump 与 wireshark

Wireshark(以前是 ethereal)是 Windows 下非常简单易用的抓包工具。但在 Linux 下很难找到一个好用的图形化抓包工具。

还好有 Tcpdump。我们可以用 Tcpdump + Wireshark 的完美组合实现：在 Linux 里抓包，然后在 Windows 里分析包。

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

(1)tcp: ip icmp arp rarp 和 tcp、udp、icmp 这些选项等都要放到第一个参数的位置，用来过滤数据报的类型

(2)-i eth1 : 只抓经过接口 eth1 的包

(3)-t : 不显示时间戳

(4)-s 0 : 抓取数据包时默认抓取长度为 68 字节。加上-S 0 后可以抓到完整的数据包

(5)-c 100 : 只抓取 100 个数据包

(6)dst port ! 22 : 不抓取目标端口是 22 的数据包

(7)src net 192.168.1.0/24 : 数据包的源网络地址为 192.168.1.0/24

(8)-w ./target.cap : 保存成 cap 文件，方便用 ethereal(即 wireshark)分析

使用 tcpdump 抓取 HTTP 包

tcpdump -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854

0x4745 为"GET"前两个字母"GE",0x4854 为"HTTP"前两个字母"HT"。

tcpdump 对截获的数据并没有进行彻底解码，数据包内的大部分内容是使用十六进制的形式直接打印输出的。显然这不利于分析网络故障，通常的解决办法是先使用带-w 参 数的 tcpdump 截获数据并保存到文件中，然后再使用其他程序(如 Wireshark)进行解码分析。当然也应该定义过滤规则，以避免捕获的数据包填满整个硬盘。

输出信息含义

首先我们注意一下，基本上 tcpdump 总的的输出格式为：系统时间 来源主机.端口 > 目标主机.端口 数据包参数

tcpdump 的输出格式与协议有关.以下简要描述了大部分常用的格式及相关例子.

链路层头

对于 FDDI 网络, '-e' 使 tcpdump 打印出指定数据包的'frame control' 域, 源和目的地址, 以及包的长度.(frame control域控制对包中其他域的解析). 一般的包(比如那些 IP datagrams)都是带有'async'(异步标志)的数据包，并且有取值 0 到 7 的优先级;

比如 'async4'就代表此包为异步数据包，并且优先级别为 4. 通常认为,这些包们会内含一个 LLC 包(逻辑链路控制包); 这时,如果此包不是一个 ISO datagram 或所谓的 SNAP 包，其 LLC 头部将会被打印(nt:应该是指此包内含的 LLC 包的包头).

对于 Token Ring 网络(令牌环网络), '-e' 使 tcpdump 打印出指定数据包的'frame control'和'access control'域, 以及源和目的地址,外加包的长度. 与 FDDI 网络类似, 此数据包通常内含 LLC 数据包. 不管 是否有'-e'选项.对于此网络上的'source-routed'类型数据包(nt:意译为:源地址被追踪的数据包,具体含义未知,需补充), 其包的源路由信息总会被打印.

对于 802.11 网络(WLAN,即 wireless local area network), '-e' 使 tcpdump 打印出指定数据包的'frame control 域,包头中包含的所有地址, 以及包的长度.与 FDDI 网络类似, 此数据包通常内含 LLC 数据包. (注意: 以下的描述会假设你熟悉 SLIP 压缩算法 (nt:SLIP 为 Serial Line Internet Protocol.), 这个算法可以在RFC-1144 中找到相关的蛛丝马迹.)

对于 SLIP 网络(nt:SLIP links, 可理解为一个网络, 即通过串行线路建立的连接, 而一个简单的连接也可看成一个网络),数据包的'direction indicator'('方向指示标志')("I"表示入, "O"表示出), 类型以及压缩信息将会被打印. 包类型会被首先打印.

类型分为 ip, utcp 以及 ctcp(nt:未知, 需补充). 对于 ip 包,连接信息将不被打印(nt:SLIP 连接上,ip 包的连接信息可能无用或没有定义.

reconfirm).对于 TCP 数据包, 连接标识紧接着类型表示被打印. 如果此包被压缩, 其被编码过的头部将被打印.

此时对于特殊的压缩包,会如下显示:

*S+n 或者 *SA+n, 其中 n 代表包的(顺序号或(顺序号和应答号))增加或减少的数目(nt | rt:S,SA 拗口, 需再译).

对于非特殊的压缩包,0 个或更多的'改变'将会被打印.'改变'被打印时格式如下: '标志'+/-/=n 包数据的长度 压缩的头部长度.

其中'标志'可以取以下值:

U(代表紧急指针), W(指缓冲窗口), A(应答), S(序列号), I(包 ID),而增量表达'=n'表示被赋予新的值, +/-表示增加或减少.

比如, 以下显示了对一个外发压缩 TCP 数据包的打印, 这个数据包隐含一个连接标识(connection identifier); 应答号增加了 6,顺序号增加了 49, 包 ID 号增加了 6; 包数据长度为 3 字节(octect), 压缩头部为 6 字节.(nt:如此看来这应该不是一个特殊的压缩数据包).

ARP/RARP 数据包

tcpdump 对 Arp/rarp 包的输出信息中会包含请求类型及该请求对应的参数. 显示格式简洁明了. 以下是从主机 rtsg 到主机csam 的'rlogin'

(远程登录)过程开始阶段的数据包样例:

arp who-has csam tell rtsg

arp reply csam is-at CSAM

第一行表示:rtsg 发送了一个 arp 数据包(nt:向全网段发送,arp 数据包）以询问 csam 的以太网地址

Csam（nt:可从下文看出来, 是 Csam）以她自己的以太网地址做了回应(在这个例子中, 以太网地址以大写的名字标识, 而internet地址(即 ip 地址)以全部的小写名字标识).

如果使用 tcpdump -n, 可以清晰看到以太网以及 ip 地址而不是名字标识:

arp who-has 128.3.254.6 tell 128.3.254.68

arp reply 128.3.254.6 is-at 02:07:01:00:01:c4

如果我们使用 tcpdump -e, 则可以清晰的看到第一个数据包是全网广播的, 而第二个数据包是点对点的:

RTSG Broadcast 0806 64: arp who-has csam tell rtsg

CSAM RTSG 0806 64: arp reply csam is-at CSAM

第一个数据包表明:以 arp 包的源以太地址是 RTSG, 目标地址是全以太网段, type 域的值为 16 进制 0806(表示ETHER_ARP(nt:arp 包的类型标识)),包的总长度为 64 字节.

TCP 数据包 (注意:以下将会假定你对 RFC-793 所描述的 TCP 熟悉. 如果不熟, 以下描述以及 tcpdump 程序可能对你帮助不大.(nt:警告可忽略,只需继续看, 不熟悉的地方可回头再看.).

通常 tcpdump 对 tcp 数据包的显示格式如下:

src > dst: flags data-seqno ack window urgent options

src 和 dst 是源和目的 IP 地址以及相应的端口. flags 标志由 S(SYN), F(FIN), P(PUSH, R(RST),W(ECN CWT(nt | rep:未知, 需补充))或者 E(ECN-Echo(nt | rep:未知, 需补充))组成,单独一个'.'表示没有 flags 标识. 数据段顺序号(Data-seqno)描述了此包中数据所对应序列号空间中的一个位置(nt:整个数据被分段,每段有一个顺序号, 所有的顺序号构成一个序列号空间)(可参考以下例子). Ack 描述的是同一个连接,同一个方向,下一个本端应该接收的(对方应该发送的)数据片段的顺序号. Window 是本端可用的数据接收缓冲区的大小(也是对方发送数据时需根据这个大小来组织数据).

Urg(urgent) 表示数据包中有紧急的数据. options 描述了 tcp 的一些选项, 这些选项都用尖括号来表示(如 <mss 1024>).

src, dst 和 flags 这三个域总是会被显示. 其他域的显示与否依赖于 tcp 协议头里的信息.

这是一个从 trsg 到 csam 的一个 rlogin 应用登录的开始阶段.

rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>

csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>rtsg.1023 > csam.login: . ack 1 win 4096

rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096

csam.login > rtsg.1023: . ack 2 win 4096

rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096

csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077

csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1

csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1

第一行表示有一个数据包从 rtsg 主机的 tcp 端口 1023 发送到了 csam 主机的 tcp 端口 login 上(nt:udp 协议的端口和 tcp 协议的端口是分别的两个空间, 虽然取值范围一致). S 表示设置了 SYN 标志. 包的顺序号是 768512, 并且没有包含数据.(表示格式为:'first:last(nbytes)', 其含义是'此包中数据的顺序号从 first 开始直到 last 结束，不包括 last. 并且总共包含 nbytes的用户数据'.) 没有捎带应答(nt:从下文来看，第二行才是有捎带应答的数据包), 可用的接受窗口的大小为 4096bytes, 并且请求端(rtsg)的最大可接受的数据段大小是 1024 字节(nt:这个信息作为请求发向应答端 csam, 以便双方进一步的协商).Csam 向 rtsg 回复了基本相同的 SYN 数据包, 其区别只是多了一个' piggy-backed ack'(nt:捎带回的 ack 应答, 针对 rtsg的 SYN 数据包).rtsg 同样针对 csam 的 SYN 数据包回复了一 ACK 数据包作为应答. '.'的含义就是此包中没有标志被设置. 由于此应答包中不含有数据, 所以包中也没有数据段序列号. 提醒! 此 ACK 数据包的顺序号只是一个小整数 1. 有如下解释:tcpdump 对于一个 tcp 连接上的会话, 只打印会话两端的初始数据包的序列号,其后相应数据包只打印出与初始包序列号的差异.即初始序列号之后的序列号, 可被看作此会话上当前

所传数据片段在整个要传输的数据中的'相对字节'位置(nt:双方的第一个位置都是 1, 即'相对字节'的开始编号). '-Ｓ'将覆盖这个功能,使数据包的原始顺序号被打印出来.

第六行的含义为:rtsg 向 csam 发送了 19 字节的数据(字节的编号为 2 到 20，传送方向为 rtsg 到 csam). 包中设置了 PUSH 标 志. 在第 7 行,csam 喊到， 她已经从 rtsg 中收到了 21 以下的字节, 但不包括 21 编号的字节. 这些字节存放在 csam 的 socket 的接收缓冲中, 相应地,csam 的接收缓冲窗口大小会减少 19 字节(nt:可以从第 5 行和第 7 行 win 属性值的变化看出来). csam 在第 7 行这个包中也向rtsg 发送了一个字节. 在第 8 行和第 9 行, csam 继续向 rtsg 分别发送了两个只包含一个字节的数据包, 并且这个数据包带 PUSH 标志.

如果所抓到的 tcp 包(nt:即这里的 snapshot)太小了，以至 tcpdump 无法完整得到其头部数据, 这时, tcpdump 会尽量解析这个不完整的头,并把剩下不能解析的部分显示为'[|tcp]'. 如果头部含有虚假的属性信息(比如其长度属性其实比头部实际长度长或短), tcpdump 会为该头部显示'[bad opt]'. 如果头部的长度告诉我们某些选项(nt | rt:从下文来看， 指 tcp 包的头部中针对 ip 包的一些选项, 回头再翻)会在此包中,

而真正的 IP(数据包的长度又不够容纳这些选项, tcpdump 会显示'[bad hdr length]'.抓取带有特殊标志的的 TCP 包(如 SYN-ACK 标志, URG-ACK 标志等).

在 TCP 的头部中, 有 8 比特(bit)用作控制位区域, 其取值为:

CWR | ECE | URG | ACK | PSH | RST | SYN | FIN(nt | rt:从表达方式上可推断:这 8 个位是用或的方式来组合的, 可回头再翻)现假设我们想要监控建立一个 TCP 连接整个过程中所产生的数据包. 可回忆如下:TCP 使用 3 次握手协议来建立一个新的连接; 其与此三次握手连接顺序对应，并带有相应 TCP 控制标志的数据包如下:

1) 连接发起方(nt:Caller)发送 SYN 标志的数据包

2) 接收方(nt:Recipient)用带有 SYN 和 ACK 标志的数据包进行回应

3) 发起方收到接收方回应后再发送带有 ACK 标志的数据包进行回应

0 15 31

-----------------------------------------------------------------

| source port | destination port |

-----------------------------------------------------------------

| sequence number |

-----------------------------------------------------------------

| acknowledgment number |

-----------------------------------------------------------------

| HL | rsvd |C|E|U|A|P|R|S|F| window size |

-----------------------------------------------------------------

| TCP checksum | urgent pointer |

-----------------------------------------------------------------

一个 TCP 头部,在不包含选项数据的情况下通常占用 20 个字节(nt | rt:options 理解为选项数据，需回译). 第一行包含 0 到 3 编号的字节,第二行包含编号 4-7 的字节.

如果编号从 0 开始算, TCP 控制标志位于 13 字节(nt:第四行左半部分).

0 7| 15| 23| 31

----------------|---------------|---------------|----------------

| HL | rsvd |C|E|U|A|P|R|S|F| window size |

----------------|---------------|---------------|----------------

| | 13th octet | | |

让我们仔细看看编号 13 的字节:

| |

|---------------|

|C|E|U|A|P|R|S|F|

|---------------|

|7 5 3 0|

这里有我们感兴趣的控制标志位. 从右往左这些位被依次编号为 0 到 7, 从而 PSH 位在 3 号, 而 URG 位在 5 号.

提醒一下自己, 我们只是要得到包含 SYN 标志的数据包. 让我们看看在一个包的包头中, 如果 SYN 位被设置, 到底在 13 号字节发生了什么:

|C|E|U|A|P|R|S|F|

|---------------|

|0 0 0 0 0 0 1 0|

|---------------|

|7 6 5 4 3 2 1 0|

在控制段的数据中, 只有比特 1(bit number 1)被置位.

假设编号为 13 的字节是一个 8 位的无符号字符型,并且按照网络字节号排序(nt:对于一个字节来说，网络字节序等同于主机字节序), 其二进制值

如下所示:

00000010

并且其 10 进制值为:

0*2^7 + 0*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2^0 = 2(nt: 1 * 2^6 表示 1 乘以 2 的 6 次方, 也许这样更

清楚些, 即把原来表达中的指数 7 6 ... 0 挪到了下面来表达)

接近目标了, 因为我们已经知道, 如果数据包头部中的 SYN 被置位, 那么头部中的第 13 个字节的值为 2(nt: 按照网络序, 即大头方式, 最重要的字节在前面(在前面,即该字节实际内存地址比较小, 最重要的字节,指数学表示中数的高位, 如 356 中的 3) ).表达为 tcpdump 能理解的关系式就是:

tcp[13] 2

从而我们可以把此关系式当作 tcpdump 的过滤条件, 目标就是监控只含有 SYN 标志的数据包:

tcpdump -i xl0 tcp[13] 2 (nt: xl0 指网络接口, 如 eth0)这个表达式是说"让 TCP 数据包的第 13 个字节拥有值 2 吧", 这也是我们想要的结果.

现在, 假设我们需要抓取带 SYN 标志的数据包, 而忽略它是否包含其他标志.(nt:只要带 SYN 就是我们想要的). 让我们来看看当一个含有

SYN-ACK 的数据包(nt:SYN 和 ACK 标志都有), 来到时发生了什么:

|C|E|U|A|P|R|S|F|

|---------------|

|0 0 0 1 0 0 1 0|

|---------------|

|7 6 5 4 3 2 1 0|

13 号字节的 1 号和 4 号位被置位, 其二进制的值为:

00010010

转换成十进制就是:

0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2 = 18(nt: 1 * 2^6 表示 1 乘以 2 的 6 次方, 也许这样更清楚些, 即把原来表达中的指数 7 6 ... 0 挪到了下面来表达)现在, 却不能只用'tcp[13] 18'作为 tcpdump 的过滤表达式, 因为这将导致只选择含有 SYN-ACK 标志的数据包, 其他的都被丢弃.

提醒一下自己, 我们的目标是: 只要包的 SYN 标志被设置就行, 其他的标志我们不理会.

为了达到我们的目标, 我们需要把 13 号字节的二进制值与其他的一个数做 AND 操作(nt:逻辑与)来得到 SYN 比特位的值. 目标是:只要 SYN 被设置就行, 于是我们就把她与上 13 号字节的 SYN 值(nt: 00000010).

00010010 SYN-ACK 00000010 SYN

AND 00000010 (we want SYN) AND 00000010 (we want SYN)

-------- --------

= 00000010 = 00000010

我们可以发现, 不管包的 ACK 或其他标志是否被设置, 以上的 AND 操作都会给我们相同的值, 其 10 进制表达就是 2(2 进制表达就是 00000010).

从而我们知道, 对于带有 SYN 标志的数据包, 以下的表达式的结果总是真(true):

( ( value of octet 13 ) AND ( 2 ) ) ( 2 ) (nt: value of octet 13, 即 13 号字节的值)灵感随之而来, 我们于是得到了如下的 tcpdump 的过滤表达式tcpdump -i xl0 'tcp[13] & 2 2'注意, 单引号或反斜杆(nt: 这里用的是单引号)不能省略, 这可以防止 shell 对&的解释或替换.

UDP 数据包

UDP 数据包的显示格式，可通过 rwho 这个具体应用所产生的数据包来说明:

actinide.who > broadcast.who: udp 84其含义为:actinide 主机上的端口 who 向 broadcast 主机上的端口 who 发送了一个 udp 数据包(nt: actinide 和 broadcast 都是指 Internet 地址).这个数据包承载的用户数据为 84 个字节.

一些 UDP 服务可从数据包的源或目的端口来识别，也可从所显示的更高层协议信息来识别. 比如, Domain Name service requests(DNS 请求, 在 RFC-1034/1035 中), 和 Sun RPC calls to NFS(对 NFS 服务器所发起的远程调用(nt: 即 Sun RPC)，在 RFC-1050 中有对远程调用的描述).UDP 名称服务请求

(注意:以下的描述假设你对 Domain Service protoco(nt:在 RFC-103 中有所描述), 否则你会发现以下描述就是天书(nt:希腊文天书,不必理会, 吓吓你的, 接着看就行))

名称服务请求有如下的格式:

src > dst: id op? flags qtype qclass name (len)

(nt: 从下文来看, 格式应该是 src > dst: id op flags qtype qclass? name (len))

比如有一个实际显示为:

h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

主机 h2opolo 向 helios 上运行的名称服务器查询 ucbvax.berkeley.edu 的地址记录(nt: qtype 等于 A). 此查询本身的 id号为'3'. 符号'+'意味着递归查询标志被设置(nt: dns 服务器可向更高层 dns 服务器查询本服务器不包含的地址记录). 这个最终通过 IP 包发送的查询请求数据长度为 37 字节, 其中不包括 UDP 和 IP 协议的头数据. 因为此查询操作为默认值(nt | rt: normal one 的理解), op 字段被省略.

如果 op 字段没被省略, 会被显示在'3' 和'+'之间. 同样, qclass 也是默认值, C_IN, 从而也没被显示, 如果没被忽略, 她会被显示在'A'之后.

异常检查会在方括中显示出附加的域: 如果一个查询同时包含一个回应(nt: 可理解为, 对之前其他一个请求的回应), 并且此回应包含权威或附加记录段,

ancount, nscout, arcount(nt: 具体字段含义需补充) 将被显示为'[na]', '[nn]', '[nau]', 其中 n 代表合适的计数. 如果包中以下回应位(比如 AA 位, RA 位, rcode 位), 或者字节 2 或 3 中任何一个'必须为 0'的位被置位(nt: 设置为 1), '[b2&3]=x' 将被显示, 其中 x 表示头部字节 2 与字节 3 进行与操作后的值.

UDP 名称服务应答

对名称服务应答的数据包，tcpdump 会有如下的显示格式

src > dst: id op rcode flags a/n/au type class data (len)

比如具体显示如下:

helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)

helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)

第一行表示: helios 对 h2opolo 所发送的 3 号查询请求回应了 3 条回答记录(nt | rt: answer records), 3 条名称服务器记录,

以及 7 条附加的记录. 第一个回答记录(nt: 3 个回答记录中的第一个)类型为 A(nt: 表示地址), 其数据为 internet 地址128.32.137.3.

此回应 UDP 数据包, 包含 273 字节的数据(不包含 UPD 和 IP 的头部数据). op 字段和 rcode 字段被忽略(nt: op 的实际值为Query, rcode, 即response code 的实际值为 NoError), 同样被忽略的字段还有 class 字段(nt | rt: 其值为 C_IN, 这也是 A 类型记录默认取值)第二行表示: helios 对 h2opolo 所发送的 2 号查询请求做了回应. 回应中, rcode 编码为 NXDomain(nt: 表示不存在的域)), 没有回答记录,但包含一个名称服务器记录, 不包含权威服务器记录(nt | ck: 从上文来看, 此处的 authority records 就是上文中对应的additionalrecords). '*'表示权威服务器回答标志被设置(nt: 从而 additional records 就表示的是 authority records).

由于没有回答记录, type, class, data 字段都被忽略.

flag 字段还有可能出现其他一些字符, 比如'-'(nt: 表示可递归地查询, 即 RA 标志没有被设置), '|'(nt: 表示被截断的消息, 即 TC 标志被置位). 如果应答(nt | ct: 可理解为, 包含名称服务应答的 UDP 数据包, tcpdump 知道这类数据包该怎样解析其数据)的

'question'段一个条目(entry)都不包含(nt: 每个条目的含义, 需补充),'[nq]' 会被打印出来.

要注意的是:名称服务器的请求和应答数据量比较大, 而默认的 68 字节的抓取长度(nt: snaplen, 可理解为 tcpdump 的一个设置选项)可能不足以抓取数据包的全部内容. 如果你真的需要仔细查看名称服务器的负载, 可以通过 tcpdump 的-s 选项来扩大 snaplen 值.