当前位置：文档之家 › TCPF Packet Data

TCPF Packet Data

  • 格式：rtf
  • 大小：75.88 KB
  • 文档页数：29

TCPF 包数据分析最后修改：2003 年10 月24 日说明：本文档说明的是解密以后的TCPF数据包的字段内容。

有关如何解密，请参阅有关的其它文档。

分析的结果，是基于QQ 2003 (0808) 内部代码0A 1D的版本。

0x0022，登录命令发送方：客户端样本：000: 4A 35 5D 6E AE DB FA 9C008: 96 BE 19 7E A3 E2 B2 48016: 00 00 00 00 00 00 00 00024: 00 00 00 00 00 00 00 00032: 00 00 00 3A 30 9B 69 60040: A8 32 73 B2 22 1F AA 65048: 6C 09 F8 01 0A 3A 0D 30056: 92 CD 77 AB 42 B9 BC 64064: 9F 17 57 D4 C3000 - 015: 用户QQ密码的MD5 的MD5 作为密钥，对空字串进行加密的结果。

0A 1D版的TEA算法采取了随机PADDING的方式，所以这个数字每次看起来都不同。

但是解密以后总是空字符串。

016 - 016: 总是0x00。

017 - 020: 以前为IP地址，现在为全零。

不知道具有互联网IP的机器是否有真正的地址。

021 - 022: 以前为端口号，现在为全零。

023 - 051: 不明含义，总是相同。

052 - 052: 登录模式。

0A为正常方式，28为隐身。

053 - 068: 应该是和机器相关的识别号，在相同的机器上总是相同。

响应方：服务器成功登录的样本：000: 00 61 42 58 45 55 6B 58008: 7A 42 57 36 78 6E 49 41016: 59 01 82 5D 90 40 E7 A7024: E3 0F A0 7F 00 00 01 1F032: 40 3F 51 22 DA 03 0A 5B040: 83 50 D2 91 55 AE FC 3A048: 5B D4 E9 31 97 C5 85 13056: 64 6B 30 0A CE F1 33 3D064: 8D C2 CF 1F 40 3D AC F9072: 8E 1F 40 00 00 1C BB 67080: 00 CB 49 E6 FF B6 FB 01088: 97 41 6E 96 30 48 76 48096: EF B8 1D 1E 5A EA EB E9104: AB 00 4A 23 D2 00 00 00112: 00 00 00 00 00 00 00 00120: 00 40 E7 A7 E3 3F 51 22128: 91 00 00 00 00 00 00 00136: 00000 - 000: 成功登录应该为0。

001 - 016: 以后通信的密钥。

017 - 020: 登录的QQ号码。

021 - 026: 服务器检测到的客户端的IP地址和端口号。

027 - 032: 127.0.0.1:8000，应该是服务器检测到自己的IP和端口号？作用不明。

033 - 036: 本次登录时间？......063 - 068: 一个端口为8000的IP地址，作用不明。

069 - 074: 一个端口为8000的IP地址，这个地址就是DTPF协议组通讯的服务器。

075 - 076: 总是０，应该为分隔。

......109 - 120: 总是０。

121 - 124: 客户端的IP。

（上次登录的IP？）125 - 128: 上次登录退出时间？...129 - 136: 总是0。

其它：未知。

密码错误的样本（用Random Key解密）：000: 02 C3 DC C2 EB B4 ED CE008: F3 A3 A1000 - 000: 密码错误: 02。

001 - 010: 字符串“密码错误！”，GB18030 编码要求转到其它服务器登录（未观察到，根据perl-OICQ的资料）：000 - 000: 转到新服务器：01。

001 - 004: 请求的QQ号。

005 - 008: 新的服务器IP。

009 - 010: 新的服务器端口号。

0x0001，注销命令：发送方：客户端（连续发送4次）样本：000: 42 80 D8 9A 5A 03 F8 12008: 75 1F 50 4C C1 0E E8 A5000 - 015: QQ密码的MD5 的MD5。

0x001D，未知命令：发送方：客户端，在登录成功后发送。

而且总是连发两个。

第一个样本：000: 03000 - 000 ：总是03，应该是子命令。

第二个样本：000: 04000 - 000 ：总是04，应该是子命令。

响应方：服务器（定长的响应）第一个响应样本：000: 03 00 52 65 76 65 6D 6D008: 41 35 65 52 54 64 4E 36016: 64 4B 00 00 00 00 00 00024: 00 00 00 00 00 00 38 3D032: 1E 4A 4E 36 53 87 8E B5040: E0 24 5C 97 80 8C 64 23048: F4 FF BC 42 69 72 39 1D056: F6 31 22 65 37 BE 00 D1064: 8E A6 F8 4C 75 82 F7 B4072: 49 1F FF 72 3E 26 01 13080: 1B 18 F6 5A BD 8E 58 00088: 01 00 00000 - 000: 03，应该表明是对03号子命令的响应。

