微信网页版抓包分析

实验步骤

1. 我打算先用必应搜索页进行练习。

• 由于没有任何抓包经验，在实验刚开始我就遇到了个小问题，我学习到要对一个指定的网站进行抓包，就必须使用WireShark捕获过滤器来过滤掉其他网站的数据包，我使用ip.addr="网站的IP地址"，这样就可以只捕获到目的IP地址或源IP地址为此网站的数据包。

• 问题1：我只能从浏览器顶部搜索栏中知道这个网站的域名，我要怎么知道这个网站的IP地址。

• 解决办法：这个问题很快就解决了，我想到了在命令行ping这个域名就能得到这个网站的IP地址。

• 于是我在WireShark中设置过滤器为ip.addr=202.89.233.100就只捕捉到这个网站的数据包，在我隔天继续进行这个实现时，我又发现一个问题。

• 问题2：我同一台电脑，不同的时间ping同一个域名，ping出来的ip地址也不同

• 原因：当我通过ping命令查询一个域名的IP地址时，DNS服务器将自动解析该域名，并返回一个IP地址。由于互联网上的DNS服务器数量和位置不固定，因此当你不同的时间ping同一个域名时，可能会连接到不同的DNS服务器，从而得到不同的IP地址。此外，一个域名还能同时映射多个IP地址，也可能导致出现这个问题。

• 之后我就开始测试抓包了，设置好WireShark过滤器，打开必应搜索页。

我发现除了TCP的连接还有TLS的数据包咋没有HTTP和HTTPS的数据包。后来查找资料知道了TLS是传输层安全协议，TLS与SSL在传输层对网络连接进行加密（SSL已经被TLS代替），因此想要读取到明文就需要对TLS解密，于是问题3就出来了。 问题3：解密TLS 解决办法：在苦恼时我搜索到了这篇关于解密TLS的文章（ 解密TLS协议全记录之利用wireshark解密_wireshark解密tls-CSDN博客 ）成功解决的这个问题。 我把解决办法总结为以下几步：

• 设置环境变量，创建变量名为SSLKEYLOGFILE的环境变量，路径设置到一个.log为后缀的文件上。

• 打开wireshark->编辑->首选项->Protocols->TLS 设置（Pre）-Master-Secret log filename的内容为刚刚环境变量的路径

• 使用终端打开火狐浏览器，打开必应搜索页后成功解密了TLS

• 在学习的过程中我又了解到了WireShark过滤器的host语法，于是我想着把过滤器设置为host cn.bing.com再抓包一次试试，出乎意料的的是host cn.bing.com与ip.addr=202.89.233.100产生的效果是不一样的，我认为一个是用域名过滤，一个是用域名ping出来的IP作为过滤，效果应该一致，于是问题4就出来了。

• 问题4：WireShark中host cn.bing.com 与 ip.addr=202.89.233.100过滤的效果不同。

• 原因：在Wireshark中，“host”过滤器是指筛选特定主机发送或接收的所有网络流量。而“ip.addr”过滤器则是基于IP地址来过滤网络流量，可以过滤发送到特定IP地址或从特定IP地址接收的网络流量。所以我分析这可能会导致一些包在使用“host”过滤器时被忽略，但可以在使用“ip.addr”过滤器时看到。

2. 正式开始抓包微信网页版

操作步骤：

1. 首先百度搜索找到微信网页版，打开获取域名 ”wx.qq.com”。

2. Win+R打开输入cmd打开终端，输入ping wx.qq.com，获取该网站IP地址120.204.207.247。

1. WireShark 选择捕获WLAN，添加过滤器ip.addr == 120.204.207.247&&tls，过滤掉非微信网页版的报文。 这是打开微信网页版前的WireShark界面，目前没有报文：

1. 使用与抓包必应一样的解密方法，解密TLS密文：

2. 打开微信网页版并扫码登陆，捕捉到的报文：

接下来可以对捕获的报文进行分析(以下分析仅为个人理解，部分分析的正确性能够进行验证)：

