QQ协议体系概述.doc

协议体系概述转 B : httD：// 1 e3f8621 f31 ad57616.html1. 协议体系概述2. 请求登录令牌3. 登录4. 改变状态5. 得到好友列表6. 得到好友7. Keep Alive8. 得到用户资料9. 登出10. 杳找用户的协议非常庞大，这些做一些概述，要注意，不要认为下面的说法一定是对的，貝能说 目前看起来好像是这样：加密解密的加密解密用的是TEA算法（puzzlebird的说法），不详细解释了的包一般部是加密 的（包头包尾除外），但是有个别包是不加密的，以后如果不做特别说明，则默认这个包是 需要加密的此外，用什么密钥加密也有不同，不过基本上都是用会话密钥加密，以麻如果 不做特殊说明，表示是川会话密钥加密这里要注意一下，有时候你收到的包可能不是用 会话密钥加密的，比如离线的消息你人都不在了，哪里来的会话密钥？所以服务器在你下 次登录的时候，会把你还没收到过的消息用密码密钥加密再传给你这是一种特殊的情况, 要分清楚UDP和 TCP支持UDP和TCP登录（如果使用HTTP代理，则相当于TCP登录），UDP登录没有什 么好说的，TCP登录时，不管什么包的开头两字节都是包长度，这个长度包括了这两个字 节。

包头包尾协议有多种包头，每种包头都分别代表了一类用途的包，但是不是所有的包都有包尾， 以下是一些存在的包头包尾格式参考包头包尾包头Z后的固定格式说明0x00无 发送方版木，或者是服务器版木，2字节随机密钥，1字节，如果这个字节是0x23,那么密钥就是0x23232323,这个密钥用来加密 发送者和接受者的号加密算法:号取反再与密钥异或发送者号的加密形式，4字节接受者号的加密形式，4字节0x00系列的包，用在文件传输过程中，传递控制信息也会出现在点对点通信中0x02 0x03源标志,2字节，表示了这个包从何处来，主要用来标识客户端版本，如果其标识 的是服务器，这个字段的具体用处还不清楚包命令,2字节包序号，2字节，原则是保证短期内这个序号不要重复就可以，一般我们处理的时候都是递 增，到最大再归00x02系列包主要完成一些基木任务，基木上处理了这个系列的包，的功能就差不多了 0x03无格式同第一行0x03系列的包，用在文件传输过程中，传递数据信息0x04 0x03客户端版木号，2字节整个的包长，2字节序号，2字节 我的号，4字节 未知的8字节0x04系列的包，用在文件传输过程中，如果使用服务器中转模式传送文件，则用到这些包 0x06未知未知还没怎么研究过这种包是干什么的请求登录令牌登录,要发的第-一个包就是Request Login Token Packeto这个包会向服务器请求一 个24字节大小的令牌（也不一定是24,只能说目前是24字节），然后在接下来的登录中， 没有这个令牌，你是登录不了的。

这个令牌是在服务器端生成的，具体的生成算法我们当 然还无从得知，但是它肯定是参考了你的IP,你的端口，还有你的其他什么信息生成这个 令牌的因为你把在A机器上得到的令牌用到B机器上，你就会登录不了，如果你把A 机器上的IP给改了，你照样也登录不了请求包格式头部未知的1字节，0x00尾部Nole:此包不加密 回复包格式 头部I川复码，1字节，0x00表示成功登录令牌长度，1字节登录令牌 尾部Note:此包不加密成功时操作成功时，核心层会触发_GET_LOGIN_TOKEN_SUCCESS事件，这个事件携带的包 是 RequestLoginTokenReplyPacket,可用的字段如下：replyCode: byte,冋复码登录登录目前有多种模式，比如普通号，电了邮件登录，绑定号登录，还有什么普 通模式，TM模式目前我们只支持普通模式和号登录请求包格式头部初始密钥，16字节用户的密码密钥加密一个空串得到的16字节36字节的固定内容，未知含义登录状态，隐身登录还是什么，1字节16字节固定内容，未知含义登录令牌长度，1字节登录令牌登录模式，1字节，目前只支持普通模式未知1字节,0x40后面段的个数，1字节，1个段9字节（猜测）段，每次基本都是固定内容，未知含义长度不足则全部填0育到符合登录包长度，UDP模式登录请求包长度为416字节尾部No©此包使用初始密钥加密，注意头部之麻•就是初始密钥，初始密钥是不加密的。

