原神抽卡分析

原神抽卡分析

原神的抽卡是该游戏的主要核心玩法，在游戏的名字是祈愿，游戏体验的提升的唯一来源就是抽卡，抽出一个强力的角色可以使游戏的探索难度直接降低一个阶级。以下我们将通过Wireshark对原神抽卡进行抓包分析。

首先进入抽卡界面：

可以看到界面左下角有历史记录，记录着以往抽到的信息。右上角代表原石和纠缠之缘，都是游戏的货币，正上方是卡池的切换，右下角是抽卡选项，而接下来我们首先进行祈愿10次的抽卡，即一次抽10个。点开游戏祈愿时，捕获到以下数据信息报文：

可以看到当游戏进行祈愿时，向原神特定的相关服务器uspider.yuanshen.com发送TCP请求，进行三次握手，连接成功后可以看到，主机申请的尽快交付报文（PSH），根据分析这个是http的报文连接请求。说明抽卡的实时性。

PSH（Push）是TCP协议头部的一个标志位，用于指示接收方应该尽快将收到的数据推送给应用层，而不需要等到接收缓冲区满了再交付数据。在TCP协议中，PSH标志位通常与发送方应用层的写操作相关，用来实现实时性要求较高的数据传输。

当TCP报文段的PSH标志位被置为1时，表示数据在发送方的缓冲区中已经准备好，希望立即传送给接收方的应用层。这通常用于那些需要及时响应的应用，如Telnet等。接收方收到带有PSH标志的TCP段后，会立即将数据交付给上层应用，而不会等待缓冲区满或者等待一定的时间。

总体而言，PSH标志位在TCP协议中用于实现即时性传输，使得发送方和接收方能够更加及时地处理数据。

服务器向主机发送http协议包装的应答，使用的是HTTP/1.1协议，表面服务器进行响应，状态码为100。该状态码说明服务器收到了请求的初始部分，并且请客户端继续发送。 在服务器发送了 100 Continue 状态码之后，如果收到客户端的请求，则必须进行响应。代表连接建立起来。

客户端代理是UnityPlayer，使用的是2017.4.30版本、并用JSON文件附带相关的用户信息，发送object有游戏账号、设备信息、申请时间等。这些都给原神服务器提供进行相关服务的依据，确保游戏的账号的安全性。

服务器接收到收到请求后进行了处理（Status Code : 200），服务器经过对请求报文进行处理之后判断出需要连接保持持久性（keep-alive），值得注意的是在 HTTP/1.0 中，"Connection: keep-alive" 并不是默认的，需要明确指定。而在 HTTP/1.1 中，默认情况下所有连接都被视为持久性连接，不需要额外的 "Connection: keep-alive" 头。之后服务器将以上信息封装成HTTP报文传输回客户端。报文里包含抽卡的结果信息，如是第几抽、抽卡时间、抽中的物品等。将这些信息下载到本地主机，进行相应的处理即可游戏界面表现出抽卡结果。

最后进行TCP的4次挥手结束这次的连接，这就是一整个抽卡过程。抽卡的结果最终以游戏的形式表现出来：

    对以上过程进行总结可得：

1. 根据IP地址进行TCP连接。
2. 申请http连接、并发出抽卡请求。
3. 服务器响应抽卡请求，发送抽卡信息给主机。
4. 结束TCP连接。

抽卡记录调取

进行抽卡记录抽取时，客户端需要进行域名解析（DNS），有对ipv4（A）地址请求也有ipv6（AAAA）地址请求，每个域名对于每一个不同的服务，寻找到合适的域名才能进行分析。

    其中对hk4e-api.mihoyo.com域名的ipv4地址如下（203.107.62.242）。服务器首先将hk4e-api.mihoyo.com域名重定位另一个域名，然后将域名进行域名解析，得到结果为203.107.62.242。从而hk4e-api.mihoyo.com域名的连接都可以用ip地址为203.107.62.242的服务器满足。

我们得到了地址203.107.62.242，对地址为203.107.62.242的报文进行筛选，可以得到以下报文，发现全都是使用TCP协议，而其中最重要的应用数据用TLSv1.2进行封装。我们小组经过以往资料的查询发现，一年前的版本是基于http协议的封装，可抓包得到http的网络地址进行信息查询，而如今原神的抽卡记录查询更新为使用LTSv1.2协议封装，说明原神游戏的工作室对游戏是有进行更新迭代的，无论是从游戏内容上，还是网络的安全上。

       在这里我们还看到了TCP协议进行了虚假重传(Spurious retransmission)，可以得知，这里网络发生了异常，没有收到上一个数据的ACK,所以在超时重传机制下，数据进行再一次的发送，但是服务器在第一个报文发送时就已经接收到报文，故将其定为虚假重传。

