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 


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