使用 Scapy 缩短 TCP 有效负载会导致 [未捕获 TCP 上一个段]答案

【问题标题】：Shortening TCP payload with Scapy results in [TCP Previous segment not captured]使用 Scapy 缩短 TCP 有效负载会导致 [未捕获 TCP 上一个段]
【发布时间】：2020-02-22 03:28:28
【问题描述】：

我正在尝试通过删除一些字节来修改 TCP 有效负载。

只要将字节替换为相同长度的其他字节而不是将它们剥离，修改包就可以正常工作。

如果字节被剥离，Wireshark 会在转储中显示 [TCP Previous segment not capture] 消息。

我删除了修改后的包的校验和和包长度，以便 Scapy 在发送包时重新计算它们：

# Delete the old checksums
del packet_mod[IP].chksum
del packet_mod[TCP].chksum

# Delete the old packet length
del packet_mod[IP].len

如果我在修改后的数据包末尾也切断了 len(stripped_bytes) ，则修改工作有效，因为重新发送的 TCP 段由接收方添加到修改后的数据包中。

例如：我删除了 20 个字节的 TCP 有效负载。只有当我在有效载荷的末尾还截断了额外的 20 个字节时，修改才会起作用。

我错过了什么？

【问题讨论】：

标签： python tcp wireshark scapy

【解决方案1】：

我不明白这部分是什么意思：

例如：我删除了 20 个字节的 TCP 有效负载。然后修改仅适用，如果我在结尾处还切断了额外的 20 个字节有效载荷。

无论如何，你缺少的是每个 TCP 段都携带一个 TCP 头域——“序列号”域——表明该段的数据内容在字节流中的位置正在通过 TCP 传输。

TCP 接收方使用段序列号和段长度（段长度是根据 IP 数据报的长度计算的传送段）来构建一个连续的字节流收到的流量。例如，如果接收方之前收集到序列位置 200 和下一个传入的所有数据片段如下所示：

  (segment 1) sequence=200 length=80 data='data data data ...'
  (segment 2) sequence=280 length=60 data='more data ...'
  (segment 3) sequence=340 length=70 data='even more data ...'

那么接收者就知道它现在已经收集了所有的数据直到（但不包括）位置 410。由于没有间隙，此数据已准备好传递给应用程序。

请注意，段号 (1)、(2)、(3) 不出现在 TCP 标头。这些数字只是为了让这个描述可以参考一下。

显然，如果段 (2) 已经丢失并且接收者只有收集到的段 (1) 和 (3) 然后接收者会知道接收到的数据有差距。它会确切地知道差距在哪里：它从位置 280 开始缺少 60 个字节。 TCP 承诺提供完整的有序数据流，所以直到该空白被填补，接收方不允许交付任何后面的字节（比如它在段中获得的位置 340 处的 70 个字节 3）到应用程序。如果丢失的字节没有很快到达然后接收方将告诉发送方有关差距和发送方将重新传输丢失的数据。

这就是为什么从 TCP 段中删除字节会导致问题。如果您的程序从段 (2) 中删除了 20 个字节，然后是接收器会看到这个：

  (segment 1) sequence=200 length=80 data='data data data ...'
  (segment 2) sequence=280 length=40 data='more data ...'
  (segment 3) sequence=340 length=70 data='even more data ...'

并且接收方会得出结论，它发现了一个位置 320 处 20 个字节。

如果 Wireshark 正在观察此流量，那么它将得出相同的结论。 TCP 接收方和 Wireshark 都不知道导致缺少字节是段 (2) 已被编辑。 Wireshark 最合理的猜测是丢失的字节在一个段中不知何故没有可供检查，这就是为什么它显示“未捕获上一个片段”消息。它说“以前” 因为它直到它检查才发现有间隙段 (3)，然后是间隙之后的一段。

接收者将像处理任何差距。它将告诉发件人有关间隙并等待丢失要重传的数据。如果接收方得到丢失的数据然后它将填补空白，然后照常继续。如果你继续拦截重传并删除丢失的字节那么接收器会继续报告它有一个gap，并且发送者最终会厌倦重新传输丢失的数据它会放弃 TCP 连接。

这意味着您不能简单地从运行中的 TCP 分段中删除数据并期望 TCP 不会注意到数据丢失。原则上你可以通过删除一些数据然后操纵序列来做到这一点来自发件人和的所有后续段中的编号接收方发送的确认，但这是一项更大的任务。

参考资料：描述了基本的TCP序列号机制在RFC 793 和长期使用序列号提高安全性的最佳实践是在RFC 1948 和在RFC 6528 中正式化为标准。

【讨论】：

感谢您的详细回复！这对我帮助很大！我想在我的情况下用虚拟字节替换字符串会是一个更好的解决方案......