QQ协议分析总结

QQ传输协议分析

http://www.mamicode.com/info-detail-866314.html

一、 实验目的：

　　在虚拟机下NAT模式下通过Wireshark抓包，分析QQ的传输模式。了解QQ在传输信息过程中用到的协

议。分析在Nat模式下，信息传输的穿透性。

二、 实验环境：

　　Win7 专业版32位（在虚拟机里面）。

　　Win7 旗舰版64位（物理机）

　　QQ版本：TM2013

　　Wireshark

三、 实验内容：

1、 QQ登录

　　1)、UDP登录

　　在虚拟机的win7打开QQ面板，设置登录服务器的类型为UDP

　　启动wireshark，然后开始登录QQ，登录成功等待一会儿停止wireshark的抓包。

　　抓包如图：

　　我们可以看到本地向远程登录服务器183.60.48.174发送了一个UDP的数据包，这个就是IP就是在刚

才设置UDP登录时的系统默认IP，还可以看到这个IP返回了一个UDP的数据包。看来这两个包就应该是登

录验证的包，接下来的几个包的服务器IP变成了183.60.48.165，由于这个IP和登录服务器的IP位于统一

网段，因此我们可以猜测这个IP是腾讯用来存储我们发送的信息的服务器。需要注意的是，在多次实验

下，可以发现服务器不止183.60.48.165这一个，这是因为想QQ这样的大吞吐量的信息交互，必须用多台

服务器分流，所以这个IP并不一定是某一个。下面的一些包应该就是心跳包。那个OIQC协议就是QQ用的

协议，其实实际上也是一个UDP包。下面的DNS协议就是因为我的QQ是在虚拟机里面登录的，在向外网交

互信息的时候会通过网关192.168.214.2解析。

　　我们来分析一下登录时候的UDP包

　　从这个图我们可以得知源和目的的IP，mac地址，还有双方的端口号等等一些信息。

 　　数据链路层：

　　目的MAC地址：00 50 56 e3 56 95

　　本机MAC地址: 00 0c 29 ba 59 3c

　　网络层：

　　通过查询资料和分析我们知道：

　　45：版本IPv4，首部长度20字节

　　00：区分服务

　　00-73：总长度175字节

　　36-1e：标识

　　00-00：标志和偏移

　　80：生存时间128

　　11：传输协议UDP(17)

　　传输层：

　　0f-a0：源端口4000

　　1f-40：目的端口8000

　　009b：长度155字节

　　7f-c4：检验和

　　QQ的数据

　　通过查询资料和分析我们知道：

　　02：QQ报文的开头 

　　34-20：QQ客户端的版本号，实验所用版本为QQTM2013

　　08-25：用户请求登陆的命令的序号 

　　67-dc：发送数据的序号  

　　56-a6-d2-5c：用户QQ号码，实验中为1453773404

　　之后的内容为加密的数据内容 

　　最后一个字节03：QQ报文的结尾

　　2)、TCP登录

　　设置如图：

　　启动wireshark，然后开始登录QQ，登录成功等待一会儿停止wireshark的抓包。

　　抓包如图：

　　可以看到几个TCP的包还有一个SSL的包

　　对TCP包分析如图：

　　通过对UDP协议的分析，我们可以看到数据层和网络层的十六进制代码和之前的一模一样，这里我们

就值分析传输层的TCP协议了，如图：

　　通过查询资料和分析我们知道：

　　C4-5e：源端口号50270

　　01- bb：目的端口443

　　45-34-fc-63：序号 

　　00-00-00-00：确认号 

　　80-02：数据偏移，标志 

　　20-00：窗口大小8192字节 

　　7f-3b：检验和 

　　00-00：紧急指针  

　　其余部分为可选字段和填充字节

　　在TCP协议里面我们没有看到QQ的登录验证消息。为什么呢？一看这里还有一个SSL协议，QQ会不会

是通过SSL验证的呢？