• NO.41:这是一条TCP协议的ACK报文，用于确认已经收到的字节序列号。该语句表示客户端已经接收到服务器传输过来的数据，其中ACK报文内容为“[TCP segment of a reassembled PDU]”，表示它是一个TCP分组的重新组装PDU段。

• NO.181:这个报文的类型是 Continuation Data，表示这是一个数据的持续传输，可以推断数据被分成多个片段传输。

• NO.281、284、285:

• 客户端向服务器发送了一个TLS握手客户端请求(Client Hello)报文。该报文告诉服务器，客户端想要进行TLS会话，并传递了相关参数。

• 服务器向客户端回复了一个TLS握手服务器Hello(Server Hello)报文，该报文包括了加密解密数据等参数，作为对客户端请求的响应。

• 客户端向服务器发送了一个TLS握手Change Cipher Spec和Finished 报文。Change Cipher Spec 表示之后的通信都将需要使用前面的Server Hello中发送的秘钥来加密和解密通信数据，而Finished表示这次握手过程已经完成了。(两端之间进行了三次通信，完成了握手，确保两端安全性，下文中出现这个过程就不在详细分析)

• NO.286:报文的类型是GET请求，在这个请求报文中，客户端请求获取一个名为“index.php”的页面资源，根据以往的Web编程经验，可以这是微信网页版首页（因为首页HTML文件通常以index命名）。

• NO.287：服务器向客户端发送了一个New Session Ticket报文。该报文发送可重用的会话密钥，允许客户端和服务器使用现有的TLS连接通信。

• NO.288：服务端回复了一个TCP应答报文，用于确认之前发送的数据包已经全部接收到。

• NO.305：服务器发送了一个TLS协议数据包。此消息类型为TLS segment of a reassembled PDU，表示上一条 TLS 消息是被 TCP 协议划分成多个部分传输的，并在接收端进行了重新组装之后整体传输到了本次报文中。

• NO.309：服务器对刚刚客户端的请求做出的响应，状态码为200表示响应成功，服务器成功返回了index.HTML页面给客户端，于是我的浏览器就显示出了微信网页版首页。

• 验证：通过响应体中的内容我们可以确定这条报文是响应了微信首页给客户端

• NO.323:这是一条TCP协议的网络报文，表示客户端已经接收到服务器发送的数据。

• NO.324：客户端对服务端发送的请求，报文是一个HTTP/JSON协议POST请求方式的网络报文，请求地址为/cgi-bin/mmwebwx-bin/webwxstatreport?

• NO.327: 服务器对客户端的响应，状态码为200 OK表示响应成功，响应给服务端，响应内容没有在响应体中体现，我无法知道具体的响应内容。

• NO.330、332、333:与第3条分析相似，进行了客户端与服务器间三次握手。

• NO.334:客户端发往服务器的HTTP协议，该报文使用HTTP协议，Get的请求方式，请求地址为/jslogin，同时附带了一些请求参数。

• NO.337:服务器向客户端发送了一个New Session Ticket报文。该报文发送可重用的会话密钥，允许客户端和服务器使用现有的TLS连接通信。

• NO.338:这是一条HTTP协议的网络报文，服务器对客户端的响应，状态码为200 OK表示响应成功，响应的类型是HTML，内容是

我推断服务器给客户端响应一个唯一的标识id，并生成一个二维码，这样当我使用手机扫描二维码时，服务端就能知道是谁扫描的。window.QRLogin.code是登录状态码，200表示登录成功，window.QRLogin.uuid是扫码登录时生成的一个唯一标识，用于标识当前登录的用户。在扫码之前，服务器会返回一个uuid，然后客户端会将该uuid生成二维码，并显示在网页中。

• NO.340:这是一条HTTP协议的网络报文，客户端发往服务端的GET请求请求地址为/cgi-bin/mmwebwx-bin/login，同时附带了一些请求参数。loginicon=true：指定登录时需要展示头像。uuid=gYAJN4N3NA==：指定登录的uuid为gYAJN4N3NA==（这个uuid与上文服务器响应的uuid一致）。

• NO.347、350、351：与第3条分析相似，进行了客户端与服务器间三次握手。

• NO.352:这是一条HTTP协议的网络报文，客户端发往主机，该报文是一个GET请求，请求地址为/qrcode/gYAJN4N3NA==，其中gYAJN4N3NA==是请求参数。

