1

试图解构这个 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
4

1 回答 1

4

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

根据TCP 规范RFC 793 ，从TCP 标头开始偏移 12 个字节的字节包含高 4 位的数据偏移量，低 4 位是保留位。数据偏移量是“TCP Header 中 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 个字节是以太网类型值；它是大端的，所以它的值为 0x0800，这是 IPv4 的以太网类型值。

接下来的 2 个字节是 IPv4 标头的前 2 个字节。根据RFC 791（IPv4 规范），IPv4 报头的第一个字节在高 4 位中包含 IP 版本，在低 4 位中包含报头长度。该字节的值为 0x45，因此 IP 版本为 4（对于 IPv4 应该是），并且标头长度为 5。标头长度“是 32 位字中 Internet 标头的长度”，因此为 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”。

所以 12 intcp[12:1]不是数据包开头的偏移量，它是TCP 标头开头的偏移量（它是, not或类似的东西）。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 Timestamp 选项的长度为 10 个字节 - 所以 No-Operation 选项用于填充。

所以这 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。

于 2015-02-08T19:10:21.090 回答