　　SSL（(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，

TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。）

　　那么我们来看看这个包：

　　02：QQ报文的开头 

　　34-20：QQ客户端的版本号，实验所用版本为QQTM2013

　　08-25：用户请求登陆的命令的序号 

　　67-dc：发送数据的序号  

　　56-a6-d2-5c：用户QQ号码，实验中为1453773404

　　之后的内容为加密的数据内容 

　　最后一个字节03：QQ报文的结尾

　　可见，这个包的信息和UDP登录时候的一样，那么TCP登录是确实使用了SSL。

2、 心跳消息数据包

　　如图，通过IP地址查询，可以知道119.147.45.40是广东深圳的IP，而深圳是腾讯的老巢。在多次的

抓包中也可以看到这个IP段，所以我们有理由相信，这个IP段是腾讯的。

　　那么我们打开来看看。

　　看到这里，确实有很熟悉哦。通过查阅资料和分析我们知道：

　　通过查询资料和分析我们知道：

　　02：QQ报文的开头 

　　34-20：QQ客户端的版本号，实验所用版本为QQTM2013

　　00-58：用户在线的命令序号 

　　3b-09：发送数据的序号  

　　56-a6-d2-5c：用户QQ号码，实验中为1453773404

　　之后的内容为加密的数据内容 

　　最后一个字节03：QQ报文的结尾

3、 收发信息数据包

　　对方在线的时候

我们看看第一个包：

　　可以看到蓝色字体那里的02是QQ报文的开头，这里需要注意的就是00-cd是客户端向服务器发送消息

的命令序号，1b-db是发送数据序号，其他的都一样。通过几次实验发现，00-cd客户端向服务器发送消

息的命令序号是固定的，而1b-db发送数据序号是会改变的。

而且没每送一个包，服务器是会回复一个包给客户端的。

四、实验总结：

　　通过实验我还发现QQ貌似是会和每一个在线好友建立一个连接，因为当我登录只有一个好友的QQ时

，wireshark抓到的包就几个，而登录有上百好友的QQ时，发现连接数也有数百个。

PS：这是去年10月份我们老师给我们讲网络协议时，自己做的一次对QQ协议的分析，当时自己对于协议

也不是很明白，但是通过查阅资料，还是独立完成了这么一次分析，由于时间过得太久，当时查阅的资

料早已忘记出处。真的很感谢网络上前辈们、朋友们的无私分享，我们今天才得以有那么多资料查阅，

衷心感谢！还要感谢姚老师的指导。文中有错之处，还望批评指出，在此先谢过！

========

一份旧QQ协议体系概述

http://www.qqxieyi.com/fenxi_show.asp?id=40

QQ协议体系概述

1. QQ协议体系概述

2. 请求登录令牌

3. 登录

4. 改变状态

5. 得到好友列表

6. 得到在线好友

7. Keep Alive

8. 得到用户资料

9. 登出

10. 查找用户 

《狂迷 2005-10-28 14:22:26》

QQ的协议非常庞大，这些做一些概述，要注意，不要认为下面的说法一定是对的，只能说目前看起来好

像是这样:

加密解密

QQ的加密解密用的是TEA算法(puzzlebird的说法)，不详细解释了。QQ的包一般都是加密的（包头包尾除

外），但是有个别包是不加密的，以后 如果不做特别说明，则默认这个包是需要加密的。此外，用什么

密钥加密也有不同，不过基本上都是用会话密钥加密，以后如果不做特殊说明，表示是用会话密钥加 密

。这里要注意一下，有时候你收到的包可能不是用会话密钥加密的，比如离线的消息。你人都不在了，

哪里来的会话密钥？所以服务器在你下次登录的时候，会把 你还没收到过的消息用密码密钥加密再传给

你。这是一种特殊的情况，要分清楚。

UDP和TCP

QQ支持UDP和TCP登录（如果使用HTTP代理，则相当于TCP登录），UDP登录没有什么好说的，TCP登录时，

不管什么包的开头两字节都是包长度，这个长度包括了这两个字节。

包头包尾

QQ协议有多种包头，每种包头都分别代表了一类用途的包，但是不是所有的包都有包尾，以下是一些存

在的包头包尾格式参考

包头 包尾 包头之后的固定格式 说明 

0x00 无 发送方QQ版本，或者是服务器版本，2字节 

随机密钥，1字节，如果这个字节是0x23，那么密钥就是0x23232323，这个密钥用来加密发送者和接受者

的QQ号。加密算法: QQ号取反再与密钥异或 

发送者QQ号的加密形式，4字节 

接受者QQ号的加密形式，4字节 

0x00系列的包，用在文件传输过程中，传递控制信息。也会出现在点对点通信中。 

0x02 0x03 源标志, 2字节，表示了这个包从何处来，主要用来标识客户端版本，如果其标识的是服务器

，这个字段的具体用处还不清楚 

包命令, 2字节 

包序号, 2字节, 原则是保证短期内这个序号不要重复就可以，一般我们处理的时候都是递增，到最大再

归0 

0x02系列包主要完成一些基本任务，基本上处理了这个系列的包，QQ的功能就差不多了。 

0x03 无 格式同第一行 0x03系列的包，用在文件传输过程中，传递数据信息 

0x04 0x03 客户端版本号，2字节 

整个的包长，2字节 

序号，2字节 

我的QQ号，4字节 

未知的8字节 

0x04系列的包，用在文件传输过程中，如果使用服务器中转模式传送文件，则用到这些包 

0x06 未知 未知 还没怎么研究过这种包是干什么的 

狂迷 2005-10-28 14:23:43

请求登录令牌

登录QQ，要发的第一个包就是Request Login Token Packet。这个包会向服务器请求一个24字节大小的

令牌（也不一定是24，只能说目前是24字节），然后在接下来的登录中，没有这个令牌，你是登录不 了

的。这个令牌是在服务器端生成的，具体的生成算法我们当然还无从得知，但是它肯定是参考了你的IP

，你的端口，还有你的其他什么信息生成这个令牌的。因 为你把在A机器上得到的令牌用到B机器上，你

就会登录不了，如果你把A机器上的IP给改了，你照样也登录不了。

请求包格式

头部 

未知的1字节，0x00 

尾部 

Note: 此包不加密

回复包格式

头部 

回复码，1字节，0x00表示成功 

登录令牌长度，1字节 

登录令牌 

尾部 

Note: 此包不加密

成功时

操作成功时，核心层会触发QQ_GET_LOGIN_TOKEN_SUCCESS事件，这个事件携带的包是

RequestLoginTokenReplyPacket，可用的字段如下: 

replyCode: byte，回复码 

loginToken: byte[]，包含了得到的登录令牌 

失败时

操作失败时，核心层会触发QQ_GET_LOGIN_TOKEN_FAIL事件，这个事件携带的包是

RequestLoginTokenReplyPacket，可用的字段如下: 

replyCode: byte，回复码 

狂迷 2005-10-28 14:24:14

登录

QQ登录目前有多种模式，比如普通QQ号，电子邮件登录，绑定手机号登录，还有什么普通模式，TM模式

。目前我们只支持普通模式和QQ号登录。

请求包格式

头部 

初始密钥，16字节 

用户的密码密钥加密一个空串得到的16字节 

36字节的固定内容，未知含义 

登录状态，隐身登录还是什么，1字节 

16字节固定内容，未知含义 

登录令牌长度，1字节 

登录令牌 

登录模式，1字节，目前只支持普通模式 

未知1字节，0x40 

后面段的个数，1字节，1个段9字节(猜测) 

段，每次基本都是固定内容，未知含义 

长度不足则全部填0直到符合登录包长度，UDP模式登录请求包长度为416字节 

尾部 

Note: 此包使用初始密钥加密，注意头部之后就是初始密钥，初始密钥是不加密的。

说明 

初始密钥在2004以前用的是一个固定值: 16个0x01字节。2004之后，采用随机密钥 

密码密钥是通过对用户的密码进行2次MD5生成的 

密码密钥加密一个空串是干什么呢？主要是服务器用来验证密码的，如果服务器能用密码密钥解开这16

个字节，那么它就认为密码是正确的。在这里，我们不一定非要加密一个空串，其实任意字符串都可以

，但是你要保证密文只有16个字节。 

登录请求包的固定内容，含义是未知的，而且，也不能说内容是固定的，即使我们把这些字段全部替换

成0，依然能够登录 

回复包格式

回复包可能有多种情况，包体的第一个字节是回复码，可能的取值如下： 

QQ_LOGIN_REPLY_OK: 登录成功 

QQ_LOGIN_REPLY_REDIRECT: 重定向 

QQ_LOGIN_REPLY_PASSWORD_ERROR: 密码错误 

QQ_LOGIN_REPLY_OK： 

头部 

回复码，1字节 

会话密钥，16字节 

用户的QQ号，4字节 

用户的IP，4字节 

用户的端口，2字节 

服务器的IP，4字节 

服务器的端口，2字节 

本次登录时间，4字节 

未知的26字节 

未知服务器1的IP，服务器的作用未知，4字节 

未知服务器1的端口，2字节 

未知服务器2的IP，4字节 

未知服务器2的端口，2字节 

2个未知字节 

2个未知字节 

Client Key, 32字节 

12个未知字节 

上次登录时的IP，4字节 

上次登录时的时间，4字节 

8个未知字节 

尾部 

QQ_LOGIN_REPLY_REDIRECT： 

头部 

回复码，1字节 

用户QQ号，4字节 

重定向的服务器IP，4字节 

重定向的服务器端口，2字节 

尾部 

QQ_LOGIN_REPLY_PASSWORD_ERROR: 

头部 

回复码，1字节 

错误消息字符串 

尾部 

Note: 登录回复包使用密码密钥加密，或者使用初始密钥加密，在处理时，应该先尝试使用密码密钥解

密，如果失败，则再用初始密钥解密。为什么要这样呢，因为你可能密码输入错误，这样的话服务器用

密码密钥加密的包你就解密不了了，所以会用初始密钥加密。

说明 

时间都是4个字节，其表示从1970-1-1开始的毫秒数再除以1000 

Client Key是用在访问一些网络服务时，比如QQ秀，通过Client Key，TX可以直接定位到你的QQ秀页面

，还有什么QQ家园啦，有可能聊天室也要用到这个。 

那些未知的服务器，可能是用来发广告用的，猜想～ 

成功时

登录成功或者重定向时，核心层会触发QQ_LOGIN_SUCCESS事件，这个事件携带的包是LoginReplyPacket

，用户应该检查replyCode的值，然后进行相应的操作：

当replyCode为QQ_LOGIN_REPLY_OK时，有以下字段可用： 

sessionKey: byte[]，会话密钥 

ip: byte[]，用户IP 

port: int, 用户端口 

serverIp: byte[], 服务器IP 

serverPort: int, 服务器端口 

loginTime: int, 本次登录时间 

lastLoginTime: int, 上次登录时间 

clientKey: byte[], Client Key 

当replyCode为QQ_LOGIN_REPLY_REDIRECT时，有以下字段可用： 

redirectIp: byte[], 重定向到的服务器IP 

redirectPort: int, 重定向到的服务器端口 

重定向到零地址时

在登录高峰期，登录重定向时有可能得到一个0地址，这时核心层会触发QQ_LOGIN_REDIRECT_NULL事件，

这个事件携带的包是LoginReplyPacket，不过这个包没有什么可用信息。

密码错误时

如果密码错误，核心层会触发QQ_LOGIN_PASSWORD_ERROR事件，这个事件携带的包是LoginReplyPacket，

可用的字段如下： 

replyMessage: String, 错误信息字符串 

未知错误时

如果回复码不是以上三种，则核心层会触发QQ_LOGIN_UNKNOWN_ERROR事件，这个事件携带的包是

LoginReplyPacket，但是没有可用字段。 

狂迷 2005-10-28 14:24:47

改变状态

登录之后的第一件事就是切换自己的状态，不然你发不出消息，这个一定要注意了，不是登录成功之后

就能发消息，而是改变状态之后才能发消息。LumaQQ核心层自动处理登录后的状态改变，所以基本上你

可以不管状态改变的事件，就看你的需要了。

请求包格式

头部 

想要切换到的状态，1字节，定义如下 

QQ_FRIEND_STATUS_ONLINE: 在线 

QQ_FRIEND_STATUS_OFFLINE: 离线 

QQ_FRIEND_STATUS_AWAY: 离开 

QQ_FRIEND_STATUS_HIDDEN: 隐身 

是否显示虚拟摄像头，4字节，最低位置1表示显示虚拟摄像头，其他位似乎无用 

尾部 

回复包格式

头部 

回复码，1字节，0x30表示成功，相关常量QQ_CHANGE_STATUS_REPLY_OK 

尾部 

成功时

操作成功时，核心层会触发QQ_CHANGE_STATUS_SUCCESS事件，这个事件携带的包是

ChangeStatusReplyPacket，可用的字段如下: 

replyCode: byte，回复码 

失败时

操作失败时，核心层会触发QQ_CHANGE_STATUS_FAIL事件，这个事件携带的包是

ChangeStatusReplyPacket，可用的字段如下: 

replyCode: byte，回复码 

狂迷 2005-10-28 14:25:42

得到好友列表

登录之后还需要得到好友列表。现在得到好友列表这个包重要性已经不太高了，因为这个包无法得到分

组信息，只能得到列表，你看到现在QQ 2004以上版本都是自动就把你的分组都同步下来，这个光用得到

好友列表的功能做不到，我想这个包现在只是做为兼容性的考虑还存在。

请求包格式

头部 

起始好友列表返回位置，2字节。假设你有10个好友，这个字段你设置成3，那么就从第3个好友开始返回

，预期你应该得到7个好友。那么第三个是怎么界定 的？服务器是按照你的好友的QQ从小到大排序决定

的。另外，为什么需要这个字段，主要是怕你好友太多，一个包得不完，QQ服务器端的设定是一次只返

回50 个好友。 

返回的好友列表是否排序, 1字节。相关常量如下： 

QQ_FRIEND_LIST_SORTED: 排序 

QQ_FRIEND_LIST_UNSORTED: 不排序 

尾部 

回复包格式

头部 

下一次好友列表开始位置，2字节。你的好友很多，还需要再请求，那么你下次要把请求包中的起始位置

字段置成这个值。如果这个字段是0xFFFF，那就是服务器告诉你，你的好友都得到了。和起始位置相关

的常量有： 

QQ_FRIEND_LIST_POSITION_START: 开始请求好友列表。你发第一个包的时候应该把起始位置置为这个值 

QQ_FRIEND_LIST_POSITION_END: 好友已经全部得到 

好友QQ号，4字节 

头像，2字节 

年龄，1字节 

性别，1字节 

昵称长度，1字节 

昵称 

2个未知字节 

1字节扩展标志，bit1表示是否有QQ Show，其他未知 

1字节通用标志 

bit1 => 会员 

bit4 => TCP方式登陆 

bit5 => 开发移动QQ 

bit6 => 绑定到手机 

bit7 => 是否有摄像头 

如果有更多好友，重复3 - 11部分 

尾部 

成功时

操作成功时，核心层会触发QQ_GET_FRIEND_LIST_SUCCESS事件，这个事件携带的包是

GetFriendListReplyPacket，可用的字段如下: 

position: char, 下一个请求包的起始位置 

friends: List, 包含了好友的信息，每个好友的信息由一个QQFriend类封装，请查看

edu.tsinghua.lumaqq.qq.beans.QQFriend.java文件了解这个类的字段信息 

失败时

尚未有操作失败事件的定义，因为我不知道如何才是失败，这么久了，这个操作就从没失败过，所以我

不知道失败的包是什么样子的。 

狂迷 2005-10-28 14:26:20

得到在线好友

一般在得到好友列表之后就是得到在线好友了，当然你也可以先得到在线好友再得到好友列表，这个没

什么限制。不过你可能会想：好友上线下线的时候会收到通 知，那还要得到在线好友干什么呢？因为这

种通知是不可靠的，可能由于种种原因，你经常会收不到这个通知，所以得到在线好友是必须的，QQ的

作法是在 Keep Alive的时候刷新一次来保持最新的在线列表，而Keep Alive是1分钟做一次的。需要说

明的是，这个请求包并非只能得到好友，注意看下面的包格式分析。

请求包格式

头部 

好友类型，1字节。目前发现这个字节置为0x02或者0x03时服务器会有反应，其他都会返回0xFF。置为

0x02时，得到的就是好友，置为0x03 时，得到的是另外一些东西，b好像是系统服务，号码比如

72000001到72000013，就是那些移动QQ，会员服务之类的 

在线好友列表起始位置，1字节，含义同得到好友列表中的起始位置字段，只不过它只根据在线的来排。 

1个未知字节，一般设为0x00 

2个未知字节，一般设为0x0000 

尾部 

回复包格式

头部 

下一个请求包的起始位置，含义同得到好友列表的回复包。相关常量如下： 

QQ_FRIEND_ONLINE_LIST_POSITION_START: 开始请求在线好友列表。你发第一个包的时候应该把起始位

置置为这个值 

QQ_FRIEND_ONLINE_LIST_POSITION_END: 在线好友已经全部得到 

好友的QQ号，4字节 

未知的1字节 

好友的IP，4字节。这里提一下，这个字段只有在点对点模式时才有值，如果对方设置的是服务器模式，

则这里都是0。但是在以前呢，都是有的，所以这是腾讯 服务器的一个bug，在腾讯发布2005 Beta1的这

段时间左右，它修正了这个bug，服务器模式不再返回ip了。所以珊瑚虫得到ip的效果已经打了折扣了。

不过对于这种这种情况，如来神掌依 然可以得到IP。 

好友的端口，2字节 

未知的1字节 

好友的状态，1字节，相关常量如下，需要注意的是，隐身状态是得不到的，所以只会返回3种状态 

QQ_FRIEND_STATUS_ONLINE: 在线 

QQ_FRIEND_STATUS_OFFLINE: 离线 

QQ_FRIEND_STATUS_AWAY: 离开 

QQ_FRIEND_STATUS_HIDDEN: 隐身 

未知的2字节 

16字节的密钥，用处未知，不过猜想是用在点对点通信中 

2个未知字节 

1字节扩展标志，bit1表示是否有QQ Show，其他未知 

1字节通用标志 

bit1 => 会员 

bit4 => TCP方式登陆 

bit5 => 开发移动QQ 

bit6 => 绑定到手机 

bit7 => 是否有摄像头 

2个未知字节 

分隔符，1字节，0x00 

如果有更多在线好友，重复3 - 15部分 

尾部 

说明: 

回复包的3 - 15部分封装在edu.tsinghua.lumaqq.qq.beans.FriendOnlineEntry.java中，而3 - 10部分

又是封装在edu.tsinghua.lumaqq.qq.beans.FriendStatus.java中的，所以 FriendOnlineEntry里面包

含了一个FriendStatus的对象。 

成功时

操作成功时，核心层会触发QQ_GET_FRIEND_ONLINE_SUCCESS事件，这个事件携带的包是

GetFriendOnlineReplyPacket，可用的字段如下: 

position: byte, 下一个请求包的起始位置 

onlineFriends: List，FriendOnlineEntry类的列表 

失败时

尚未有操作失败事件的定义，因为我不知道如何才是失败，这么久了，这个操作就从没失败过，所以我

不知道失败的包是什么样子的。 

狂迷 2005-10-28 14:26:59

Keep Alive

Keep Alive这个包，用来使QQ服务器知道自己还在线，至于到底你多久不发Keep Alive就认为你不在线

，这个还不清楚，感觉好像挺长的一段时间不发都没事，所以服务器端到底有没有真的在意这个包，我

说不准，QQ自己是1分钟发一次 的，建议实现你自己的程序的时候参考这个间隔，你要2分钟发一次，当

然也可以。这个包本身的作用很小，只能用来得到QQ总在线人数，它最主要的作用还是起 到一个定时器

的用处，你可以顺便在Keep Alive之后做一些事情，比如得到在线好友数，得到群在线成员数，都可以

在这个包之后做，so，把他当成一个固定操作的触发手段吧。

请求包格式

头部 

用户QQ号的字符串形式 

尾部 

回复包格式

头部 

6个域，分别是"0", "0", 所有在线用户数，我的IP，我的端口，未知含义字段，用ascii码31分隔 

尾部 

成功时

操作成功时，核心层会触发QQ_KEEP_ALIVE_SUCCESS事件，这个事件携带的包是KeepAliveReplyPacket，

可用的字段如下: 

onlines: int, 总在线人数 

ip: String, 我的外部IP的字符串形式 

port: int, 我的外部端口 

失败时

目前无失败事件定义，因为它从来就没失败过，所以也不知道失败的时候是什么样的 

狂迷 2005-10-28 14:27:46

得到用户资料

查看用户资料是个很基本的功能了，用户资料有很多，这个就看QQ版本了，那么2004目前是包含了37个

字段，如果是2004 II，恐怕又会多些个性签名之类，你要是用2004 II的协议，自然是要与时俱进的。

请求包格式

头部 

你想查看资料的用户QQ号的字符串形式 

尾部 

回复包格式

头部 

用户资料，37个域，不管域的类型是整数还是什么，都采用字符串形式表示。每个域之间用字符'0'分隔

。这30个域的顺序你不用关心，他们都被包装在了edu.tsinghua.lumaqq.qq.beans.ContactInfo类中 

尾部 

成功时的事件

操作成功时，核心层会触发QQ_GET_USER_INFO_SUCCESS事件，这个事件携带的包是

GetUserInfoReplyPacket，可用的字段如下: 

contactInfo: ContactInfo对象 

失败时的事件

操作失败时，核心层会触发QQ_GET_USER_INFO_FAIL事件，这个事件携带的包是GetUserInfoReplyPacket

，无可用字段 

狂迷 2005-10-28 14:28:23

登出

退出QQ，要发送Logout命令，这个命令是不需要等待回复的，也就是说你发了之后就可以退出程序了，

那么为了保证服务器能够收到你的登出命令，你需要 多发几次，比如像QQ的做法是发送4次，你想发多

少次就随便你了，我觉得这个也不是强制要做的，比如你只想发一次，也行，服务器收不到就收不到吧

，影响也 不大，说不定还能继续长你在线时间呃。

请求包格式

头部，包序号需要指定为0xFFFF，但是这个只是QQ的做法，指定为其他的是否可以，没有试验过，你感

兴趣可以试试 

用session key加密的password key 

尾部 

这个包没有回复包，所以也没有相关联的事件了。 

狂迷 2005-10-28 14:28:56

查找用户

QQ有很多种查找方式，这里是最简单的一种查找方式，2004版本开始有了高级查找，我们后面再介绍。

以前我们只能查找全部在线用户，或者根据用户的一些特定信息查找（叫做自定义查找)。所以这个命令

