從原始字節重新組合后，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' |>>>