说明初始密钥在2004以前用的是一个固定值：16个0x01字节2004 Z后，采用随机密钥 密码密钥是通过对用户的密码进行2次MD5生成的密码密钥加密一个空串是干什么呢？主要是服务器用来验证密码的，如果服务器能用密码密 钥解开这16个字节，那么它就认为密码是正确的在这里，我们不一定非要加密一个空串, 其实任意字符串都可以，但是你要保证密文只有16个字节登录请求包的同定内容，含义是未知的，而且，也不能说内容是固定的，即使我们把这些字 段全部替换成0,依然能够登录回复包格式冋复包可能有多种情况，包体的第一个字节是冋复码，可能的取值如下：_LOGIN_REPLY_OK:登录成功_LOGIN_REPLY_REDIRECT:重定向_LOGIN_REPLY_PASSWORD_ERROR:密码错误_LOGIN_REPLY_OK：头部回复码，1字节会话密钥，16字节用户的号，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个未知字节尾部_LOGIN_REPLY_REDIRECT:头部回复码，1字节用户号，4字节重定向的服务器IP，4字节重定向的服务器端口，2字节尾部_LOGIN_REPLY_PASSWORD_ERROR:头部冋复码，1字节错谋消息字符串尾部Note:登录冋复包使用密码密钥加密，或者使用初始密钥加密，在处理时，应该先尝试使用 密码密钥解密，如果失败，则再用初始密钥解密。

为什么要这样呢，因为你可能密码输入错 误，这样的话服务器用密码密钥加密的包你就解密不了了，所以会用初始密钥加密说明时间都是4个字节，其表示从1970-1-1开始的毫秒数再除以100()Client Key是用在访问一些网络服务时，比如秀，通过Client K巳y, TX可以直接定位到 你的秀页面，还有什么家园啦，有可能聊天室也要用到这个那些未知的服务器，可能是用来发广告用的，猜想〜成功时登录成功或者重定向时，核心层会触发_LOGIN_SUCCESS事件，这个事件携带的包是 LoginReplyPacket,用户应该检杳replyCode的值，然后进行相应的操作：当replyCode为_LOGIN_REPLY_OK时，有以下字段可用: sessionKey: byte[],会话密钥ip： byte[J,用户 IPport: int,用户端口serverip: bytef],服务器 IPserverPort: int,服务器端口loginTime: int,本次登录时间lastLoginTime: int, _t次登录时间clientKey: byte[], Client Key当 replyCode 为 _LOGIN_REPLY_REDIRECT 时，有以下字段可用： redirectip: byte[],重定向到的服务器IP redirectPort: int,重定向到的服务器端【】重定向到零地址时在登录高峰期，登录重定向时有可能得到一个0地址，这时核心层会触发 _LOGIN_REDIRECT_NULL事件，这个事件携带的包是LoginReplyPacket,不过这个包 没有什么可用信息。

密码错谋时如果密码错误，核心层会触发_LOGIN_PASSWORD_ERROR事件，这个事件携带的包 是LoginReplyPacket,可用的字段如下：replyMessage: String,错误信息字符串未知错误时如果冋复码不是以上三种，则核心层会触发_LOGIN_UNKNOWN_ERROR事件，这个 事件携带的包是LoginReplyPacket,但是没有可用字段改变状态登录之后的第一件事就是切换H己的状态，不然你发不出消息，这个一定要注意了，不是登 录成功Z示就能发消息，而是改变状态才能发消息Luma核心层自动处理登录后的 状态改变，所以基本上你可以不管状态改变的事件，就看你的需要了请求包格式 头部想要切换到的状态，1字节，定义如下_FRIEND_STATUS_ONLINE:_FRIEND_STATUS_OFFLINE:离线_FRIEND_STATUS_AWAY:离开_FRIEND_STATUS_HIDDEN:隐身是否显示虚拟摄像头，4字节，最低位置1表示显不虚拟摄像头，英他位似乎无用尾部 冋复包格式头部冋复码，1字节，0x30表示成功，相关常量_CHANGE_STATUS_REPLY_OK尾部成功时操作成功时，核心层会触发_CHANGE_STATUS_SUCCESS事件，这个事件携带的包是 ChangeStatusReplyPacket,可用的字段如下：replyCode: byte,冋复码失败时操作失败时，核心层会触发_CHANGE_STATUS_FAIL事件，这个事件携带的包是 ChangeStatusReplyPacket,可用的字段如下:replyCode: byte,冋复码得到好友列表登录Z示还需要得到好友列表。

现在得到好友列表这个包重要性已经不太高了，因为这个包 无法得到分纟Ft信息，只能得到列表，你看到现在 2004以上版木部是自动就把你的分组 都同步下来，这个光用得到好友列表的功能做不到，我想这个包现在只是做为兼容性的考虑 还存在请求包格式头部起始好友列表返冋位置，2字节假设你有10个好友，这个字段你设置成3,那么就从第3 个好友开始返冋，预期你应该得到7个好友那么第三个是怎么界定的？服务器是按照你 的好友的从小到大排序决定的另外，为什么需要这个字段，主要是怕你好友太多，一 个包得不完，服务器端的设定是一次只返冋50个好友返冋的好友列表是否排序，1字节相关常量如下：_FRIEND_LIST_SORTED:排序 _FRIEND_LIST_UNSORTED:不排序尾部回复包格式头部下一次好友列表开始位置，2字节你的好友很多，还需要再请求，那么你下次要把请求包 中的起始位置字段置成这个值如果这个字段是OxFFFF,那就是服务器告诉你，你的好友 都得到了和起始位置相关的常量有：_FRIEND_LIST_POSITION_START:开始请求好友列表你发第一个包的时候应该把起 始位置置为这个值_FRIEND_LIST_POSIT。