关于我尝试抓包微信失败后想到的新方法居然和奥特曼有关~

以前 微信网页版 还可以登录的时候，我们还可以使用 python 帮助我们实现 自动化操作，调用各种各样的 API ，做做机器人啥的 ，但是现在呢~ 微信网页版 好像不开放了😐

扫码登录都会出现下面的画面 😵

来到之前 很火的 python 库 wxpy， 我看到下面这个场景， 果然也是一片哀嚎 哈哈哈

wireshark 抓包

于是我做了个大胆的决定，尝试用 wireshark 去抓取微信发出的数据包~ （我实在太天真了！🙃）

在电脑上打开微信，参考下面三次握手的图~ 可以看到这里就已经 发出了这么多信息 我晕了😵

这个过程是 TCP 三次握手 ，再加上 HTTPS 加密的一个过程（SSL 开始的部分 😵）

虽然早就知道数据会加密，但是。。网上搜了这么久都没有一个好的解决办法~ 只能说太强了😱

好多知识不懂，我晕了！😐

本以为自己搭个nginx，做下中间人，但是第一步就失败了 ， 看着这个域名 ？ reverse.gdsz.cncnet.net，我才发现我连这个 DNS 都不懂 完蛋了 咳咳~

还是记录下抓到的数据先把~

三次握手

可以看到各发了一个 SYN 还有 ACK

面试常问点~ 为啥要三次呢，不是二次或者四次或者巴拉巴拉~

注意 TCP 的特点是 可靠

一次的话，客户端都不知道自己 发送 的成功了没

两次的话，客户端知道自己 发送 和 接收 都成功了，服务端只知道自己 接收 成功

三次的话 就刚刚好啦， 客户端和服务端都能确定自己 发送 和 接收 都正常

更多次的话就多余啦~

四次挥手

面试常问点~ 为啥要四次呢，不是三次或者五次或者巴拉巴拉~

答： 由于 TCP 是全双工通信的，每次只能关闭一边的，所以要四次才能关闭

C 表示客户端 ，S 表示 服务端

C：我要断开啦

S: 好滴 （其他信息）巴拉巴拉~

S: 我也要断开啦

C: 好滴

（C 还要自己再等一会再关掉）

S 收到就关闭了，C 要等一会，为什么要等一会呢？

因为 TCP 的特点是 可靠 ，所以要确保信息能被 服务端 S 收到，如果服务端没有收到的话，在一段时间后会重新跟客户端 C 说 我要关掉啦 ~ 所以 C 不能那么快关掉~

假设 C 已经关掉了的话，那它只能回复 复位标志 RST 给服务端了。

等的时间和这个等待计时器有关，一般是 2MSL ，它才断开

MSL= maxinum segment lifetime 即最长报文生存时间，2MSL 就是 两倍的 MSL

真实场景如下~

1. 客户端 发送 FIN=1，进入 FIN-WAIT-1 状态

2. 服务端收到信息回 ACK=1，此时服务端进入 CLOSE-WAIT 的半关闭状态 ，客户端收到信息后变成 FIN-WAIT-2 状态

3. 服务端在关闭前还要发送 终止标志位和确认位 FIN=1 ACK=1，然后进入 LAST-ACK 状态，等待客户端断开连接

4. 客户端收到 FIN=1后，也要回服务端一个 ACK=1 , 表示已经收到信息并要断开连接啦，并进入TIME-WAIT 状态，这时TCP连接还没断开，需要等这个时间到了才关闭，这依靠等待计时器 Timer_Wait Timer ，一般 2MSL 后才关闭

总结

虽然没能抓到有用的信息 只能简单复习下 TCP 的 三次握手，四次分手，

但是我还是找到其他有用的插件，而且好像还在持续更新~

现在万事具备，就差一台 MAC 了 😄

地址如下 https://github.com/MustangYM/WeChatExtension-ForMac

功能如下~

计划 B- 奥义 · 真人工智能！

嘿嘿 高大上的计划名😝

既然走 技术路线导出群成员信息 失败了， 那我只也能执行计划 B 了。

虽然就那么几号人~ 我手动复制就几分钟的时间 🙃

但是我还是决定 用我珍藏多年的奥特曼去勾引下楼下的小胖子, 让他帮我用 OCR 软件截截图，记录下有哪些群成员了 （目的还是达到的 哈哈哈哈！）😄