001 - 001: 00，应该是分隔。

002 - 017: 16个字符，全由字母和数字组成。

018 - 029: 全0。

030 - 030: 总是38，应该是后面数据的长度。

...087 - 090: 总是00 01 00 00。

第二个响应样本：000: 04 00 43 44 7A 7A 38 63008: 74 6A 52 55 4B 55 35 43016: 52 6B 00 00 00 00 00 00024: 00 00 00 00 00 00 38 A2032: 5B B9 D3 0E 67 E8 93 BD040: 0E B4 F6 AE BF 54 47 D7048: 0F 69 84 5D F2 81 5D D8056: 12 BF EC 1E 1A 83 D2 58064: 1D 94 D4 03 EB 91 3B 13072: A6 B4 66 37 5C A1 96 48080: 15 8F BD E0 A8 6C 5F 00088: 01 00 00000 - 000: 04，应该表明是对04号子命令的响应。

0x0006，获取用户信息：发送方：客户端样本：000: 32 35 33 32 30 38 34 38需要获取信息的用户QQ号码。

ascii字符串形式。

应答方：服务器样本：000: 32 35 33 32 30 38 34 38008: 1E6A 65 66 66 5F 79 65016: 63 6E 1E D6 D0 BB AA C8024: CB C3 F1 B9 B2 BA CD B9032: FA 1E B9 E3 B6 AB CA A1040: 1E 35 31 30 30 30 30 1E048: 64 6F 6E 67 20 66 65 6E056: 67 20 72 64 2E 20 31 34064: 35 1E2D 1E 33 31 1E C4072: D0 1E2D 1E6A 65 66 66080: 5F 79 65 63 6E 40 73 69088: 6E 6F 6D 61 63 2E 63 6F096: 6D 1E 1E 1E1E30 1E 1E104: CD A8 D0 C5 1E2D 1E30112: 1E 1E 1E32 30 34 1E31120: 33 30 30 35 31 36 31 32128: 34 34 1E 30 1E CF B2 BB136: B6 BA CD C8 CE BA CE C8144: CB C1 C4 CC EC A1 A3 1E152: B9 E3 D6 DD 1E2D 1E 2D160: 1E 30 1E32 1E30 1E 55168: 53 54 43 1E 31 32 1E31176: 32 1E32 1E 30 1E 2D返回的数值由一个个字段组成，数字也是以字符串表示，没有填写的很多为-。

每个字段用1E分隔。

分别的含义为：QQ号码，昵称，国家，省，邮政编码，街道地址，电话，年纪，性别：男女的GB编码。

真实姓名，电子邮件，寻呼编号，寻呼号，寻呼机供应商，寻呼台号，寻呼机类型，职业，主页，添加好友认证方式：'0' 不认证，'1' 需认证，'2' 不许添加未知20，未知21，头像：0-255的字符串表示，每三个代表一组正常，离开，忙的头像手机号码，手机类型：'0' 为无移动QQ，'1'为开通移动QQ。

自我描述：城市,未知27，未知28，未知29，是否公开手机：'0' 公开'1' 好友'2' 不公开是否公开联系方式：'0' 公开'1' 好友'2' 不公开学校，星座：以下的对应关系，见pagers.plist生肖，血型，QQShow，未知37。

0x000D，设置状态：发送者：客户端样本：000: 0A 00 00 00 00000 - 000: 状态：0A 正常，1E 离开，40 隐身001 - 004: 总是0。

应答者：服务器样本：000: 30成功返回30 ('0')。

0x0026，获取好友列表：发送者：客户端样本：000: 00 00 00000 - 001:获取的好友列表的位置标志（第一个从00 00 开始，以后的根据上一次响应包的标志值）。

002 - 002: 总是0。

