首页 > 代码库 > 协议分析TMP
协议分析TMP
最近闲来有事, 分析了一个非常低端(非常低端的意思是说你不应该对她是否能取代你现有的QQ客户端作任何可能的奢望,她只是一个实验性的东西)的手机QQ的协议, 是手机QQ3.0,
所用到的TCP/HTTP通信协议版本是1.4, 也不知道是哪一年release的了, 至少有七八年的历久了吧, 反正就是: 功能非常弱!
主要的分析原因是想学学网络方面的编程经验(这是我第2次弄socket编程 :-) ), 以及学学怎么抓包分析.
主要用到的工具软件
手机QQ3.0: http://www.ruan8.com/soft_5872.html
kEmulator(Java模拟器):http://gamevina.us/kemulator-vh/
Wireshark(协议分析):http://www.wireshark.org/download.html
Java Decompiler(Java查看(和谐)工具):http://jd.benow.ca/
分析流程简要介绍
1.获取服务器信息
网上分析这个版本手机QQ的用户不在少数, 我也了解到这个版本比较容易分析, 协议简单, 所以...
首先, 打开这个网址:http://conf.3g.qq.com/newConf/kjava/aubin2.jsp
(注意使用unicode编码查看, 否则可能乱码) 然后你就会看到类似下面的东西:
SERERCONFIG_NUM=5& SERVERCONFIG_TYPE=KQQTCP,KQQTCP,KQQHTTP,KQQHTTP,KQQHTTP& SERVERCONFIG_URL=socket://58.60.12.177:14000,socket: //211.136.236.88:14000,http://tqq.tencent.com:8000,http: //mconn.tencent.com:14000,http: //kconn.tencent.com:21001&UPDATAECONFIG_NUM=1& UPDATECONFIG_VERSION=2.4.2&UPDATECONFIG_MUST=N& UPDATECONFIG_URL=http://mq.3g.qq.com/g/s?aid=mqq& UPDATECONFIG_HELPTXT=请升级到2.4.3版QQ2005(Java 版)&SMSSERVICE_NUM=2&SMSSERVICE_NAME=24小时在线,关注好友& SMSSERVICE_ADDRESS=10661700,1066170056& SMSSERVICE_TEXT=HQ,SQKJ%2c||QQNO||&SMSSERVICE_HELPTXT=不用手机上网，通过短信就能登陆QQ，累积在线时间真是方便，让你QQ等级不停增长!%0a当前操作需要通过短信操作完成，选择取定将发送一条短信，请根据收到的短信提示完成操作！, 关注此QQ好友，好友一上QQ马上就会有短信通知你手机！随时随地和TA在QQ上“偶遇”，资费10元/月。%0a当前操作需要通过短信操作完成，选择确定将发送一条短信，请根据收到的短信提示完成操作。
其中:
SERERCONFIG_NUM表示目前可以使用的服务器的个数
SERVERCONFIG_TYPE表示服务器类型:KQQTCP表示TCP服务器,KQQHTTP表示HTTP服务器
SERVERCONFIG_URL:服务器地址
......(不重要)
注意:各值以逗号分隔; 键值对间使用&符号连接.
至于手机QQ要使用哪个服务器, 现在还不知道, 反正是其中一个, 过滤试一下就知道了.
2.过滤通信协议
先打开Wireshark进行网络封包过滤: 选择一张活动网卡, 然后start.
应该马上就可以看到, wireshark已经显示了很多数据包... 数据太多, 不便查看, 于是过滤显示一下,
以QQ的第一个tcp服务器为例: 在Wireshark的Filter Expression里面输入过滤表达式, 并点击Apply应用:
用kEmulator运行手机QQ并登录:
接下来, 如果QQ使用了第一个服务器的话, 那么Wireshark将会显示以下信息:
没错, 你没有看错, 协议可以说全部是明文的, 完全就像是HTTP那样的...
比如VER=1.4代表版本号为1.4, CMD=Login表示命令为登录, UIN=***表示QQ...............
3.协议分析
好了, QQ和服务器的所有通信都是基于这种HTTP的键值对方式, 下面列出一些常见的键值对:
| VER=1.4 | 表示当前使用的协议版本, 不过服务器返回的版本可能有所不一致 |
| CON=1 | 这个不知道是什么意思, 通过查看QQ的代码可见其貌似是固定值1 |
| CMD=*** | 当前的命令, 有Login, Logout, Query_Stat2等等. |
| SEQ=*** | 当前命令的序列号, 以此来标识不同的命令序号, 每下一次发送时, 在上一次的基础上加1 |
| UIN=*** | 当前登录的QQ号, 不变 |
命令的规定:
每个命令以\r\n结束, 这就意味着命令字段中不能再出现其它的\r\n, 还有,要把\n换成%0D,\r换成%0D
每条命令都使用UTF-8编码, 同时命令中出现的逗号,&等要转换url编码, 不然要误解释命令.
1. 登录命令: VER=1.4&CON=1&CMD=Login&SEQ={seq}&UIN={qq}&PS={ps}&M5=1&LG=0&LC={lc}&GD={gd}&CKE=\r\n
服务器响应:VER=1.1&CMD=Login&SEQ={seq}&UIN=2933278370&RES=0&RS=0&HI=60&LI=300&SG=***&SSG=207390864\r\n
SEQ序号应该和你发送时一样, 不然就是错的.
RES=0代表服务器成功响应
RS=0代表登录成功,其它均为失败; 若失败:则有相应的RA字段标识错误信息, 比如Password Error!
如果有SID或者COMP字段, 记得保存起来, 因为后面的某些搞不懂的命令还要用它们. 其它的比如什么HI和LI就不知道是什么东西了.
如果出现了VC字段, 则说明需要验证码信息, 我测试了很久, 一直没遇到, 暂时不说这个...
2.取得所有QQ好友及其基本信息
命令:VER=1.4&CON=1&CMD=SimpleInfo2&SEQ={seq}&UIN={qq}&SID={sid}&XP={xp}&UN=0&TO=0\r\n
回复:VER=1.1&CMD=SIMPLEINFO2&SEQ={seq}&&UIN={qq}&RES=0&NP=65535&SN=0&UN=&FC=&NK=\r\n
XP是前面根据login命令计算出来的, 具体可以看我后面的代码.
RES=0同样代表服务器正确响应.
NP=65535表示当前返回了所有的好友信息, 如不是, 需要多次查询, 你应该没有那么多好友吧?
SN表示当前返回的好友基础信息的个数, (注:我全没有写出来)
UN表示好友QQ号, 以逗号分隔(我没列出)
FC表示头像ID
NK表示昵称, 以逗号分隔
3.取得好友状态
命令:VER=1.4&CON=1&CMD=Query_Stat2&SEQ={seq}&UIN={qq}&SID=&XP={xp}&CM=2&UN=0\r\n
回复:VER=1.1&CMD=QUERY_STAT2&SEQ={seq}&UIN={qq}&RES=0&FN=1&SN=2&ST=10,30&UN=..\r\n
FN是不是finish的意思? 不知道.
SN返回信息的个数
ST状态:10-在线,20-离线,30-离开,40-隐身
UN:QQ号, 与状态一一对应
4.发送消息给好友
命令:VER=1.4&CON=1&CMD=CLTMSG&SEQ={seq}&UIN={qq}&SID={sid]&XP={xp}&UN={qq2}&MG={mg}\r\n
回复:VER=1.1&CMD=CLTMSG&SEQ={seq}&UIN={qq}&RES=0
UN代表好友的QQ
MG表示消息, 必须是部分url编码的
5. .............
还有几条命令, 比如加好友, 删除好友, 我就不写了 , 加上有些也没做测试.
4.模拟登录
1. 可以先用GET方式获取到服务器IP信息
GET /newConf/kjava/aubin2.jsp HTTP/1.1
Accept: text/html, application/xhtml+xml,*/*
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/6.0)
Accept-Encoding: utf8
Host: conf.3g.qq.com
Connection: Keep-Alive
[blankline]
2. 然后建立socket并连接到服务器
3.向服务器发送命令
4.处理服务器返回
5...............
5.效果展示
3.完结
文章里面只是简要介绍了一些协议方面的东西, 细节处理, 以及完全的命令列表(我也不全知道)也没有完全列出来,若
需要参考, 还请查看下面的源代码.
参考文章:
手机QQ协议分析 （一）登陆
HTTP/1.1 Request - w3school
未完结的源代码: http://pan.baidu.com/s/1c0iYYDa
作者:女孩不哭
时间:2014年4月6日
联系:QQ-191035066
地址:http://www.cnblogs.com/memset
参考：
微信协议简单调研笔记
微信破解研究总结
Sync协议
道听途说，加上上面参考中都是提到微信使用Sync协议。去年项目中做过参考Microsoft Exchange ActiveSync 协议来优化消息协议的方案，虽经过长时间讨论定稿，但由于一些原因最终没有实现；也从中深知Sync并不是表面上那么简单、那么好用。
Sync 有啥问题呢？
1. SyncKey 生成维护成本
SyncKey 在ActiveSync中为字符串，客户端不需要解析，但服务端实现要用数字自增，需要强一致性，且不能回退。
2. 消息的订阅模式 采用类似Zookeeper的One time triggler 还是每条消息都推送一条通知能
One time trigger能够避免并发通知时，获取消息时重复问题，但增加了交互成本，和客户端实现复杂性。
3. 自己发的消息，SyncKey怎么获取
尤其要支持多端同步发消息，保证消息同步；也只好消息发完在给自己同步一遍(自己设备发的可以不带消息体）
4. 消息推送延时加重
Sync 消息体获取方式：Notify - Ack - get - Mssage, 也就是至少第四个应用包才能返回消息，在移动网络下成本很高。文中提到消息通过单独https请求，那么延时更为严重了（嗯，实测新版本并非如此）。
手机客户端不再Sync协议
抓包分析版本：Android 微信6.0, 抓包分析可参考：android 移动网络实时抓包
在wifi、gprs网络状况下都相同，客户端会依次尝试使用80、8080、443 端口连接服务器；消息发送、接收都使用长连接进行.
协议格式：
4byte Packet Len(包含4字节本身)
2byte Head Len(包含2字节本身) + 2byte Version(1) + 4byte Operation + 4byte SeqId + ….
(Packet Len - Head Len) Body
协议交互方式：
- 客户端请求（一应一答，通过seqid匹配）：
seqid = 1 开始，依次递增，服务器回复相同的seqid 作为应答
- 服务器推送通知（单向）：
seqid = 0，Operation = 7a, 客户端不需要应答
主要业务：
-心跳包：
发起客户端请求，Operation = 0c，长度为16字节，算是最小的包
-发消息：
发起客户端请求，Operation = ed
单点在线时发完消息后，应答携带SyncKey，不再同步，多点在线时，通过通知同步SyncKey，将随后文章分析。
-收消息：
1. 服务器推送消息， Operation = 7a, Body 中携带消息内容
抓包分析时，通过改变消息体大小，可能到接收方第一个包length 也会随之变化，可确认消息是push的。
2. 发起客户端单向请求，即消息的应答Ack
-加密：
未分析，一般来说像whatsapp那样，使用 hash(密码/OTP + 长连接第一个请求获取RandomCode) 做RC4 的密钥
总结：
现在版本的微信消息推送，并非Sync方式，而是推送+ack方式；
从他们协议设计来看，应该最开始用的是Notify + Sync Req + Sync Rsp 方式，因为协议上是不支持服务器发起请求的；
现在改成 Sync 消息+ 单向 Ack Req 的push方式，虽然协议上怪异， 相比Sync 消息接收会更加及时。从以前看到的文章都是说用的Sync协议，应该是是后期版本做了修改，push方式更为高效、而且通过顺序的SyncKey也能够修复丢失的消息。
下面一个通知包示例：
4 byte: 265 PacketLen
2 byte: 16 Head Length
2 byte: 1 Protocol Version
4 byte: 7a Operation
4 byte: 0 SeqId 这是一个通知性消息
4 byte: unknow header
……. Body
Web客户端
web微信客户端使用比较标准的Sync协议，Sync协议也比较适合web长轮询模型。
移动客户端模式下，协议是二进制的而且有加密，很难分析；微信侧重手机端，web端主体协议应该保持与移动端一致，可通过web端推测整体协议实现，json也比较好分析。
接收一条消息后SyncKey变化：
synckey:1_624161340|2_624162225|3_624162051|11_624161867|201_1420112604|1000_1420104656
synckey:1_624161340|2_624162226|3_624162051|11_624161867|201_1420112631|1000_1420104656
可以看出：
- Synckey 有多个，应该是应对不同业务，其中2为为所有个人消息、讨论组消息，其他可能是联系人、朋友圈、订阅号等，201 为当前时间戳。
- SyncKey 的值为数字自增，不是从0开始，应该有个固定的初始值。
- 发消息时，发完需要自己给再自己同步回一下SyncKey。
- 下面是一条消息增量同步结构，一堆要同步字段+是否修改FlagMask，同步协议变得很简洁。
{
"BaseResponse": {
"Ret": 0,
"ErrMsg": ""
}
,
"AddMsgCount": 1,
"AddMsgList": [{
"MsgId": 1625734358,
"FromUserName": "@sssss",
"ToUserName": "@ssssssss2",
"MsgType": 1,
"Content": "捶地笑……",
"Status": 3,
"ImgStatus": 1,
"CreateTime": 1420109883,
"VoiceLength": 0,
"PlayLength": 0,
"FileName": "",
"FileSize": "",
"MediaId": "",
"Url": "",
"AppMsgType": 0,
"StatusNotifyCode": 0,
"StatusNotifyUserName": "",
"RecommendInfo": {
"UserName": "",
"NickName": "",
"QQNum": 0,
"Province": "",
"City": "",
"Content": "",
"Signature": "",
"Alias": "",
"Scene": 0,
"VerifyFlag": 0,
"AttrStatus": 0,
"Sex": 0,
"Ticket": "",
"OpCode": 0
}
,
"ForwardFlag": 0,
"AppInfo": {
"AppID": "",
"Type": 0
}
,
"HasProductId": 0,
"Ticket": ""
}
],
"ModContactCount": 0,
"ModContactList": [],
"DelContactCount": 0,
"DelContactList": [],
"ModChatRoomMemberCount": 0,
"ModChatRoomMemberList": [],
"Profile": {
"BitFlag": 0,
"UserName": {
"Buff": ""
}
,
"NickName": {
"Buff": ""
}
,
"BindUin": 0,
"BindEmail": {
"Buff": ""
}
,
"BindMobile": {
"Buff": ""
}
,
"Status": 0,
"Sex": 0,
"PersonalCard": 0,
"Alias": "",
"HeadImgUpdateFlag": 0,
"HeadImgUrl": "",
"Signature": ""
}
,
"ContinueFlag": 0,
"SyncKey": {
"Count": 6,
"List": [{
"Key": 1,
"Val": 624161340
}
,{
"Key": 2,
"Val": 624162166
}
,{
"Key": 3,
"Val": 624162051
}
,{
"Key": 11,
"Val": 624161867
}
,{
"Key": 201,
"Val": 1420109883
}
,{
"Key": 1000,
"Val": 1420104656
}
]
}
,
"SKey": ""
}
最初，QQ通信协议并没有加密，而是直接采取明文的方式进行传输，到了后来才使用了加密传输，加密算法一直没有变过，使用的是blowfish算法，但是密钥的交换协议变得比较频繁。其实TX也是被逼的，现在的互联网用户比前几年更加注重隐私安全，这么大用户量的通信软件，如果用户与对方之间的聊天信息可以轻易的被第三方破译获取，那么用户量肯定会离开她，而去选择那些能够更加保护好个人隐私的人通信软件。因此，随着时间的推移和技术的发展，以前设计的协议可能会被研发者发现一些弱点，“图谋不轨”者加以利用，会对TX造成一些潜在的风险，他不得不对协议进行修改（QQ2011正式版中的密钥交换中对密码的MD5计算就加入了salt的概念，这个salt就是对应的QQ号码，后面会有详细的描叙）。
QQ协议首选的传输层是UDP，如果UDP不可登陆，那么会再尝试使用TCP进行传输。UDP使用的端口是8000，TCP使用的端口是443，应用协议基本一样，只是在通过TCP进行传输时，前两个字节为协议内容的长度（包括2个字节）。
QQ协议中每个通信内容都带有一个协议头部，如下图：
其中标识1一个字节，版本号、命令字和序号都是2个字节，QQ号码有4个字节，接下来是数据部分（已加密），最后是一个尾部标识1个字节。
在进行协议还原的时候，最关心的就是协议头部的命令字，需要根据不同的命令字，来进行相应的处理，最终获取密钥解密聊天内容。
QQ登陆协议密钥交换过程，首先我们使用Wireshark抓报文分析，观察主要用到的命令字（见上一篇Header部分的介绍）。
| 命令字 | 含义 |
| 1、Touch Information(0×0091) | 根服务器SAY HELLO，如果对该报文做一些小动作，可以让QQ认为，TX的服务器或网络不能访问… |
| 2、Login Request(0x00ba) | 未知，可以不进行处理。 |
| 3、Login Verify(0x00dd) | 向服务器发送登陆请求，需要使用密码进行运算作为密钥才能机密该报文，解密的报文中包含对第4步的解密密钥。 |
| 4、Login get Information(0x00e5) | 未知，但是服务器返回的报文你必须得知道，因为这个报文中包含解密会话密钥报文（第6步）的密钥。 |
| 5、Login verify E3(0x00e3) | 未知，可以不进行处理。 |
| 6、Login send Information(0×0030) | 客户端向服务器发送sessionKey，使用第4步获取的密钥进行解密。 |
1、Touch Information(0×0091)
这个报文无需关心，是客户端向服务器在SAY HELLO…
2、Login Request(0x00ba)
未知，在此处并不重要。
3、Login Verify(0x00dd)
非常重要！！获取会话密钥首先得解密该报文。但是要解密该报文，必须得知道该登陆QQ用户的密码，而用户密码只有用户和TX知道，第三方是不知道的（也有可能存在“不可思议”的第三方…）。数据传输过程中使用的加密算法是blowfish，这个算法目前从公开的资料上来说，还没有发现漏洞。因此，要实时获取用户的聊天信息，除非已经知道密码了，或者已经暴力破解了密码（这里简单介绍一下怎么进行暴力破解，这里的暴力破解，当然不是模拟一个QQ客户端不停的向TX服务器发送登陆请求，这样太慢了，而且TX那边也会有记录。首先，得分析出这个报文的密钥生成算法[不是简单的直接使用密码作为密钥]，加密算法（这个已知，是blowfish），第二，需要将对方的登陆报文截取保存到文件，然后写一个程序，不停拼接字符串、数字、标点符号进行组合，根据第一步分析它密钥的生成方法生成出密钥，然后作为blowfish算法的密钥，去解密报文，如果解密成功，恭喜你，你暴力破解到了一个QQ密码。但是这种概率比较小，即使有一些，这些号码的价值不大，扯远了…)。
LoginVerify报文的解密密钥生成方法，在QQ2011版本之前，是MD5(MD5(PWD))，对QQ的密码做了两次MD5运算。但是QQ2011版本（包括2011版本）之后，这个算法做了一点修改，就是：MD5(MD5(PWD+QQ_NUM))，这个修改其实是非常有必要的，为什么呢？因为随着硬件技术的发展，以及前些年MD5彩虹表的推出，简单密码的MD5值非常容易就能从彩虹表中找出对应MD5值，从而得到原始字符串密码，即使TX做了两次的MD5运算。在彩虹表的推出或以前（因为我也不知道是在这以前还是以后，呵呵），在执行MD5运算时，就有了加SALT的说法，很形象！加盐，在这里，QQ_NUM就是盐，这样就加大了使用彩虹表破解的难度。
使用密码根据以上的算法得出解密密钥，解密Login Verify报文后，会得到一个新的密钥，这个密钥暂且就叫做verify_key。
Login Verify Reply(0x00dd)
服务器对客户端Login Verify报文的响应，这个报文需要verify_key作为密钥进行解密，得出一个新的密钥-verify_reply_key。
4、Login get information(0x00e5)
客户端接收到服务器的Login Verify Reply报文后，会使用verify_reply_key加密数据发送到服务器，而这里面又包含了一个key – get_info_key。
5、Login verify E3(0x00e3)
未知，此处可以不进行处理。
6、Login send Information(0×0030)
使用get_info_key解密该报文，得到会话KEY – session key。
回想一下：密码是关键，有了密码才能解密Login Verify(0x00dd)报文，解密了Login Verify(0x00dd)，才能解密后续的的报文。其步骤是：passwd -> verify_key -> verify_reply_key -> get_info_key -> session_key。
前面两篇简单的介绍了QQ登陆协议密钥交换过程以及所使用的加密算法，知道了这两点，就可以对它的协议进行还原了。
QQDecrypt，通过winpcap抓包，实时对QQ聊天协议进行还原。
除了聊天协议之外，我们还可以对QQ相关的协议进行还原，包括但不限于：
1、QQ文件传输
2、QQ音频传输
3、QQ视频传输
4、QQ密码验证程序
5、QQ密码获取，是的，你没有看错，有一种主动的方法（用户登录时）就可以获得QQ的密码。在网络出口获取，而不是在客户端进行HOOK的方式获取。
协议分析TMP