又包含两种搜索方式。

请求包格式

搜索方式的相关常量如下: 

QQ_SEARCH_ALL: 查找全部在线用户 

QQ_SEARCH_CUSTOM: 自定义查找 

搜索方式为QQ_SEARCH_ALL时: 

头部 

搜索方式，1字节 

1字节分隔符: 0x1F 

页号的十进制字符串形式，从0开始。你应该知道在线用户是很多的，所以要分成多页来显示。实际上这

个页号是否真的有用也不好说，你如果不停的请求得到第0 页的用户，你会发现返回结果都不一样，所

以，这个页号有没有用很难说，不知道服务器是怎么做的。按照常理呢，你还是在程序中递增这个页号

吧。 

尾部 

搜索方式为QQ_SEARCH_CUSTOM时: 

头部 

搜索方式，1字节 

1字节分隔符: 0x1F 

要搜索的用户的QQ号的字符串形式 

1字节分隔符: 0x1F 

要搜索的用户的昵称 

1字节分隔符: 0x1F 

要搜索的用户的email 

1字节分隔符: 0x1F 

页号的字符串形式 

1个字节，0x00，应该是结束符吧，因为前面是页号，考虑c语言的字符串表示方式，这个应该是页号的

结束符 

尾部 

对于那些不存在的条件，把这个字段置为空就是了 