（QQ 2000 无此数据）应答者：服务器样本：000: 00 32 01 72 D1 90 00 ED008: 11 00 04 B0 A2 BB A2 00016: 0001 74 55 CD 00 D8 15024: 01 06 BB A8 D4 F3 C0 E0032: 02 4001 7C 13 30 00 DE040: 18 01 08 CF EB B7 C9 B5048: C4 D0 C4 00 0001 7C 50056: 8A 00 99 1D 00 03 47 59064: 48 00 0201 7D 1A 2A 00072: B7 00 01 04 D4 B6 BA BD080: 00 0001 7E 79 A5 00 A2088: 13 01 04 D1 A9 C2 D8 00096: 0001 81 E1 25 00 21 17104: 01 07 B2 BB D2 AA BF DE112: 20 00 0000 01 82 90 00120: 60 1F 00 04 6A 65 66 66128: 00 0000 13 3E DF 00 60136: 17 01 09 20 20 73 61 62144: 72 69 6E 61 00 4000 32152: F5 5E 00 39 19 01 06 79160: 76 6F 6E 6E 65 00 0000168: 38 F3 B9 00 C3 00 00 08176: CA B1 B4 FA C0 CF C8 CB184: 00 0000 41 98 95 00 90192: 15 01 04 44 65 65 72 00208: 01 08 D4 C2 B9 E2 C5 AE 216: BA A2 02 0000 55 04 61 224: 00 90 11 01 08 C6 AF C1 232: C1 B1 A6 B1 B4 02 0000 240: 59 AF 21 00 60 1A 01 07 248: CF B8 CE C3 D7 D0 7E 02 256: 6600 5A 86 9B 00 21 00 264: 01 04 C0 B6 D6 BD 00 00 272: 00 5C 03 6E 00 A5 20 00 280: 06 B3 CC BA A3 C2 D7 00 288: 0000 67 7C EC 00 72 1C 296: 00 06 6A 61 63 33 33 33 304: 00 0000 70 7F C8 00 78 312: 00 01 04 C3 A8 C1 E1 00 320: 0000 82 00 BF 00 51 00 328: 00 09 20 20 20 B7 BD BE 336: F5 CF FE 00 0000 A0 C0 344: 6A 00 63 12 01 04 C3 CE 352: BE B2 00 0000 D1 06 59 360: 00 60 00 00 08 D2 BB BD 368: A3 C6 AE CF E3 00 4000 376: F0 BA 07 00 8A 00 01 04 384: C7 E0 C7 E0 00 0000 F2 392: 69 9F 00 AB 16 01 0A 5E 400: 5F 5E C7 EF C7 EF 5E 5F 408: 5E 00 0001 03 1B 44 00 416: D5 13 00 08 B0 AE C4 E3 424: B5 C4 C8 CB 00 0001 0F 432: A2 D5 00 78 02 01 05 57 440: F2 AB C4 DE 02 4001 17 448: 48 76 00 51 00 00 06 BA 456: DC B0 B2 C8 AB 00 0001 464: 3B AD D7 00 F0 18 01 0A 472: B9 C6 BB F3 A1 CA CC EC 480: CA B9 00 0001 44 AE 12 488: 00 87 20 00 0A 20 20 20 496: 20 51 51 D6 AE B8 B8 00 504: 0001 B3 8C 71 00 99 1A 512: 00 08 C3 E6 B4 F8 CE A2 520: D0 A6 00 0001 C0 29 68 528: 00 F9 12 01 06 D0 A1 C0 536: B1 BD B7 00 0001 CA 96 544: 03 00 F9 00 01 04 D0 A1 552: BB A2 02 4001 CB 81 C2 560: 00 90 12 01 0B 4C A1 EE 568: 76 65 CF E3 C4 CE B6 F9 576: 00 0001 E9 1B 7F 00 0C 584: 18 00 08 B6 FE C2 BF B1 592: E4 C1 CB 00 0002 20 F1 600: D4 00 A8 13 01 04 CE A8 608: D2 BB 00 0002 36 B5 07 616: 00 A8 1A 01 04 BF C9 DD 624: E6 02 0002 4C 03 88 00640: A7 F1 A7 D1 C6 A1 C0 E6648: 02 0002 4D 98 8B 00 B4656: 16 00 06 BB B5 C6 A2 C6664: F8 00 0002 65 0A 51 00672: A8 00 01 04 C7 A7 CA BD680: 00 0002 7A DB D0 00 90688: 00 01 02 58 32 00 0002696: 7C 37 4E 00 7B 15 01 04704: 63 6F 63 6F 00 0002 88712: D5 EA 00 42 00 00 04 D1720: C5 B7 E7 00 0002 93 67728: 5A 00 90 12 01 0C C4 C7736: C3 B4 B0 AE CB FB CE AA744: CA B2 00 00000 - 001: 下一次发送0x0026命令的数据起始位置。

合集下载

TCP读取报文不完整的问题分析

TCP读取报文不完整的问题分析