• NO.394:这是一条HTTP协议的网络报文，服务端发往客户端，状态码为200 OK，表明请求成功，响应头中的"JPEG JFIF image"说明该响应主体部分是JPEG格式的图片，推测是客户端请求二维码图片。

• NO.416:这是一条HTTP/JSON协议的网络报文，客户端发往服务端，该报文是一个POST请求，请求地址为/cgi-bin/mmwebwx-bin/webwxstatreport?fun=new，请求头中的"JavaScript Object Notation (application/json)"说明该报文的主体部分是一个JSON格式的数据，我推测这报文是向服务端请求是否登录成功（因为当我进入微信网页版后，只要不扫码登录，这个请求就会一直被捕获，我推测这是客户端在轮询请求，客户是否扫描了二维码并登录成功）。

• NO.417:这是一条HTTP协议的网络报文，服务端发往客户端，状态码为200 OK，表明请求成功，响应体内容中看不出什么。

• NO.510:由客户端发往服务端，其作用是通知连接的一端关闭连接，这个报文属于警告级别。

• NO.595:与NO.510类似，关闭了某个连接。

• NO.695:这条报文是一个HTTP协议的报文它表明，服务端发送给客户端，目标 Web 服务器正在响应客户端发送的请求。状态码是 200 (表示请求成功)，并带有一个MIME类型 "text/javascript"。响应体是JavaScript代码,传递了一些参数。

• NO.696:这条报文是一个 HTTP 协议的报文，客户端发往服务端。它是一个 GET请求，客户端想要获取一个经过身份验证的登录凭据，以便登录到一个名为 "mmwebwx-bin" 的 CGI 脚本。loginicon=true 和 uuid 等参数用于标记请求的类型和状态，并帮助服务器进行适当的响应。最后，该请求路径是 "/cgi-bin/mmwebwx-bin/login"。

• NO.765:与NO.695类似，返回体中有：

我认为通过状态码200，也返回了scan的值，可以推断服务端告诉了客户端二维码被扫描了。

• NO.771、774、775：与第3条分析相似，进行了客户端与服务器间三次握手。

• NO.776：这条报文是一个 HTTP GET 请求报文，客户端发往服务端。客户端正在向 Web 服务器请求 webwxnewloginpage 页面。参数 ticket 包含一个经过身份验证的凭证。uuid参数是由服务器生成的唯一标识符。scan 表示客户端正在扫描二维码。

• NO.777:这条报文是一个 TLSv1.3 协议的报文，服务端发往客户端，这个过程允许客户端在与同一服务器再次通信时，单方面重新恢复已有的 TLS 会话，而无需与服务器重新握手，这样可以减少握手次数，从而加快通信速度。

• NO.780:这条报文是一个 HTTP 响应报文，服务端发往客户端。根据这个报文，服务器在响应客户端发送的请求后，回复了一个 HTTP 200 OK 状态码。，这个响应的 MIME 类型为 text/html。

• 虽然出现编码问题，出现了乱码，但是还是可以看出响应的HTML和浏览器的内容是一致的

• NO.781:重复请求登录了，与NO.776一致，导致了后面的重复响应。

• NO.784:通过观察请求体内容和长度与NO.781一模一样，可能是服务端重复返回给客户端登陆后的界面了。

对整个过程的总结分析，并绘制报文流动图：

• 这是我基于对以上抓取报文分析的结果，绘制的整个过程的报文流向图，在绘制报文流向图时，我忽略了一些我认为在这个过程中不那么重要的内容（eg.多次重复的连接，连接的关闭等）。

• 其次我认为这个报文流向图还应该把手机端也添加进去，但是问题是我看不到手机端与微信服务端的数据包，所以只能粗略概括。

最后总结：

• 由于没有抓包经验以及这方面的知识储量不够大，对于很多数据包的内容，端与端的连接有些模糊感，但我尝试着去推测它们，验证它们，这可能导致在我的分析中存在错误的一面和浅薄的一面，但是我觉得对于端与端间数据包的流动，我有了更深层次的认识。