在TCPdump中解构BPF过滤器

Question

试图解构这个TCPdump BPF样式过滤器，需要一些帮助：

'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

它取自这里

已经采取的步骤，以更好地了解正在发生的事情：

1. Lets convert the 0x47455420 to ascii 
    ===> GET 
    ===> tcp[((tcp[12:1] & 0xf0) >> 2):4] = GET
2. Examine the inner tcp filter: (tcp[12:1] & 0xf0) 
    ===> the 0xf0 == 0000 0000 1111 0000 ===> I suppose it is save to discard the upper zeros so I can write 1111 0000
    ===> tcp[12:1] == 08 (start filtering from byte 13 (0 based indexing, so you could also say start with the byte that has index 12) for 1 byte, so only 13th byte);
    ===> 08 == 0000 1000
    ===> 0000 1000 & 1111 0000 == 0000 (bitwise and = if both are 1 then end result is one)

这是我困惑的地方。 我在上面提供的超链接中的解释是说

multiply it by four ( (tcp[12:1] & 0xf0)>>2 ) which should give the tcp header length

如果它是零则不可能。 请：

1. 帮我在计算中找到错误（也许我在混合TCP和IP头？）;
2. 提供一些指导我的逻辑是否正确。

这是包：

19:10:30.091065 IP (tos 0x0, ttl 63, id 40127, offset 0, flags [DF], proto TCP (6), length 2786)
10.240.35.81.47856 > 172.17.13.201.8080: Flags [P.], cksum 0xf2ef (incorrect -> 0xb8f8), seq 2263020471:2263023205, ack 4187927811, win 28, options [nop,nop,TS val 1906863883 ecr 214445688], length 2734
0x0000:  1a17 8e8a a3a0 026d 627d 049c 0800 4500  .......mb}....E.
         0,1  2,3  ...  ...  ...  ...  12,13 ...                    <=== byte indexes
         1,2  3,4  ...  ...  ...  ...  13,14 ...                    <=== counting how many bytes
0x0010:  0ae2 9cbf 4000 3f06 ac3b 0af0 2351 ac11  ....@.?..;..#Q..  <=== 0x0010 number correctly identifies that the first two diggits are the 16th byte
         16,17 ... ...
0x0020:  0dc9 baf0 1f90 86e2 f3b7 f99e b503 8018  ................
0x0030:  001c f2ef 0000 0101 080a 71a8 6f0b 0cc8  ..........q.o...
0x0040:  2e78 4745 5420 2f69 636f 6e73 2f75 6e6b  .xGET./icons/unk
0x0050:  6e6f 776e 2e67 6966 2048 5454 502f 312e  nown.gif.HTTP/1.
0x0060:  310d 0a68 6f73 743a 2070 6870 2d6d 696e  1..host:.php-min

Answer 1

tcp[12:1]是从TCP头开始的12个字节的偏移量的字节; 12 不是从数据包开始的偏移量，它是从TCP头开始的偏移量（它是tcp[12:1] ，而不是ether[12:1]或类似的东西）。 “1”是被引用的字节数。

根据作为TCP规范的RFC 793 ，从TCP报头开始的12字节偏移处的字节包含高4位中的数据偏移，低4位是保留位。 数据偏移量是“TCP标头中的32位字数”，“表示数据开始的位置”。

数据包中的数据显示为一系列字节对。 如果将其表示为单个字节序列，则更容易理解，因此：

0x0000:  1a 17 8e 8a a3 a0 02 6d 62 7d 04 9c 08 00 45 00
         eth dest          eth src           etype IP hdr

数据包的前6个字节是以太网目标地址。

数据包的下一个6字节是以太网源地址。

之后的2个字节是以太网类型值; 它是big-endian，所以它的值是0x0800，这是IPv4的以太网类型值。

接下来的2个字节是IPv4标头的前2个字节。 根据作为IPv4规范的RFC 791 ， IPv4报头的第一个字节包含高4位的IP版本和低4位的报头长度。 该字节的值为0x45，因此IP版本为4（对于IPv4应该是这样），标题长度为5.标题长度“是32位字中互联网标题的长度”，因此为5 32位字，或20个字节。

那么，现在，让我们跳过IPv4标头并转到TCP标头：

0x0020:  0d c9 ba f0 1f 90 86 e2 f3 b7 f9 9e b5 03 80 18
               TCP header                          12 13

因此TCP标头的字节12是0x80。 0x80和0xf0是0x80,0x80 >> 2是0x20，即32; 这与该字节的高4位是数据偏移一致，在32位字中，为8 * 4 = 32。