TCP读取报文不完整的问题分析2009-10-22from /blog/archives/430.html首先解释一下这个题目, "报文"指的是业务层自定义的报文, TCP是流式协议, 不像UDP那样是报文协议.某两个系统间进行网络交互, 请求报文的格式为:<json串>&sig=xxx请求方用PHP的stream_socket_sendto()进行发送. 服务器端使用Python的twisted框架. 上线后, 出现问题, 服务器端接收到的报文不完整. 例如, json串只读了一半, 或者缺少"&sig=xxx", 缺少的数据是随机的, 但只缺少尾部, 已经接收到数据没有差错.发送方代码:$str = sprintf('json=%s&sig=%s', $json, $sig);stream_socket_sendto($fp, $str);接收方代码:class XServer(Protocol):def dataReceived(self, data):#处理一个报文factory = Factory()factory.protocol = XServerreactor.listenTCP(19009, factory)reactor.run()我们通过PHP和Python的API文档, 以及我们对网络协议和套接口的理解来分析.问题1: 发送缓冲太小了吗?(发送方分包了吗?)我们首先想到的原因会不会是, 发送方的发送缓冲比一个报文小,所以"分包"了? 不过仔细一想, 这个问题出发点本身就是错误的. 因为TCP协议是流式协议, 不存在"分包"的问题, 因为TCP的用户接口只能看到字节流, 不认识报文(包). 所以, 发送方的发送缓冲大小不影响接收. 问题2: 接收缓冲太小了吗?怀疑完发送缓冲, 现在来怀疑一下接收缓冲. 因为使用的是TCP协议, 所以, 就算是只读到一个字节的数据, dataReceived()也可能被调用一次, 所以, 在dataReceived()中把接收到的数据当作一个报文, 就犯了逻辑错误, 与接收缓冲的大小无关. 而且, dataReceived()的API文档提到: Please keep in mind that you will probably need to buffer some data.问题1和问题2都有相同的错误, 那就是错误地把TCP当作是基于报文的协议. 使用TCP, 如果应用层协议不是基于报文的, 你可以在每一次读数据之后对数据进行处理, 比如, echo程序. 如果应用层协议是基于报文的, 那么, 你必须自己组装报文; 或者, 一次TCP会话只发送一个报文, 通过连接关闭来显式地声明报文发送完毕. 而一个报文可能需要多次读操作才能组装完毕, 也可能一次读包含了多于一个报文(如果不是停止等待应答的话).结论:1. 重新定义报文格式, 基于行的协议基于TCP socket的程序, 有几种方式可用来实现报文协议:1. 报文中声明报文数据的长度.2. 使用分隔符.3. 发送方发送完一个报文后关闭连接.业务层本意上是想使用一种基于报文的协议, 但所定义的报文格式并没有提供报文分隔符或者长度字段, 这就要求程序进行语义分析, 增加了实现难度. 现在改成使用换行符作为分隔符.2. 改写接收端代码, 使用基于行的接口class XServer(LineServer):def lineReceived(self, data):#处理一个报文前面提到, 我们必须自己组装报文, 但这不代表我们要自己写组装代码, 行IO库可以替我们做这项工作. LineServer实现了基于行的协议, 只有读到完整的一行, lineReceived()才会调用.。

TCP连接过程及报文解析

TCP连接过程及报文解析

TCP连接过程及报⽂解析可能⼤家都听过TCP建⽴连接时需要经历三次握⼿和四次挥⼿的。

那么具体的握⼿挥⼿的过程是怎么样的呢？这篇⽂章就通过WireShark抓包来了解TCP连接建⽴和断开的过程。

实验⽅法：写⼀段简单的代码代码客户端和服务端，分别部署，让客户端主动像服务器发起连接，随后断开。

让WireShark抓股这个过程中产⽣了哪些包，并对其分析。

（注：WireShark默认不⽀持LoopBack，需要将客户端和服务端分开部署，或是配置WireShark）。

⾸先，我们先来看⼀下连接建⽴和断开的过程中，产⽣了哪⼏个包。

从上图我们可以看到，正好是七个包，符合我们三次握⼿四次挥⼿的过程。

分析其过程，WireShark已经为我们解析了每个TCP包的标志位（之后会详细解释，主要⽤来区分每个包的⽤途）。

TCP建⽴连接：1）.客户端向服务器发起建⽴连接请求（SYN）2）.服务端收到后，像客户端回复⼀个建⽴连接请求的响应（SYN，ACK）3）.客户端收到后，继续向服务端发送⼀个响应（ACK）三次握⼿完成，正式建⽴连接。

TCP断开连接1）.断开发起⽅向另⼀⽅发送断开连接请求（FIN，ACK）2）.另⼀⽅收到后，回复⼀个响应（ACK）3）.再由另⼀⽅主动发送⼀个断开连接请求（FIN，ACK）4）.断开发起⽅收到后，回复⼀个响应（ACK）四次挥⼿完成，断开SOCKET连接。

