ipad协议828版
平时我一直用itchat，突然在一个开源网站上发现了一些其他的微信逆向协议。但无一例外，这些协议都是基于网页微信的。大多数都有往群里加好友的功能。但是很少有自动建群自动加好友的。
我的那个可以再加一个功能，就是把接收的消息都存入数据库，然后提供一个消息的备份和查询功能。有了这些数据，可以做一些分析和报表以直观的形式提供给用户。
另外可以把基础的linux和windows命令嵌入到里面。
无论是在微信安装还是运行的时候，普通用户是不会觉察到微信中居然还有一个默默无闻的SQLite数据库。就算在微信的安装目录中，你也不会发现有任何对于SQLite数据库的描述、说明和感谢（基于SQLite的许可协议，不允许以SQLite的名义来推销产品），但是却在用户的文件夹下（C:\Users\xxxxxx\Documents\WeChat Files\xxxx\Msg\）留下一堆以db为扩展名的文件。对于细心的探索者来说，微信留下来的任何蛛丝马迹，都会变成重要的探秘线索。
这些db文件，都是经过加密处理的。即使你怀疑它是一个SQLite数据库文件，但是你根本无法用任何一个SQLite管理器打开。虽然网上有不少的文章告诉你，去到微信中寻找那个密码，然后使用某某工具进行解密还原。先不说这些工具各种各样的莫名其妙的问题，就算你确实可以顺利搞到密码，再到完成了解密，再进行访问，其实已经晚了半拍。当然，你要相信，腾讯的那些顶级程序员，会在保证软件功能和性能的情况下，会为这些探秘者设置各种各样的障碍。至少我们知道，那些db文件的确是一个个SQLite数据库，只是经过了加密处理而已。
直播所用协议的需求
从交互方式来看，流媒体分为点播（VOD）和直播（LIVE）
直播（LIVE):HLS,RTMP,http+MP4,http+flv,RTP+RTSP
点播（VOD):http+MP4,http+flv,HLS,DASH.
从业务场景来看，总结一下常见的应用方案
直播：RTMP,HLS,http+flv
音视频通话：webrtc(RTP),SIP＋RTP
视频点播：http+MP4,http+flv,hls
IPTV：RTSP(信令)＋RTP（媒体）
会议电视：RTP(媒体)＋SIP(信令),H323(信令)+RTP(媒体)
视频监控：国标SIP(信令)+RTP(媒体)，RTSP(媒体)+RTP(媒体)
VOIP：SIP(信令)+RTP(媒体)
延时低，安全，满足单播、组播不同的要求
流媒体协议需要根据目标场景，选择TCP/UDP，再进行应用层协议开发
1. 所有的功能方法 都是异步的， 以微信"click" 按钮点击 事件定位具体功能函数 基本没用，
只能通过搜索 字符串， 通过逆向积累 的一些 企微的对象内存分配函数 或者 内存格式化函数定位
2. 大部分 功能函数都是c++虚函数的形式 ，ida里找不到调用函数的交叉引用，
微信参数都字符串，很好搞， 不同于微信，企微的所有功能函数参数都是 对象的形式，
如果对象结构 不和 原始的结构兼容，功能就调用不通，因为在调用中就出现了异常，功能没有跑到最终的方法。
往往一个功能 需要构造2-3个参数对象，如何让对象结构 和 原始的结构兼容，达到功能可以调通
这个就是企微最难的地方， 这个只能不断的调试，分析，看参数对象结构 到底缺少了什么，
不停的迭代，直到 方法ok为止。
如何构造一个参数对象了，本人的经验 归纳起来有几点
1.使用企微内部函数分配内存，operator+，malloc
2.内部函数构造参数对象
3.补全参数对象的内存结构 原始的结构的差异， 补全一切必要的部分，使call能跑到最终的方法, 做到无bug的call
各种发消息，3步
1.构造 消息内容对象
2. 构造发消息人对象
3.调用发消息函数
修改备注，信息，3步
1.构造 修改人和修改内容 对象
2. 构造 修改介质对象
3. 调用修改函数