导出微信聊天记录并输出

1 备份数据到电脑
导出微信聊天记录并输出_第1张图片2 下载DB.Browser.for.SQLite-3.12.0-win64安装包(资源我已上传csdn),并安装。

3打开db文件。
导出微信聊天记录并输出_第2张图片4 输入个人微信数据库密码数据库密码
导出微信聊天记录并输出_第3张图片在这里网上资料的说法是<手机IMEI号+微信UIN号> 的MD5码前七位。手机IME号获取方式较简单(*#06#),但是微信Uid号码获取方式的微信网页版抓包BUG已经被处理。果断选择笔记本电脑开启热点,使用手机连接,做流量抓包,是否能抓到微信uin值?
笔记本开启热点
导出微信聊天记录并输出_第4张图片12导出微信聊天记录并输出_第5张图片微信网络行为:

  • 程序启动后,优先尝试DNS解析特定域名(support.weixin.qq.com,short.weixin.qq.com,long.weixin.qq.com,wx.qlogo.cn);
    如果DNS查询不可用,程序转为使用hardcode的ip链接服务;
    如果dns可用,返回的ip为根据ISP智能解析的结果,程序使用返回的ip链接服务; 程序仅在注册阶段使用https链接,内容不详;
    程序使用tcp 80/8080链接服务器,其中80为http协议,8080为未知协议;
    80/8080两个端口同时或任何单独一个,均可提供服务; 80端口为短链接,8080为长链接, 程序会优先使用8080端口;
    没有使用udp传输数据;
    当1-2次发送失败时,客户端会弹出提示“当前网络状况不好,是否提交反馈数据”,确认后客户端试图通过web提交反馈数据;

  • 发布的消息对应一个ID(这个id就是UID),消息重传机制确保有限次的重试,重试失败给予用户提示,发送成功会反馈确认,客户端只有收到确认信息才知道发送成功。发送消息可能不会产生新SyncKey。
    基于版本号(SynKey)的状态消息同步机制,增量、有序传输需求水到渠成。长连接通知/短连接获取、确认等,交互方式简单,确保了消息可靠谱、准确无误到达。
    客户端/服务器端都会存储消息ID处理记录,避免被重复消费客户端获取最新消息,但未确认,服务器端不会认为该消息被消费掉。下次客户端会重新获取,会查询当前消息是否被处理过。根据一些现象猜测。
    总体上看,微信协议跨平台(TCP或HTPP都可呈现,处理方式可统一),通过“握手”同步,很可靠,无论哪一个平台都可以支持的很好
    微信协议最小成本为16字节,大部分时间若干个消息包和在一起,批量传输。微信协议说不上最简洁,也不是最节省流量,但是非常成功的。
    若服务器检测到一些不确定因素,可能会导致微启用安全套接层SSL协议进行常规的TCP长连接传输。短连接都没有发生变化 发送消息方式
    发送消息走已经建立的TCP长连接通道,发送消息到服务器,然后接受确认信息等,产生一次交互。

    小伙伴接收到信息阅读也都会收到服务器端通知,产生一次交互等。

    可以确定,微信发送消息走TCP长连接方式,因为不对自身状态数据产生影响,应该不交换SyncKey

详细见 http://www.blogjava.net/yongboy/archive/2014/03/05/410636.html
wireshake 过滤条件抓取需要的数据包
导出微信聊天记录并输出_第6张图片发现微信传输的数据采用加密方式,tcp传输,由于时间原因下阶段继续分析tcp/ip协议。怎么解决呢?

  • 今天看到一个比较有点意思的解决办法,就是有点费手机(需要root)

导出微信聊天记录

如果手机安装恶意APP,会被获取ROOT权限,可能导致个人信息,账号密码的泄露。其次会导致部分手机以后是无法升级官方的系统,比如Vivo OPPO这类手机,ROOT以后升级系统会开不开机,去除ROOT权限也没用,因为系统文件已经被修改了,这种情况只能通过重新刷入完整的官方刷机包解决

你可能感兴趣的:(wireshake,数据加密算法,算法,安全,经验分享)