我们通过图⽚来加深⼀下印象：了解完过程，再让我们通过分析第⼀个包的内容，初步了解下TCP报⽂结构：我们可以看到整个消息帧是66个字节：1）.该帧是⼀个以太⽹消息帧：分为⾸部和数据两个部分。

⾸部前六个字节（30 9c 23 bc 9d 80）表⽰⽬的地MAC地址后六个字节（30 9c 23 1c 0f 74）表⽰源MAC地址我们可以看到当数据在链路层中传输的时候，是由MAC地址标识定位的。

之后两个字节（08 00）表⽰上层协议类型（这⾥的0x 08 00表⽰的就是IP协议）剩余的52（66 - 6 - 6 - 2）个字节为数据部分，来承载上层协议（本例中为IP协议）的消息。

TCP标志位详解及tcp拦截配置

TCP标志位详解及tcp拦截配置

TCP标志位详解及tcp拦截配置TCP标志位URG：此标志表示TCP包的紧急指针域（后面马上就要说到）有效，用来保证TCP 连接不被中断，并且督促中间层设备要尽快处理这些数据；ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中；有两个取值：0和1，为1的时候表示应答域有效，反之为0；PSH：这个标志位表示Push操作。

所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序，而不是在缓冲区中排队；RST：这个标志表示连接复位请求。

用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包；SYN：表示同步序号，用来建立连接。

SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1，ACK=0；连接被相应的时候，SYN=1，ACK= 1；这个标志的数据包经常被用来进行端口扫描。

扫描者发送一个只有SYN的数据包，如果对方主机响应了一个数据包回来，就表明这台主机存在这个端口；但是由于这种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全的主机将会强制要求一个连接严格的进行TCP的三次握手；FIN：表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志位的TCP数据包后，连接将被断开。

这个标志的数据包也经常被用于进行端口扫描。

当一个FIN标志的TCP数据包发送到一台计算机的特定端口，如果这台计算机响应了这个数据，并且反馈回来一个RST标志的TCP包，就表明这台计算机上没有打开这个端口，但是这台计算机是存在的；如果这台计算机没有反馈回来任何数据包，这就表明，这台被扫描的计算机存在这个端口。

*SYN：同步标志同步序列编号(Synchronize Sequence Numbers)栏有效。

该标志仅在三次握手建立TCP连接时有效。

它提示TCP连接的服务端检查序列编号，该序列编号为TCP 连接初始端(一般是客户端)的初始序列编号。

qq通信协议

qq通信协议

竭诚为您提供优质文档/双击可除qq通信协议篇一：qq协议简单分析qq协议简单分析qq的版本：qq的版本升级比较频繁，而且与多数的软件不同的是，它客户端的升级往往伴随着协议相应的改变。

目前，对研究qq协议版本比较重要的是：qq2000c。

它对应的客户端协议版本是08xx，目前对这个版本的研究比较多。

qq20xx(0808)这是腾讯最新公布的qq版本，目前发现它对应的客户端协议版本是0a1d。

目前对这个版本的研究才刚刚开始，此版本对协议做了比较大的改动。

协议类型：我们尝试把qq的协议进行分类：文字聊天协议族（tcpF,textchattingprotocolFamily)：它主要支持与其它qq客户端进行文字聊天。

tcpF是建立在udp协议之上。

udp数据包中的第一个字符02为这个协议族的标识。

tcpF的服务器使用8000号端口，腾讯的qq客户端软件一般从4000号端口开始尝试使用，但实际上，对客户端使用的端口号并没有限制。

目前的研究集中在tcpF上。

其它未知可能存在的协议族：我们观察到qq除了与tcpF服务器通信以外，还有与其它的服务器使用udp进行通信。

目前我们观察到的服务器为218.17.217.111:8000。

客户端使用与tcpF不同的端口。

目前观察到的从客户端发出的包以06开头，而服务器返回的包则以01开头。

目前其具体作用未知。

我们注意到一个有趣的现象是，如果选择离线后重新上线，那么在发出登录包之前，这个通讯已经开始。

我们暂时把它命名为数据传输协议族（dtpF，datatransferprotocolFamily）。

最新的研究发现，它传递的是qqshow的图片数据。

语音、视频聊天：目前还没有开始分析，尚未知道是使用udp还是tcp协议。

聊天室：没有分析，应该是tcp协议。

随着对这些协议分析的开始，我们会给它们更精细的划分和恰当的命名。

tcpF:tcpF是建立在udp协议上的协议族，主要支持文字聊天功能。