tcp[((tcp[12:1] & 0xf0) >> 2):4]因此，对于此数据包， tcp[32:4] ，即从TCP头开始的偏移量为32的4个字节。

从TCP头开始的32个字节是：

0x0040:  2e78 4745 5420 2f69 636f 6e73 2f75 6e6b
              ^

在那里，这是HTTP请求的“GET”标头，从TCP段数据的开头开始。 有问题的4个字节是“GET”。

所以tcp[12:1] 不是从数据包开始的偏移量，它是从TCP头开始的偏移量（它是tcp[12:1] ，而不是ether[12:1]或类似的东西就像那样）。

并且，在回答有关数据包字节及其含义的问题时：

0x0000:  1a 17 8e 8a a3 a0: Ethernet destination
         02 6d 62 7d 04 9c: Ethernet source
         08 00: Ethernet type/length field - 0x0800 = IPv4

所以数据包的前14个（0x000e）字节是以太网头。

在此数据包中，以太网类型/长度字段为0x0800，因此以太网报头之后的以太网有效负载是IPv4数据包，从IPv4报头开始：

         45: IPv4 version/header length
         00: IPv4 Type of Service/Differentiated Service
0x0010:  0a e2: IPv4 total length
         9c bf: IPv4 identification
         40 00: IPv4 flags/fragment offset
         3f: IPv4 time-to-live
         06: IPv4 (next) protocol - 6 = TCP
         ac 3b: IPv4 header checksum
         0a f0 23 51: IPv4 source address
         ac 11: first 2 bytes of IPv4 destination address
0x0020:  0d c9: second 2 bytes of IPv4 destination address

IPv4标头长度为5，因此IPv4标头为20个字节。 这是最小的IPv4标头长度; 它不能更小，但如果在标题的固定长度部分之后有IPv4选项，它可以更大。 在这种情况下，没有任何东西。

由于协议字段的值为6，因此IPv4有效负载是TCP数据包：

         ba f0: TCP source port (47856)
         1f 90: TCP destination port (8080)
         86 e2 f3 b7: TCP sequence number
         f9 9e b5 03: TCP acknowledgment number
         80: TCP data offset + reserved bits
         18: reserved bits + TCP flags
0x0030:  00 1c: TCP window
         f2 ef: TCP checksum
         00 00: TCP urgent pointer

这是TCP头的20字节固定长度部分; 但是，TCP标头长度为32个字节，因此标头中还有12个字节的TCP选项：

         01: TCP No-Operation option
         01: TCP No-Operation option
         08 0a 71 a8 6f 0b 0c c8: first 8 bytes of TCP Timestamp option
0x0040:  2e 78: last 2 bytes of TCP Timestamp option

TCP报头的长度必须是32位的倍数，即4个字节的倍数; TCP选项的长度可能不是4的倍数 - TCP时间戳选项长度为10个字节 - 因此“无操作”选项用于填充。

所以这32个字节是TCP头; 接下来是TCP有效载荷。 显然，这是在HTTP连接上（数据包被发送到端口8080，这是一个备用HTTP端口），这是HTTP GET请求的开始：

         47 45 54 20 2f 69 63 6f 6e 73 2f 75 6e 6b
0x0050:  6e 6f 77 6e 2e 67 69 66 20 48 54 54 50 2f 31 2e
0x0060:  31 0d 0a 68 6f 73 74 3a 20 70 68 70 2d 6d 69 6e

所以：

• 因为这是在以太网或Wi-Fi网络上捕获的，不是在监控模式下（或者在其他类型的网络上使用以太网接头或适配器或驱动程序提供“假以太网”接头），如同Wi -Fi），数据包将以以太网头开始;
• 由于以太网类型值为0x0800，因此后跟IPv4标头;
• 当IPv4协议值为6时，它后跟一个TCP头;
• 由于其中一个TCP端口号是HTTP（8080）通常使用的端口号，因此可能会跟随某种类型的HTTP数据（但这不保证，但TCP端口号更像是提示）。

对于同一网络上的ARP，你将再次拥有一个以太网头（ ffff ffff是以太网广播地址，因此数据包正在广播，因为通常是ARP请求），以太网类型为0x0806，即以太网ARP的类型值。

对于同一网络上的ICMP，您将再次拥有一个以太网标头，并且您还将拥有一个IPv4标头，因此以太网类型将为0x0800。 对于ICMP，IPv4报头中协议字段中的值将为1。