TCP：seq / ack 编号是如何生成的？
我目前正在开发一个程序，该程序可以嗅探发送到特定地址和从特定地址接收的 TCP 数据包。 我想要完成的是用定制的数据包回复某些收到的数据包。 我已经完成了解析。 我已经可以生成有效的以太网、IP 以及（大部分）TCP 数据包。
我唯一不明白的是 seq / ack 号是如何确定的。
虽然这可能与问题无关，但该程序是使用 WinPCap 用 C++ 编写的。 我正在寻求任何可能对我有帮助的提示、文章或其他资源。
I am currently working on a program which sniffs TCP packets being sent and received to and from a particular address. What I am trying to accomplish is replying with custom tailored packets to certain received packets. I've already got the parsing done. I can already generated valid Ethernet, IP, and--for the most part--TCP packets.
The only thing that I cannot figure out is how the seq / ack numbers are determined.
While this may be irrelevant to the problem, the program is written in C++ using WinPCap. I am asking for any tips, articles, or other resources that may help me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
当建立TCP连接时，每一方都会生成一个随机数作为其初始序列号。 它是一个强随机数：如果互联网上的任何人都可以猜测序列号，就会出现安全问题，因为他们可以轻松伪造数据包注入 TCP 流。
此后，对于传输的每个字节，序列号将增加 1。ACK 字段是来自另一方的序列号，发送回以确认接收。
RFC 793，原始的 TCP 协议规范，可以提供很大的帮助。
When a TCP connection is established, each side generates a random number as its initial sequence number. It is a strongly random number: there are security problems if anybody on the internet can guess the sequence number, as they can easily forge packets to inject into the TCP stream.
Thereafter, for every byte transmitted the sequence number will increment by 1. The ACK field is the sequence number from the other side, sent back to acknowledge reception.
RFC 793, the original TCP protocol specification, can be of great help.
我也有同样的工作要做。
首先，初始的 seq# 将随机生成（0-4294967297）。
然后接收方会计算收到的数据的长度，并将
seq# + length = x的ACK发送给发送方。 序列将为 x，发送者将发送数据。 类似地，接收方将计算长度x + length = y并将ACK作为y发送，依此类推...这就是seq/ack的生成方式...如果你想实际展示它，请尝试在 Wireshark 中嗅探数据包并跟踪 TCP 流并查看场景...
I have the same job to do.
Firstly the initial seq# will be generated randomly(0-4294967297).
Then the receiver will count the length of the data it received and send the ACK of
seq# + length = xto the sender. The sequence will then be x and the sender will send the data. Similarly the receiver will count the lengthx + length = yand send the ACK asyand so on... Its how the the seq/ack is generated...If you want to show it practically try to sniff a packet in Wireshark and follow the TCP stream and see the scenario...
如果我理解正确的话 - 您正在尝试发起 TCP SEQ 预测攻击。 如果是这种情况，您需要研究目标操作系统初始序列号 发电机。
几乎所有主要操作系统中都存在广泛公开的漏洞，因为它们的 ISN 生成器是可预测的。 我没有密切关注后果，但我的理解是大多数供应商都发布了 的补丁随机化它们的 ISN 增量。
If I understand you correctly - you're trying to mount a TCP SEQ prediction attack. If that's the case, you'll want to study the specifics of your target OS's Initial Sequence Number generator.
There were widely publicized vulnerabilties in pretty much all the major OS's wrt their ISN generators being predictable. I haven't followed the fallout closely, but my understanding is that most vendors released patches to randomize their ISN increments.
似乎其余的答案几乎解释了在哪里可以找到有关 ACK 的详细和官方信息，即 TCP RFC
这是一个更实用且“易于理解”的页面，是我在进行类似实现时发现的，也可能有帮助TCP 分析 - 第 2 部分：序列和连接 确认编号
Seems that the rest of the answers explained pretty much all about where to find detailed and official information about ACK's, namely TCP RFC
Here's a more practical and "easy understood" page that I found when I was doing similar implementations that may also help TCP Analysis - Section 2: Sequence & Acknowledgement Numbers
RFC 793 第 3.3 节涵盖了序列号。 上次我在该级别编写代码时，我认为我们只是为持续存在的序列号保留了一个递增计数器。
RFC 793 section 3.3 covers sequence numbers. Last time I wrote code at that level, I think we just kept a one-up counter for sequence numbers that persisted.
这些值引用数据包有效负载开始相对于连接初始序列号的预期偏移量。
参考
These values reference the expected offsets of the start of the payload for the packet relative to the initial sequence number for the connection.
Reference
数字是从双方随机生成的，然后按发送的八位位组（字节）数增加。
Numbers are randomly generated from both sides, then increased by number of octets (bytes) send.
建立连接后序列号递增。 新连接上的初始序列号理想情况下是随机选择的，但许多操作系统都有一些半随机算法。 RFC 是了解更多 TCP RFC 的最佳位置。
The sequence numbers increment after a connection is established. The initial sequence number on a new connection is ideally chosen at random but a lot of OS's have some semi-random algorithm. The RFC's are the best place to find out more TCP RFC.