windows微信协议|PC微信协议829版

最新windows协议|PC微信协议829版采用最新算法,达到非常稳定的效果,自己研发,功能多,并发量高,稳定好用,不掉线,不封号。mmtls是基于1.3的tls协议简化修改而来,根据某公司的描述,这种安全可行,用于短连接的安全模式,也给了其他的公司启发,一方面,使用https在越狱root环境下,也容易被窥探,所以开发一种通用而安全的短连接加密协议,确实有些必要,我们想看看到底是如何实现的,所以抓个包,PC协议下数据来看看。

windows微信协议|PC微信协议829版_第1张图片

我们如何入手分析呢?
1.抓包
抓包显然是没有办法看到啥的,不过我们只关心短连接,所以我们需要一个环境来触发短连接的mmtls初始化,而且我们只关心mmtls,并不关心其他的信息,所以,我们可以利用一个早期版本,理由是,早期版本可以屏蔽掉长连接,而强制使用短连接。
2.算法
显然我们应该先对算法,有一些了解,甚至我们应该先阅读一下github上的tls1.3的实现,这样我们才能对tls1.3的答题轮廓有些印象,在我们逆向分析的过程中,省去很多的麻烦,所以我们应该先了解以下算法,包括以下算法的原理和使用
windows微信协议|PC微信协议829版_第2张图片

2、获取登录二维码

访问网址:https://login.weixin.qq.com/qrcode/XXXXXX

这里的XXXXXXX就是我们刚才获取的uuid,这个网址直接显示的就是二维码

3、查询是否扫描二维码登录

显示了二维码以后,用户必须用手机微信扫描这个二维码才能登录。(有人会说微信为啥要这么设计?很奇怪的思维。我用电脑很多情况不就是因为手机没在旁边吗。其实是因为安全的考虑)

使用get方法,查询地址:https://login.weixin.qq.com/cgi-bin/mmwebwx-bin/login?uuid=XXXXXX&tip=1&_=时间戳

这里的XXXXXX是我们刚才获取的uuid,时间戳同上。tip在第一次获取时应为1,这个数是每次查询要变的。

如果服务器返回:window.code=201,则说明此时用户在手机端已经完成扫描,但还没有点击确认,继续使用上面的地址查询,但tip要变成0;

如果服务器返回:

window.code=200

window.redirect_uri='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'

则说明此时用户在手机端已经确认登录,window.redirect_uri=后面的这个网址要记下来,接着要访问这个地址。

如果服务器返回:window.code=408,则说明等待超时,继续使用上面的地址查询,但tip=1

4、访问登录地址,获得uin、sid、pass_ticket、skey

用get方法,访问在上一步骤获得访问地址,并在参数后面加上:&fun=new,会返回一个xml格式的文本,类似这样:

0

OK

xxx

xxx

xxx

xxx

1

把这里的wxuin,wxsid,skey,pass_ticket都记下来,这是重要数据。

windows微信协议|PC微信协议829版_第3张图片

采用UDP协议,通过服务器中转方式。因此,现在的IP侦探在你仅仅跟对方发送聊天消息的时候是无法获取到IP的。大家都知道,UDP 协议是不可靠协议,它只管发送,不管对方是否收到的,但它的传输很高效。但是,作为聊天软件,怎么可以采用这样的不可靠方式来传输消息呢?于是,腾讯采用了上层协议来保证可靠传输;如果客户端使用UDP协议发出消息后,服务器收到该包,需要使用UDP协议发回一个应答包。如此来保证消息可以无遗漏传输。之所以会发生在客户端明明看到“消息发送失败”但对方又收到了这个消息的情况,就是因为客户端发出的消息服务器已经收到并转发成功,但客户端由于网络原因没有收到服务器的应答包引起的。
 

你可能感兴趣的:(golang,ipad,微信,开发语言,ios,golang,ipad)