Question

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

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

我举个例子：使用IP()/UDP()/"hello"将此数据包build转换为十六进制字符串，然后使用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' |>>>

但是，在使用IP()UDP()/"ab"将此数据包build转换为十六进制字符串，然后使用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 implementation和RFC 1035＆＃34; DOMAIN NAMES中的UDP运动（源端口）和dport（目标端口）的默认值 - 实现和规格＆＃34;在章节＆＃34; 4.2.1中说。 UDP使用＆＃34;：

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

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

1 个答案: