网页版微信抓包和IPAD微信抓包 Wireshark

#在51CTO的第一篇博文#

本来想抓普通网页版微信，但是换了好几个微信号说安全问题无法登陆，，，只能去QQ浏览器的微信（应该是插件）。只是熟悉了一下过程，并没有深入分析微信传输协议（其实是不会）。

网页版微信

一：实验目标

1.认识web端微信通过TCP建立连接和使用SSL/TLS协议进行数据加密的过程。 2.抓包分析IOS端微信收发的某种数据。

二：实验过程与分析 1.先查看本机的IP地址。

2.打开浏览器准备登录微信网页版。扫码的时候查看抓的包，其中有个DNS数据包询问extshaort.微信.qq.com的IP地址。

查询报文：DNS查询报文为标准查询即通过主机名查询对应的IP

这是192.168.31.1回复的DNS报文，查询本机网络信息。

192.168.31.1是本地的DNS服务器，所以询问也是通过学校的DNS服务器。然后再通过校外的DNS服务器找到相关服务器的IP地址，当然回复过程也是先到本地DNS服务器再发送到本机。

DNS回复报文

从DNS回复报文中可以看出网页版微信的IP地址有多个，为了应对大流量的访问包括避免宕机影响业务，大企业或者大型服务都会有多个服务器。 从接下来的报文中可以看出用户选择了223.166.152.101这个服务器进行访问连接。因为DNS查询后有一定数量的TCP数据包是本机与223.166.152.101之间的。

3.分析上述提到的TCP数据包（三次握手过程）。

看到了源IP是本机IP，目的IP为DNS返回的其中一个IP。分析TCP报文内容，看到了目的Port为80即常见的HTTP协议的端口。 然后标志位 SYN置1，为TCP三次握手中的第一步。说明本机正常通过TCP与微信的服务器建立连接。

服务器回复的报文。其中确认号ACK=x+1，x为请求报文中的0，syn = 1，表示客户端的请求报文有效，服务器可以正常接收客户端发送的数据，同意创建与客户端的的新连接。

客户端收到服务器回复的报文后得知服务器允许建立连接，此时客户端还会再发送一个TCP报文，这个数据包的seq = x+1=1,ack还是为1。表明可以建立连接了。接下来的就是双方的数据传输。

4.三次握手后建立连接后客户端向服务器发送了一个 HTPP post报文，客户端开始提交数据。看HTTP的内容，request URI，而这个URI为..../getloginqrcode，应该就是微信登录的二维码。

5.扫码登录微信

登录后有大量的TCP数据包及HTTP POST和HTTP响应数据包。从这里可以看出这时候与登录前的服务器IP不同，但是都是之前DNS返回的IP之一。可能这种大型业务不同的服务器承载着不同的业务需求。

客户端向微信服务器请求同步数据等数据传输的HTTP。

6.微信使用了应用层与传输层之间的SSL/TLS协议进行数据加密。 6.1 Client Hello开始客户端向服务器发送建立连接的请求：（版本号，随机数等）

支持的加密套件6.2Server Hello，根据请求中携带的内容建立连接版本，加密套件，生成服务器端随机数。

6.3服务器向用户发送由CA签发的证书，验证身份。（Certificate，server Key exchange等）

6.4Change Cipher Spec（通知）

6.5双方可以加密通信。

7.给好友传一张照片

![在这里插入图片描述](/i/ll/?i=20210116185757641.png)

抓包发现还是原来的建立通信的过程

抓包发现了HTTP请求报文，内容是关于uploadmsgimg的。

尝试IOS端的微信抓包分析

1.用PC作为一个无线AP，让移动端接入。查看移动端的IP和MAC地址。

2.将wireshark绑定在这个无线接口，进行抓包分析。

还是先通过DNS查找微信的服务器IP。IP地址和之前的类似。116.128开头。

3.获得登录二维码

在获得二维码过程中，终端和121.51.73.100进行了大量的TCP通信。

观察其中一个报文，发现了之前不太了解的字段SACK。在网上查找相关知识，得知这个字段可以告诉发送方哪些报文段丢失，哪些报文段重传。根据这些信息，发送方可以重传这些真正丢失的字段。

4.登录。经过网上查找发现微信客户端用的是自己改进的mmtls协议。也抓到了相关的mmtls POST数据包。

在刷新微信列表的时候发现有大量的TCP包和其中的HTTP请求包。以下面这个为例：开始有个HTTP Get，应该是下载某个数据，然后服务器向用户发送多个TCP 后，最后接上一个HTTP OK（JPEG JFIF Image）。

一般来说TCP可以发1500个字节，减去40字节的头文件就还有1452个字节，所以一般大于1452TCP也会分段。如上图，一个TCP中包含1440字节数据。TCP segment of a reassembled PDU，TCP层收到上层大块报文后分解成段后发出去。

ACK值相同。

上图是最后的HTTP OK报文，其中包含了之前6个TCP的数据，让我想起了之前做的IP分片，最后也是ICMP重组所有分片。

看到JPEG就知道应该是关于图像数据的GET传输，找到最后的HTTP OK 报文。找到了JPEG File数据段。当时看到了开头的FF D8，就抱着试试看的态度去找了一下JPEG文件的文件格式，发现正是是开头FF D8，结尾是FF D9，数据段也符合。就想着将数据取出生成JPEG文件。

用python将Hex 串写入一个文件并以图片形式存储到本地。
import binascii
# payload为十六进制字符串，如：“ffd8ffe111e0457869...”；经过如下代码转换，可将pic存储为图片形式并可以正常打开
filepath = "C:\\Users\\14112\\Desktop\\yang\\a.jpg"
payload = "FF D8......FF D9" #只取了文件头和尾，数据太长
f=open(filepath,"ab") # filepath为你要存储的图片的全路径
pic = binascii.a2b_hex(payload.encode())
f.write(pic)
f.close()

发现生成的图片可以打开（如下图），

生成了上述图片就去微信列表找头像，发现下面这个群头像正是从抓到的报文中提取出的十六进制数据生成的。

了解到微信使用的是基于TLS的mmtls，能力有限，就不再分析腾讯未公开的协议了。原有的加密是存在业务层，加密的是请求包主体，但是数据包包头是明文，其中还包括用户的id等信息，而且加密的安全性也都待加强，所以腾讯开发了保护Client到Server之前所有网络通信数据、而且加密通信保护对业务开发人员透明的安全通信协议即mmtls。

实验总结：现在我们使用的PC以及移动网络设备每时每刻都运行着各种服务，也和非常多的服务器之间进行数据包的传输，但是基本离不开TCP/IP 还有HTTP等常见的协议。感觉在真实的网络环境抓包比在GNS3上最难的就是无法排除其他服务数据包的干扰，在本机可能一打开wireshark就出现了大量的数据包，所以这时候wireshark使用技巧就尤为重要，学会过滤报文。 分析微信的通信过程中服务器的IP会发送变化，也许是不同的业务使用不同的服务器，开始的时候需要分析DNS，因为开始主机会查询相关服务器的IP地址，从DNS中也可以看出一项大型服务会使用多个服务器，多个IP来保证业务正常。Web版应用基于TLS的加密也表现了web版应用存在一定不安全性。通过协议分析课程和实验也发现了自己存在着很大的不足，自己还有很多要做要学的。