利用Wireshark软件对微信协议的分析

1.接入手机,通过wireshark抓取微信数据包。

2.分析微信的登陆认证过程

3.分析微信的普通聊天过程

4.分析微信的典型应用——附近的人

5.总结:微信的协议

步骤1、配置虚拟AP:

由于微信的pc 页版本不容易操作,针对本次分析,我们使用Android手机系统下的微信客户端进行操作。通过手机连接至pc虚拟的无线 络进行微信的连接,这样通过wireshark软件进行抓包。

win7系统下可以很容易将无线 卡设置为虚拟AP,供其他无线设备接入。

配置脚本如下:

#Vitual_Wifi_setup.bat

netsh wlan set hostednetwork mode=allow ssid=”HappyBoy” key=******

#在GUI界面下,将正在使用的某个 络连接共享给该虚拟AP.

netsh wlan start hostednetwork

netsh wlan show hostednetwork

将手机接入后,可以看到: Number of clients

打开wireshark,能看到在接口列表中已经有虚拟AP了(如图)。手机接入后,打开微信app,点击开始抓包,就能抓到微信数据包了。

步骤2. 分析微信的登陆认证过程:

打开微信客户端,微信开始登录,可以看到手机分配到的IP为192.168.137.87, AP站点的IP为192.168.137.1

第一包数据是一个域名查询,微信客户端向 络查询微信服务器,域名为long.weixin.qq.com的IP地址;

第二包数据是ARP地址解析,AP站点向全 广播,询问192.168.137.87对应的MAC地址;

第三包数据是ARP应答,手机告诉AP站点自己的MAC地址;

第四包数据是第一包DNS查询的应答,将该包数据展开,可以看到:

可以看到,查询到微信域名long.weixin.qq.com的多个服务器IP。接下来TCP的通信过程表明,微信客户端选择了IP为120.204.201.154的主机进行数据传送。

步骤3. 分析微信的普通聊天过程

先是建立TCP连接:第5到第7包数据是TCP的三次握手

首先客户端向服务器发送标志为SYN的连接请求,数据包标 Seq=0;

收到请求后,服务器向客户端发送了带有SYN和ACK的确认应答,发送序 Seq=0,确认序 ACK=1;接下来,客户端向服务器发送确认应答,Seq=1, ACK=1. 连接建立完成。

第8到第19包数据是客户端和服务器之前用HTTP协议相互传送了一些数据。

第18包是HTTP数据包,它的大小为314字节,其中有用数据长度为248字节,数据最后一行为空行,表明数据已经传送完毕,如下图所示:

第20和21包数据是关闭连接。传送完数据后,主机发出带FIN的TCP 文,要求关闭连接,客户端发出确认(第21包数据),连接关闭。

超时会重传:

第39包:未收到第38包数据的确认应答,超时后,开始重传;

第42包:第38包数据仍未收到应答,又超时,重传一次;

第43包:终于收到了第38包数据的应答。

步骤4. 微信-附近的人

用wireshark抓包得到如下数据

首先是DNS解析,展开第二包数据,可以看到

DNS应答返回了域名mapi.mapabc.com的IP:211.151.71.89

mapabc.com是北京图盟科技有限公司的 站,是一家致力于互联 地图、手机地图和相关位置服务的互联 软件技术服务公司,它是高德成员企业。(有个高德地图的app)

随后的几包数据,是客户端和该服务器之间相互交换信息。

查询该IP.发现服务器位于北京。

可以看到,微信客户端的地点信息被收集起来存储在服务器中,当客户端发送附近的人请求时,服务器调用地图信息,通过计算,得到位于附近的用户数据,将它们传给该客户端。

附近的人—用户头像下载过程

第134包:HTTP的GET请求,展开该包:

将请求的地址输入到浏览器,会看到一个用户头像;

第135包是服务器端的TCP协议将该头像分段成两段(第135包和136包),传送给客户端;

第136包标为HTTP包,表示头像传送出去了。

第137和138包客户端收到HTTP传来的头像后,向服务器发TCP确认,传送完成。

三. 实验结论:关于微信协议

1.微信通过内置浏览器和服务器交互数据。

微信在应用层使用HTTP协议传输数据。微信的聊天对话框如下,点击 址链接,会跳转到浏览器模式,打开该消息对应的 页。现在手机QQ和微博客户端都内置了浏览器。而且用wireshark抓包发现微信的通信都是用HTTP协议收发数据的,内嵌浏览器为 络通信接口。

2.微信的数据传输未加密

微信只有在输入密码的初次认证过程中的数据是用SSL加密传输的。其他数据,比如聊天数据,地理位置信息等,传输过程都没有加密(源端加密未知)

总结:微信各个功能的数据传输,几乎全都是用HTTP协议

3.微信不同功能有独立的服务器:

①涉及到位置信息,会调用地图,常用的有:

map.soso.com 搜搜地图

maps.google.com 谷歌地图

mapi.mapabc.com 高德地图

②微信的好多图片文件的访问,都是对wx.qlogo.cn和mmsns.qpic.cn的

③微信登陆的时候,有两个域名:long.weixin.qq.com和short.weixin.qq.com

short.weixin.qq.com是HTTP协议扩展

tcp短连接,运行8080 port,http body为二进制。

提供API:

用户登录验证;

好友关系(获取,添加);

消息sync (newsync),自有sync机制;

获取用户图像;

用户注销;

行为日志上 。

long.weixin.qq.com

tcp 长连接,端口为8080,类似微软activesync的二进制协议。

提供API:

接受/发送文本消息;

接受/发送语音;

接受/发送图片;

接受/发送视频文件等。

4.关于”微信与运营商大战”的思考:

TCP短连接是指通讯双方有数据交互时,建立一个连接,数据发送完成后,则断开此连接,即每次连接只完成一项业务的发送;TCP长连接,是指连接建立后保持较长时间而不释放掉。Android默认的推送服务,采用的是Google的GCM技术,其心跳周期约为28分钟,这才是所谓“慢”的含义——尽可能降低心跳的频度,从而达到省电、省流量的目的。

微信客户端与服务器之间的大部分连接都是TCP长连接,慢心跳。本来是为了能够给用户提供即使提醒和通知的方便并为用户节约耗电。但在中国大陆的2.5G 络中,如果闲置超过大概5分钟,运营商的IP 关会自动释放掉(关闭)连接,心跳周期远远达不到28分钟。为此,Android版本的微信选择以5分钟为周期发送心跳连接。这种过于频繁的心跳连接,加上微信庞大的用户数量,导致了 络信令的严重占用。这是最近微信和 络运营商之间矛盾的原因之一。而且,每一次心跳,都相当于把手机从待机状态唤醒,以5分钟为一个周期,每天最大约300次唤醒,这会严重消耗手机的电量。

因此,从共赢的角度讲,运营商方面,应该升级 络,加速 络建设,合理收费;而腾讯公司应该优化微信软件,尽量减少 络占用,以期能达到一个平衡。其实微信带来的问题远不止信令占用这一项,更重要的是,微信的通信模式,使传统的话音业务和短信业务受到巨大冲击,尤其微信对短信业务的侵蚀非常大,这才是触及运营商利益的最大头。其实这也是一个无法避免的发展趋势,通信业的发展重心,已经开始由话音业务转向 络业务,随着3G和4G 络的建设,相信微信所引起的矛盾最终会得到解决。