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

Question

>我正在尝试发送和接收 SCAPY 数据包。 我通过使用 SCAPY 构建一个数据包，使用 Scapy 提供的send函数发送它，接收数据包作为使用套接字功能的原始字节recvfrom。

似乎是 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) im 接收到预期的不同数据包来重新组装它时：

<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 用法"：

使用 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' |>>>