从原始字节重新组合后，Scapy数据包将具有新的DNS层

Question

我正在尝试发送和接收船尾数据包。 我这样做是通过用scapy构建数据包，使用scapy提供的send函数发送数据包，并使用socket的recvfrom函数将数据包作为rawbytes接收。

似乎是scapy的build功能-将scapy数据包转换为十六进制字符串，有时会在数据包中添加“新” DNS层。

我举个例子：使用build将这个数据包IP()/UDP()/"hello"为十六进制字符串，然后将其与IP(hex_str)重新组装时，我会收到预期的数据包：

<IP  version=4L ihl=5L tos=0x0 len=33 id=1 flags= frag=0L ttl=64 proto=udp chksum=0x7cc9 src=127.0.0.1 dst=127.0.0.1 options=[] |<UDP  sport=domain dport=domain len=13 chksum=0xbd95 |<Raw  load='hello' |>>>

但是，当使用build将此数据包IP()UDP()/"ab"为十六进制字符串，然后将其与IP(hex_string)我收到一个不同的数据包，则可以预期：

<IP  version=4L ihl=5L tos=0x0 len=30 id=1 flags= frag=0L ttl=64 proto=udp chksum=0x7ccc src=127.0.0.1 dst=127.0.0.1 options=[] |<UDP  sport=domain dport=domain len=10 chksum=0xa00b |<DNS  id=24930 |>>>

任何帮助都将受到高度重视！ 谢谢

Answer 1

问题是，53是scapy实现中 UDP运动（源端口）和dport（目标端口）的默认值，而RFC 1035 “域名- 实现和规格”在“ 4.2.1。章”中说。 “：

使用UDP用户服务器端口53（十进制）发送的消息。

因此，似乎scapy试图将您的hex_string解释为IP / TCP / DNS数据包。 似乎更笼统地说，scapy总是尝试将hex_strings解释为协议，该协议与端口号相对应。

如果将UDP端口更改为例如42

packet = IP()/UDP(sport=42, dport=42)/"ab"
hex_string = packet.build()
newPacket = IP(hex_string)

newPacket的表示为：

<IP  [some flags] |<UDP  sport=nameserver dport=nameserver len=10 chksum=0x91ab |<Raw  load='ab' |>>>