P2P协议分析end.docx
《P2P协议分析end.docx》由会员分享，可在线阅读，更多相关《P2P协议分析end.docx（68页珍藏版）》请在冰豆网上搜索。
P2P协议分析end
P2P协议分析
一、eDonkey/eMule协议1
二、Gnutella6
三、PPLive8
四、迅雷12
五、KuGoo18
六、QQlive20
七、Feidian网络电视22
八、PPStream25
九、CCIPTV28
十、DC++34
一、eDonkey/eMule协议
在eDonkey/eMule通信的TCP数据包中，格式如下：
✧数据流（除掉包头）中的第一个字节代表的是通信的协议簇代码（如0xE3为标准的edonkey协议，0xE4为kad协议，0xc5是eMule扩展协议）；
✧接下来的四个字节代表包长度，所有的包都用这种方式发送到TCP流中，就可以区分出来了；
✧另外每个包内容中的第一个字节为opcode，即在确定了某个具体协议后，这个opcode确定了这个包的具体含义；
在eMule通信的UDP数据包中，处理起来更加得简单，因为UDP本来就是以一个包一个包作为单位在网络上流传的，因此不需要在包的内容中再包含表示长度的字段。
每个UDP包的第一个字节是协议簇代码，其它内容就是包的内容。
说明：
有种特殊情况，遇见大量的数据传出（压缩数据），0xe3改为0xd4，oxe4改为0xe5。
1.1、TCP通信
eMule/eDonkey协议的TCP消息头格式：
列项名称
特征
长度（B）
protocol
0xe3：
eDonkey,0xe4:
Kad,0xc5:
eMule
1
length
信息包长度
4
type
信息类型
1
比如下面TCP数据包：
列项名称
特征
protocol
0e3
length
19280000
type
46
00000013c328dc00000b6ae3d33208004500...（....j..2..E.
00100334cca14000800692abc0a80412da02.4..@...........
0020f9b90cdf1236c55ab525a66749c35018.....6.Z.%.gI.P.
00304061c2c50000e31928000046f5469530@a......（..F.F.0
0040d06898749deae3ea289e3e9200b89719.h.t....（.>.....
．．． ．．．
（1）eDonkey协议的TCP消息类型：
Client——Server（协议标识0xe3）
信息类型
说明（协议标识0xe3）
0x01
HELLO
0x05
BAD_PROTO
0x14
GET_SERVER_LIST
0x15
OFFER_FILES
0x16
SEARCH_FILES
0x18
DISCONNECT
0x19
GET_SOURCES
0x1a
SEARCH_USER
0x1c
CLIENT_CB_REQ
0x21
MORE_RESULTS
0x32
SERVER_LIST
0x33
SEARCH_FILE_RESULTS
0x34
SERVER_STATUS
0x35
SERVER_CB_REQ
0x36
CALLBACK_FAIL
0x38
SERVER_MESSAGE
0x40
ID_CHANGE
0x41
SERVER_INFO_DATA
0x42
FOUND_SOURCES
0x43
SEARCH_USER_RESULTS
0x23
OP_GETSOURCES_OBFU
0x44
OP_FOUNDSOURCES_OBFU
Clinet——Client（协议标识0xe3）
信息类型
说明（协议标识0xe3）
0x01
HELLO_CLIENT
0x46
SENDING_PART
0x47
REQUEST_PARTS
0x48
NO_SUCH_FILE
0x49
END_OF_DOWNLOAD
0x4a
VIEW_FILES
0x4b
VIEW_FILES_ANSWER
0x4c
HELLO_ANSWER
0x4d
NEW_CLIENT_ID
0x4e
CLIENT_MESSAGE
0x4f
FILE_STATUS_REQUEST
0x50
FILE_STATUS
0x51
HASHSET_REQUEST
0x52
HASHSET_ANSWER
0x54
SLOT_REQUEST
0x55
SLOT_GIVEN
0x56
SLOT_RELEASE
0x57
SLOT_TAKEN
0x58
FILE_REQUEST
0x59
FILE_REQUEST_ANSWER
0x5d
GET_SHARED_DIRS
0x5e
GET_SHARED_FILES
0x5f
SHARED_DIRS
0x60
SHARED_FILES
0x61
SHARED_DENIED
eMule协议（协议标识0xc5）
信息类型
说明（协议标识0xc5）
0x01
HELLO
0x02
HELLO_ANSWER
0x40
DATA_COMPRESSED
0x60
QUEUE_RANKING
0x61
filedescription
0x81
SOURCES_REQUEST
0x82
SOURCES_ANSWER
0x87
SecureIdentification
0x85
Theclient’spublickey
0x86
Theclientsignsa4byteschallengeusingitspublickey.
0x90
Requestanimagepreviewforafile.
0x91
Animagepreviewanswermessage
0x92
MULTIPACKET
0x93
MULTIPACKET_ANSWER
0x9b
AICH_REQUEST
0x9c
AICH_ANSWER
0x9d
AICHFILEHASH_ANSWER
0x9e
AICHFILEHASH_REQUEST
0xa1
DATA_COMPRESSED_64
0xa2
SENDING_PART_64
0xa3
REQUEST_PARTS_64
0xa4
MULTIPACKET_EXT
1.2、UDP通信
eMule/eDonkey协议的UDP消息头格式：
列项名称
特征
长度（B）
protocol
0xe3：
eDonkey,0xe4:
Kad,0xc5:
eMule
1
type
信息类型
1
eDonkey协议的UDP信息类型（协议标识0xe3）：
信息类型
说明（协议标识0xe3）
0x96
SERVER_STATUS_REQUEST
0x97
SERVER_STATUS
0x98
SEARCH_FILE
0x99
SEARCH_FILE_RESULTS
0x9a
GET_SOURCES
0x9b
FOUND_SOURCES
0x9c
CALLBACK_REQUEST
0x9e
CALLBACK_FAIL
0xa1
SERVER_LIST
0xa2
GET_SERVER_INFO
0xa3
SERVER_INFO
0xa4
GET_SERVER_LIST
eMule协议的UDP信息类型（协议标识0xC5）：
信息类型
说明（协议标识0xc5）
0x90
REASKFILEPING
0x91
REASKACK
0x92
FILE_NOT_FOUND
0x93
QUEUE_FULL
Overnet的设计目的是取代eDonkey，许多eDonkey客户端程序同时使用Overnet，Overnet没有中心服务器，但其用户数量现在少于eDonke。
KadNetwork很类似Overnet，几乎只有eDonkey的用户你用它，但它的普及性也很低。
信息类型
说明overnet（协议标识0xe3）
0x0a
CONNECT
0x0b
CONNECT_REPLY
0x0c
PUBLICIZE
0x0d
PUBLICIZE_ACK
0x0e
SEARCH
0x0f
SEARCH_NEXT
0x10
SEARCH_INFO
0x11
SEARCH_RESULT
0x12
SEARCH_END
0x13
PUBLISH
0x14
PUBLISH_ACK
0x15
IDENTIFY_REPLY
0x16
IDENTIFY_ACK
0x18
FIREWALL_CONNECTION
0x19
FIREWALL_CONNECTION_ACK
0x1a
FIREWALL_CONNECTION_NACK
0x1b
IP_QUERY
0x1c
IP_QUERY_ANSWER
0x1d
IP_QUERY_END
0x1e
IDENTIFY
KAD网络的UDP信息类型（协议标识0xe4）有如下类型：
11，10，20，28，18，19，21，29，30，50，58。
信息类型
说明（0xe4Kad）
0x20
hello
0x28
helloanswer
0x10
0x11
0x21
0x30
0x50
0x52
0x28
0x19
0x18
0x58
消息代码
消息类型
说明（0xe4UDPKad）
0x10
KADEMLIA_HELLO_REQ
0x11
KADEMLIA2_HELLO_REQ
0x18
KADEMLIA_HELLO_RES
0x19
KADEMLIA2_HELLO_RES
0x20
KADEMLIA_REQ
0x21
KADEMLIA2_REQ
0x28
KADEMLIA_RES
*（CNT）
0x29
KADEMLIA2_RES
0x30
KADEMLIA_SEARCH_REQ
[ext]
0x32
KADEMLIA_SEARCH_NOTES_REQ
0x33
KADEMLIA2_SEARCH_KEY_REQ
0x34
KADEMLIA2_SEARCH_SOURCE_REQ
0x35
KADEMLIA2_SEARCH_NOTES_REQ
0x38
KADEMLIA_SEARCH_RES
（*（CNT2））*（CNT1）
0x3A
KADEMLIA_SEARCH_NOTES_RES
（*（CNT2））*（CNT1）
0x3B
KADEMLIA2_SEARCH_RES
0x40
KADEMLIA_PUBLISH_REQ
（*（CNT2））*（CNT1）
0x42
KADEMLIA_PUBLISH_NOTES_REQ
*（CNT2））*（CNT1）
0x43
KADEMLIA2_PUBLISH_KEY_REQ
0x44
KADEMLIA2_PUBLISH_SOURCE_REQ
0x45
KADEMLIA2_PUBLISH_NOTES_REQ
0x48
KADEMLIA_PUBLISH_RES
0x4A
KADEMLIA_PUBLISH_NOTES_RES
0x4B
KADEMLIA2_PUBLISH_RES
0x50
KADEMLIA_FIREWALLED_REQ
0x51
KADEMLIA_FINDBUDDY_REQ
0x52
KADEMLIA_CALLBACK_REQ
0x58
KADEMLIA_FIREWALLED_RES
0x59
KADEMLIA_FIREWALLED_ACK_RES
（null）
0x5A
KADEMLIA_FINDBUDDY_RES
二、Gnutella
Gnutella的p2p网络主要是负责资源的搜索和连接的建立，真正的数据传输不在Gnutella网络中进行。
当一个客户端找到相应的资源客户端并获取该资源客户端的连接信息后，即一个客户机收到一个QueryHit描述符，它将初始化直接下载描述符的结果集其中的一个文件。
文件将不通过Gnutella的网络进行下载，一个源客户机和目标客户机直接建立连接进行数据的传输。
文件数据从来不会通过Gnutella网络进行传送。
文件下载协议是HTTP协议。
初始化下载的客户机发送一个请求字符串到目标客户机，格式如下：
GET/get///HTTP/1.0\r\n
Connection:
Keep-Alive\r\n
Range:
bytes=0-\r\n
User-Agent:
Gnutella\r\n3\r\n
这里的和是一个QueryHit描述符结果集中的FileIndex/FileName对中的其中之一。
当服务器收到下载请求，将回应于HTTP1.0兼容的头，例如：
HTTP200OK\r\n
Server:
Gnutella\r\n
Content-type:
application/binary\r\n
Content-length:
4356789\r\n
\r\n
并非总是在初始化一个文件下载后都可以与Gnutella客户机建立直接连接。
客户机可能在防火墙后并不允许通过它的Gnutella端口进入的连接。
如果一个直接连接不能建立，客户机若想下载文件可能会请求共享文件的客户机采用“推送”方式来代替。
一个客户机可以通过发送一个Push文件推送请求到发送QueryHit请求的客户机处来实现。
作为Push请求目标的客户机（在客户机标志区标示一个Push的描述符）应该接收Push描述符，尝试建立一个新的TCP/IP连接到请求客户机（在Push描述符中标示有IP地址和端口）。
如果直接连接不能建立，那么可能发起Push请求的客户机自己也在防火墙后。
这种情况，文件传输将不能进行。
如果一个直接连接可以从防火墙后的客户机建立到发起Push请求的客户机，防火墙后的客户机应该立刻发送以下的：
GIV:
/\n\n
这里的:
和是Push请求头中的的文件索引和客户机标示，是本地文件表中文件索引为的文件。
客户机收到GIV请求头（Push请求者）应该从头中取出和并构造一个如下的HTTPGET请求：
GET/get///HTTP/1.0\r\n
Connection:
Keep-Alive\r\n
Range:
bytes=0-\r\n
User-Agent:
Gnutella\r\n3
\r\n
余下的下载过程和上面所述的“文件下载”内容一致。
可允许的用户－代理字符串由HTTP标准定义。
客户机开发者不能对这里使用的值做自己的假定。
其中的值“Gnutella”只是用来演示举例而已。
首先来说明一下Gnutella的协议格式，如下表所示：
Gnutella头部结构
项目
长度（B）
说明
标识ID
16
唯一的网络描述字符
负载标识
2
Ping=0x00,Pong=0x01,Query=0x80,QueryHit=0x81,Push=0x40
TTL
1
生存期
Hops
1
TTL（0）=TTL（i）+Hops（i）
负载长度
4
不同的负载有不同的结构和长度
数据流
n
承载的数据区内容
不同的负载描述结构说明：
（1）Ping
没有负载体；
（2）Pong
（3）Query
其中，Mininumspeed最小响应速度，响应的客户机的速度必须在此速度之上（以K/秒为单位）。
Searchcriteria：
查询关键字，一个零结尾的字符串。
这个字符串的最大长度由描述头的PayloadLength负载长度规定。
（4）QueryHit
其中，NumofHits指查询的符合的个数，speed指文件的传输速率，单位为KB/s，ResultSet描述的是查询结果集，集合的元素结构为：
（5）Push
三、PPLive
（1）启动初始化，获取播放列表信息（TCP）
PPlive是p2p视频流方面的应用，启动PPlive客户端之后，该客户端会通过DNS解析出PPlive服务器（）的ip地址，然后建立TCP连接。
正常的http协议在建立TCP连接之后，主机会向PPlive服务器发送GET请求，获取相关的信息：
下面是抓取的数据包格式：
GET/zh-cn/mini/index.htmlHTTP/1.1\r\n
RequestMethod:
GET
RequestURI:
/zh-cn/mini/index.html
RequestVersion:
HTTP/1.1
Accept:
*/*\r\n
Accept-Language:
zh-cn\r\n
UA-CPU:
x86\r\n
Accept-Encoding:
gzip,deflate\r\n
If-Modified-Since:
Tue,23Jan200704:
13:
36GMT;length=11054\r\n
User-Agent:
Mozilla/4.0（compatible;MSIE6.0;WindowsNT5.2;SV1;.NETCLR1.1.4322）\r\n
Host:
\r\n
Connection:
Keep-Alive\r\n
Cookie:
flux_stat_user=0.313428001169524028636494169;cck_lasttime=1169524045312;cck_count=0;rcc74340947=2101604757%7C15%7C2%7C1%7C%7C%2Ff%3Fkz%3D66648944\r\n
\r\n
GET/zh-cn/mini/index.htmlHTTP/1.1\r\n
RequestMethod:
GET
RequestURI:
/zh-cn/mini/index.html
RequestVersion:
HTTP/1.1
Accept:
*/*\r\n
Accept-Language:
zh-cn\r\n
UA-CPU:
x86\r\n
Accept-Encoding:
gzip,deflate\r\n
If-Modified-Since:
Fri,09Feb200708:
15:
02GMT;length=10871\r\n
User-Agent:
Mozilla/4.0（compatible;MSIE6.0;WindowsNT5.2;SV1;.NETCLR1.1.4322）\r\n
Host:
\r\n
Connection:
Keep-Alive\r\n
Cookie:
flux_stat_user=0.622608001171008597457657584;__utma=140991987.415022390.1170821161.1171008599.1171008993.4;__utmb=140991987;__utmz=140991987.1170821161.1.1.utmccn=（direct）|utmcsr=（direct）|utmcmd=（none）;rcc74340947=2101604757%7
\r\n
因此，可以从一系列的GET请求中的特征标识Host和Cookie内容，可以初步分析出pplive客户端的启动。
（2）PPlive客户加入网络，获取节点信息（UDP）
获得了频道信息后PPlive应用程序通过UDP协议与域名为的目的主机通信（其中x可以为0~8,s,h），由于其采用域名方式访问，可以假定为固定的服务器提供P2P网络中的资源信息，即“片源服务器”。
说明：
其中红色字体的标识固定不变（e903,0198ab0102）,
蓝色字体是变化的，但是都是很小，为01，02，03，
绿色字体的是个连续的序号。
客户端——片源服务器
客户端会向片源服务器发送UDP数据包，报告自己加入PPlive网络，再者客户端发出的数据大小为57B，片源服务器返回的数据大小不定
升级会员 