"Spurious retransmission"（虚假重传）是指在TCP（Transmission Control Protocol）通信中发生的一种情况，其中某个数据包被错误地认为丢失而进行了不必要的重传。

这种情况可能由网络拥塞、临时性的通信问题、或者接收方延迟等原因引起。通常，TCP协议通过超时计时器（Timeout Timer）来检测是否需要进行数据包的重传。如果发送方在一定时间内未收到确认（ACK）或者其他指示，就会认为数据包丢失，并触发重传。

"Spurious retransmission"可能在以下情况下发生：

1. 网络延迟和波动： 临时性的网络延迟或者波动可能导致接收方在一定时间内未能及时响应，触发发送方的重传机制。
2. ACK丢失： 如果接收方发送的确认丢失，发送方可能错误地认为数据包丢失，而进行虚假的重传。
3. 拥塞： 网络拥塞可能导致数据包的延迟或丢失，触发发送方的重传。

由于收到虚假重传，所以服务器以为对方没有收到ACK，重新发送ACK，然而在该报文到达主机时，前一个超时的ACK报文缓慢地到达了主机。该ACK就被认定为重复确认。

由这些结论可知，有重复确认就一定有虚假重传，有虚假重传不一定有重复确认。

TCP DUP ACK（Duplicate Acknowledgment，重复确认）是指在TCP通信中，接收方收到的确认（ACK）重复了之前已经接收过的确认。这通常发生在某个数据包在传输过程中丢失，接收方收到了后续的数据包，然后在接收方发现数据包丢失后，它发送一个重复的确认通知发送方。

DUP ACK通常是TCP拥塞控制和快速重传机制的信号。当发送方的某个数据包在网络中丢失时，接收方通过发送一个重复的确认通知告诉发送方它收到的最后一个有序的数据包，希望发送方可以快速重传缺失的数据包。这有助于减小重传时延，提高数据传输的效率。

TCP DUP ACK的触发机制可以简单描述为以下步骤：

1. 发送方发送一系列的TCP数据包。
2. 某个数据包在传输过程中丢失。
3. 接收方收到后续的数据包，并发现缺失的数据包。
4. 接收方发送一个重复的确认通知，即DUP ACK，告诉发送方它收到的最后一个有序的数据包。

除此之外，还有提示未捕捉到前一段TCP （previous segment not captured），说明网络确实波动严重，所以需要重新重传TCP,因此会发生虚假重传和重复确认的提示。

另外还有out-of-order提示，说明TCP的到达顺序与原始排序是不一致的，进一步说明网络波动严重。

"previous segment not captured" 是 Wireshark 中的一种提示，通常出现在 TCP 报文的 Acknowledgment Number 字段中。这是 Wireshark 在分析过程中发现在之前的数据包中缺失了一部分，而当前的 Acknowledgment Number 对应的数据段没有被捕获。

TCP 使用序列号和确认号来保证数据的可靠传输。如果 Wireshark 检测到某个 TCP 报文的确认号对应的序列号在之前的数据包中没有被捕获，它就会显示 "previous segment not captured"，表示有一部分数据没有被记录。

这可能是因为在网络中的某个点上，数据包在传输过程中丢失了，或者捕获软件/硬件没有捕获到完整的传输过程。这并不一定表示网络通信出现了问题，而可能只是捕获环境的限制。

以下就是TLS v1.2协议封装的应用数据报文，由主机发送给服务器，可以看出报文是TLS协议是对TCP协议的封装，其中仍保留TCP同步机制（seq,ack,win等）。

而服务器发送给主机的报文如下，大同小异。

根据接收到服务器的信息进行相应的解密得到历史记录信息，辅以本地文件表现出以下界面：

 

这就是抽卡记录的调取，总的来说分为以下几个部分：

1. 域名解析出历史记录服务器IP地址。
2. 根据IP地址进行TCP握手。
3. 进行TLS握手。
4. 在TLS协议上交换应用数据。
5. 主机处理收到的数据，加载历史记录界面，并结束TCP挥手。

以上就是我对原神抽卡抓包的分析，由于是小组作业，且我研究方向不在此，并没有深入地去分析，所以有很多错误的地方，欢迎朋友们批评指正。