Question

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

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

取自here

为了更好地了解正在发生的事情而采取的步骤：

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

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

帮助我在计算中发现错误（也许我正在混合使用TCP和IP标头？）;
提供一些指导，说明我的逻辑是否正确。

这是数据包：

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，从the TCP header开始的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个字节。根据{{3}}（IPv4的规范），RFC 791的第一个字节包含高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＆amp; 0xf0是0x80，并且0x80＆gt;＆gt; 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]中的12 不从数据包开头的偏移量，它是 TCP标头开头的偏移量（它是{ {1}}，而不是tcp[12:1]或类似的东西。

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

ether[12:1]

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

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

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

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

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

         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

这是TCP头的20字节固定长度部分;但是，TCP标头长度为32个字节，因此标头中还有12个字节的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标头的长度必须是32位的倍数，即4个字节的倍数; TCP选项的长度可能不是4的倍数 - TCP时间戳选项长度为10个字节 - 因此“无操作”选项用于填充。

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

         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

所以：

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

对于同一网络上的ARP，您将再次拥有一个以太网报头（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是以太网广播地址，因此正在广播数据包，因为通常是ARP请求），以太网类型为0x0806，这是ARP的以太网类型值。

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

在TCPdump中解构BPF过滤器

1 个答案: