Protocols > BitTorrent P2P

In the past I was looking into this and found that certain BitTorrent clients were able to use UDP to further their networks and get around filtering of the TCP connections for tracker communication.  The BitTorrent client BitComet is able to do so, as well as Azureus, uTorrent, and some others.  So I will include the information on classifying these packets as well, still under this same signature.  First of all, there are a couple simple ways to identify packets of the BitTorrent protocol.  The first is the connections that a BitTorrent client makes to an HTTP tracker.  The client will do an HTTP request for a file that is named announced with a first option of info_hash=.  So an HTTP request for the information below would identify an HTTP tracker connection.

/announce?info_hash=

You could probably go without classifying these outside of HTTP if you wanted to, because the major easily identifiable characteristic within the BitTorrent protocol (and don't laugh when you see it) is the string:

BitTorrent protocol

Now, classifying sessions that have that in the first couples packets will successfully classify the basic TCP BitTorrent clients out there.  However, as I specified above, other clients are capable of some UDP stuff, which is also pretty readily identifiable.  There are also encrypted clients out there now for the TCP portions of the protocol for file transfer, and I haven't spent much time identifying these packets yet.  The UDP sessions within BitComet and other clients will always start with a packet which starts with the bytes below at the first bytes of the UDP data section (UDP byte 8):

64 31 3a 61 64 32 3a 69 64 32 30 3a (Ascii: "d1:ad2:id20:")

These packets are always responded to by packets beginning with a very similar string listed below:

64 31 3a 72 64 32 3a 69 64 32 30 3a (Ascii: "d1:rd2:id20:")