回复包格式

搜索的结果，有两种情况，一种是搜到了一些用户，一种是没搜到，这好像是废话哈？嗯，那么重要的

是这种结果之后的含义，没搜到简单啊，那你就应该停止发送搜索请求了。要是搜到了呢？还继续搜不

？这个当然就看你自己了，你想继续就继续，但是要记得把页号加1。 

没搜到时： 

头部 

字符串"-1"，变成16进制就是0x2D31 

尾部 

搜到时: 

头部 

用户的资料，每个用户有4个字段，字段的顺序是"QQ号，昵称，地区，头像号码"，注意这些字段都是字

符串形式。所以为了分隔这些字段，同时为了分隔这些 用户，这里面有两种分隔符：0x1F用来分隔用户

，0x1E用来分隔用户的4个字段。要注意的是边界的情况，因为头像号码是最后一个字段，所以头像号码

后 面不是0x1E而是0x1F。那么自然QQ号前面也是0x1F。另外，第一个用户前面没有0x1F。搜索的结果被

封装在 edu.tsinghua.lumaqq.qq.beans.UserInfo中，一个用户对应一个UserInfo。 

尾部 

成功时

操作成功时，核心层会触发QQ_SEARCH_USER_SUCCESS事件，这个事件携带的包是SearchUserReplyPacket

，可用的字段如下: 

finished: boolean, true表示后面还可能有更多的匹配，你应该页号加1继续搜 

users: java.util.List，里面存放的是UserInfo对象 

搜索结束时

操作成功时，核心层会触发QQ_SEARCH_USER_END事件，这个事件携带的包是SearchUserReplyPacket，可

用的字段如下: 

finished: boolean, 既然是搜索结束，这个字段当然是true 

失败时

因为目前未知还没失败过，所以不知道失败时候的模样，自然也没有失败的事件了

========