我们发现这些数据包在 Telstra 的 NEXTG 移动网络上的下行文件传输期间被注入到 FTP-DTP 通道中。我们不确定这些是网络级数据包，还是我们的 3G 调制解调器（基于 HC25）存在问题，或者是我们的防火墙注入了数据流。
使用工具我们注意到 PPP 框架因协议长度错误而失败，因此它们很可能是移动网络数据包。
我希望这里有人可以识别数据包的签名，以便我可以与相应的供应商进行跟进。
这些数据包肯定有其格式：-
数据包 1：00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 01 10 f4 4e 00 00 40 06 2f 13 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 5d a9 01 f7 0c eb 50 10 ff ff 58 b9 00 00
数据包2：00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 00 ff 6b 50 00 00 40 06 b8 22 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 7b 82 01 f7 0c eb 50 10 ff ff a3 79 00 00
数据包3：00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 02 20 5b 50 00 00 40 06 c7 01 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 7c 59 01 f7 0c eb 50 10 ff ff e2 5d 00 00
数据包4：00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 01 38 d8 52 00 00 40 06 4a e7 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 62 42 f9 01 f7 0c eb 50 10 ff ff 20 91 00 00
数据包5：00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 00 d0 4d 58 00 00 40 06 d6 49 cb 7a 9d e9 7b d0 71 52 7a ee 04 08 4b fb 0b 8f 03 5d 51 1a 50 10 ff ff e9 88 00 00
答案1
它看起来像是一系列到端口 1030 和 1032 的 TCP ACK。将转储重新格式化为以下格式后text2pcap可以处理，例如
0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................
0010 01 10 f4 4e 00 00 40 06 2f 13 cb 7a 9d e9 7b d0 ................
0020 71 52 7a ed 04 06 8c 61 5d a9 01 f7 0c eb 50 10 ................
0030 ff ff 58 b9 00 00 ................
0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................
0010 00 ff 6b 50 00 00 40 06 b8 22 cb 7a 9d e9 7b d0 ................
0020 71 52 7a ed 04 06 8c 61 7b 82 01 f7 0c eb 50 10 ................
0030 ff ff a3 79 00 00 ................
0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................
0010 02 20 5b 50 00 00 40 06 c7 01 cb 7a 9d e9 7b d0 ................
0020 71 52 7a ed 04 06 8c 61 7c 59 01 f7 0c eb 50 10 ................
0030 ff ff e2 5d 00 00 ................
0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................
0010 01 38 d8 52 00 00 40 06 4a e7 cb 7a 9d e9 7b d0 ................
0020 71 52 7a ed 04 06 8c 62 42 f9 01 f7 0c eb 50 10 ................
0030 ff ff 20 91 00 00 ................
0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................
0010 00 d0 4d 58 00 00 40 06 d6 49 cb 7a 9d e9 7b d0 ................
0020 71 52 7a ee 04 08 4b fb 0b 8f 03 5d 51 1a 50 10 ................
0030 ff ff e9 88 00 00 ................
您可以将十六进制转储转换为 pcap 文件。第一帧在 Tshark 中如下所示：
Frame 1: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Arrival Time: Dec 1, 2009 08:24:53.000000000
Epoch Time: 1259684693.000000000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 54 bytes (432 bits)
Capture Length: 54 bytes (432 bits)
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
Ethernet II, Src: Watchgua_43:0f:a1 (00:90:7f:43:0f:a1), Dst: Cisco_b8:7b:1a (00:24:c4:b8:7b:1a)
Destination: Cisco_b8:7b:1a (00:24:c4:b8:7b:1a)
Address: Cisco_b8:7b:1a (00:24:c4:b8:7b:1a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Watchgua_43:0f:a1 (00:90:7f:43:0f:a1)
Address: Watchgua_43:0f:a1 (00:90:7f:43:0f:a1)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 203.122.157.233 (203.122.157.233), Dst: 123.208.113.82 (123.208.113.82)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 272
Identification: 0xf44e (62542)
Flags: 0x00
0.. = Reserved bit: Not set
.0. = Don't fragment: Not set
..0 = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0x2f13 [validation disabled]
[Good: False]
[Bad: False]
Source: 203.122.157.233 (203.122.157.233)
Destination: 123.208.113.82 (123.208.113.82)
[Source GeoIP: Australia, Kingston, 04, -27.666700, 153.116699]
[Source GeoIP Country: Australia]
[Source GeoIP City: Kingston, 04]
[Source GeoIP Latitude: -27.666700]
[Source GeoIP Longitude: 153.116699]
[Destination GeoIP: Australia, Terrigal, 02, -33.450001, 151.449997]
[Destination GeoIP Country: Australia]
[Destination GeoIP City: Terrigal, 02]
[Destination GeoIP Latitude: -33.450001]
[Destination GeoIP Longitude: 151.449997]
Transmission Control Protocol, Src Port: 31469 (31469), Dst Port: iad1 (1030), Seq: 1, Ack: 1, Len: 0
Source port: 31469 (31469)
Destination port: iad1 (1030)
[Stream index: 0]
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x58b9 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
所有帧均未携带有效载荷，因此很难确切地说出发生了什么。由于您提到 FTP，因此这些可能只是数据连接 ACK。
答案2
我猜测它们是某种封装的 IP 数据包。
0x0800 == the Ethernet type for IP
0x45 == IPv4 with 5*4=20 byte header
0x00 == Type of Service
0x00d0 == length
0x4d58 == ID
0x0000 == offset
0x40 == TTL (64)
0x06 == protocol (TCP)
有趣的链接：
顺便说一句，我不认为 00:24:c4:b8:7b:1a 或 00:90:7f:43:0f:a1 恰好是您的本地设备的地址，而另一个是远程设备的地址？
答案3
您是否尝试过查看这些数据包Wireshark? 它包含大量针对各种协议的解码器 - 您确定不包括这些流量吗？