关于我尝试抓包微信失败后想到的新方法居然和奥特曼有关~
以前 微信网页版 还可以登录的时候，我们还可以使用 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
真实场景如下~
- 客户端 发送
FIN=1，进入FIN-WAIT-1状态
- 服务端收到信息回
ACK=1，此时服务端进入CLOSE-WAIT的半关闭状态 ，客户端收到信息后变成FIN-WAIT-2状态
- 服务端在关闭前还要发送 终止标志位和确认位
FIN=1 ACK=1，然后进入LAST-ACK状态，等待客户端断开连接
- 客户端收到
FIN=1后，也要回服务端一个ACK=1, 表示已经收到信息并要断开连接啦，并进入TIME-WAIT状态，这时TCP连接还没断开，需要等这个时间到了才关闭，这依靠等待计时器Timer_Wait Timer，一般2MSL后才关闭
总结
虽然没能抓到有用的信息 只能简单复习下 TCP 的 三次握手，四次分手，
但是我还是找到其他有用的插件，而且好像还在持续更新~
现在万事具备，就差一台 MAC 了 😄
功能如下~
计划B- 奥义 · 真人工智能！
嘿嘿 高大上的计划名😝
既然走 技术路线导出群成员信息 失败了， 那我只也能执行计划B了。
虽然就那么几号人~ 我手动复制就几分钟的时间 🙃
但是我还是决定 用我珍藏多年的奥特曼去勾引下楼下的小胖子, 让他帮我用OCR软件截
截图，记录下有哪些群成员了 （目的还是达到的 哈哈哈哈！）😄
