协议分析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的键值对方式, 下面列出一些常见的键值对:

命令的规定: 
                   每个命令以\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部分的介绍）。

 

 

 

QQ2011登陆过程分析

命令字	含义
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的方式获取。