我正在尝试进行 TCP ACK 欺骗。我从 pcap 文件中嗅探一个 ACK 数据包,并在一个循环中发送它,增加它的 ACK 编号和另一个选项字段。
嗅探部分:(Prespoofing)
from scapy.all import *
from struct import unpack, pack
pkt = sniff(offline="mptcpdemo.pcap", filter="tcp", count=15)
i=6
while True:
ack_pkt = pkt[i]
if ack_pkt.sprintf('%TCP.flags%') == 'A':
break
i+=1
del ack_pkt.chksum
del ack_pkt[TCP].chksum
print ack_pkt.chksum, ack_pkt[TCP].chksum
hex2pkt = ack_pkt.__class__
欺骗部分:(未优化)
count=1
while count<5:
ack_pkt[TCP].ack += 1
pkt_hex = str(ack_pkt)
rest = pkt_hex[:-4]
last_4_bit = unpack('!I',pkt_hex[-4:])[0]
new_hex_pkt = rest + pack('>I',(last_4_bit+1))
new_pkt=hex2pkt(new_hex_pkt)
#sendp(new_pkt, verbose=0)
print new_pkt.chksum, new_pkt[TCP].chksum
count+=1
输出是这样的:(正在改变)
None None
27441 60323
27441 58895
27441 57467
27441 56039
发送后,两个数据包之间的平均时间间隔约为 15 毫秒。 (对于 1000 个数据包)
当我用 Wireshark
检查它时,它显示第一个数据包“校验和正确”,其他数据包显示“不正确”。
欺骗部分:(稍微优化)
pkt_hex=str(ack_pkt)
rest1=pkt_hex[:42]
tcp_ack=unpack('!I',pkt_hex[42:46])[0]
rest2=pkt_hex[46:-4]
last_4_bit = unpack('!I',pkt_hex[-4:])[0]
count=1
while count<5:
new_hex_pkt = rest1 + pack('>I',(tcp_ack+1)) + rest2 + pack('>I',(last_4_bit+1))
new_pkt = hex2pkt(new_hex_pkt)
#sendp(new_pkt, verbose=0)
print new_pkt.chksum, new_pkt[TCP].chksum
count+=1
输出是这样的:(没有改变)
None None
27441 61751
27441 61751
27441 61751
27441 61751
发送后,两个数据包之间的平均时间间隔约为 10 毫秒。 (对于 1000 个数据包)
第二种情况的校验和没有改变。这个过程是完全一样的。那么第二个优化案例的问题是什么?为什么在循环中计算的 TCP 校验和对于后续数据包是错误的?
注意:
- last_4_bit 不是校验和字段。
- 我能够在 tcpdump 中看到正在递增的数据包的
ack 编号
。
最佳答案
经过扩展测试,我发现 del ack_pkt[TCP].checksum
删除了校验和。但是我猜,在使用 str(ack_pkt)
转换为十六进制字符串时,它会重新计算校验和。尝试后:
ack_pkt = sniff(offline="mptcpdemo.pcap", filter="tcp", count=15)[14]
del ack_pkt[TCP].chksum
print ack_pkt[TCP].chksum
print str(ack_pkt)
它首先将校验和打印为 None
。但是在打印十六进制字符串时,我能够看到校验和字段不为零并且包含实际重新计算的校验和。
在未优化的代码中,在循环内,数据包被转换为十六进制字符串,因此每次都重新计算校验和。但在优化版本中,转换在循环之外,因此它只携带一个值。
关于python - Scapy TCP 校验和重新计算奇怪的行为,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27222184/