Botnets surrounding us: sending KADEMLIA2_BOOTSTRAP_REQ, KADEMLIA2_HELLO_REQ and their strict cousins

In the previous post the routing table has been analyzed; in this one the first type of messages exchanged to get into the Kad network will be discussed.  I found out that there are some PDFs here and there describing the old Kad flow, so I will discuss here just the new one. I already said that, a contact in the normal nodes.dat, is automatically included into the routing table, but what if there is just a bootstrap nodes.dat available? That’s what the KADEMLIA2_BOOTSTRAP_REQ message does: it’s sent to one of these contacts to retrieve a list of contacts to be added in the routing table.

KADEMLIA2_BOOTSTRAP_REQ (opcode 0x01)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA2_BOOTSTRAP_REQ opcode

Pretty straightforward packet, huh? This packet is sent (in obfuscated form or not, as usual) to one of the contacts of the bootstrap list and, when is received, the remote contact retrieves all the contacts in the routing table tree that are stored in K-buckets not deepest than the 5th level. Then first 20 (or less, if not available) contacts in the list are taken and stored in the response message, as follows.


KADEMLIA2_BOOTSTRAP_RES (opcode 0x09)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA2_BOOTSTRAP_RES opcode
  • unsigned int 128-bit: local contact ID
  • unsigned int 16-bit: local TCP port
  • unsigned int 8-bit: Kad version used
  • unsigned int 16-bit: number of contacts included
  • unsigned int 128-bit: contact’s contact ID
  • unsigned int 32-bit: contact’s IP address
  • unsigned int 16-bit: contact’s UDP port
  • unsigned int 16-bit: contact’s TCP port
  • unsigned int 8-bit: contact’s version

Of course the last 6 points are repeated for the number of contacts included. Once this packet is received, if our bootstrap list is empty, the sender is added in the routing table as a verified contact, thanks to the details included in the first part of the message. Then all the other contacts are added directly to the routing table (in order to speed up the connection process, if the routing table is totally empty, all these new contacts will be considered as verified).

At the end of the process, the routing table will finally have some contacts inside and a KADEMLIA2_HELLO_REQ can be sent to them.


KADEMLIA2_HELLO_REQ (opcode 0x11)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA2_HELLO_REQ opcode
  • unsigned int 128-bit: local contact ID
  • unsigned int 16-bit: local TCP port
  • unsigned int 8-bit: Kad version used
  • unsigned int 8-bit: number of tags used

Apart from the usual information here included, here we meet a new element in the Kad network: tags. What is a tag? Actually is a piece of information identified by a name and features its own length and type. When a tag is dumped over a buffer, it has the following structure:

  • unsigned int 8-bit: tag type
  • unsigned int 16-bit: tag name length
  • string of variable length: the tag name (its length is specified in the previous field)
  • unsigned char []: buffer of data (can be integers, strings, blobs, etc).

For some of them the parsing of the data is simple: for example for integers we need to just cast the buffer and we’ll directly get the value. For others things get a little bit difficult: for strings, for example, the first two bytes of the buffer indicate the length of the string that follows immediately. I have not examined the blob encoding yet, but I can easily guess it’s gonna be a total mess (maybe I could be wrong).

Only two tags can be included in this message: the Kad internal UDP port and some connection options.

  • If we don’t know yet the external UDP port (the one seen on the other side of the potential NAT between my PC and the Internet), then the internal UDP port must be included in this message as a 16-bit integer (tag name TAG_SOURCEUPORT).
  • If the remote Kad version is at least 8 AND we are in some way still firewalled (TCP or UDP port not forwarded on the NAT, there’s a particular mechanism to discover this that will be soon analyzed), then the information about local the firewall situation must be included in this message as an 8-bit integer (tag name TAG_KADMISCOPTIONS): the 0-bit says if we are UDP firewalled, the 1-bit says if we are TCP firewalled and the 2-bit will be analyzed later (not used in the KADEMLIA2_HELLO_REQ).

When this packet is received, the information is added or updated in the routing table (if and only if the contact is not UDP firewalled or the filtered by some IP filter).

At the end of the processing, a KADEMLIA2_HELLO_RES packet is sent, containing the same information of this message, but, if the contact has been added AND it didn’t already sent a valid receiver key (or maybe it changed), the 3-bit is going to be set to 1 in the TAG_KADMISCOPTIONS: an additional ACK message is requested to complete a three-way-handshake and verify the remote IP. Unfortunately, this new message is not supported on client version 7 and another way to complete the handshake is taken by sending a KADEMLIA2_PING message.

The KADEMLIA2_PING is sent anyway in case we are still looking for the UDP external port and the remote contact version is at least 5.

In the end, if a firewall check is still needed, it is performed by sending a KADEMLIA_FIREWALLED2_REQ message (see over).


KADEMLIA2_HELLO_RES (opcode 0x18)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA2_HELLO_RES opcode
  • unsigned int 128-bit: local contact ID
  • unsigned int 16-bit: local TCP port
  • unsigned int 8-bit: Kad version used
  • unsigned int 8-bit: number of tags used

This message is indentical to KADEMLIA2_HELLO_REQ, as it carries the same information in the same layout. When this message is received, the contact is added (or updated) to the routing table with the same criteria seen for the twin message. If the client requested to send an ACK message to end the handshake, a KADEMLIA2_HELLO_RES_ACK is sent to that client.

Again, if the UDP external port is yet to be found and the remote contact is at least 5, a KADEMLIA2_PING message is sent. If the firewall check is still needed, the KADEMLIA_FIREWALLED2_REQ message is sent, as well.


KADEMLIA2_HELLO_RES_ACK (opcode 0x22)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA2_HELLO_RES_ACK opcode
  • unsigned int 128-bit: local contact ID
  • unsigned int 8-bit: number of tags used (set to 0)

This message is definitely a simple one. When received, the contact is set as verified in the routing table and the three-way-handshake is declared as over.


KADEMLIA2_PING (opcode 0x60)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA2_PING opcode

The only purpose of this message, for now, is to determine the own UDP external port. In fact, once received the KADEMLIA2_PONG received will contain only this information.


KADEMLIA2_PONG (opcode 0x61)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA2_PING opcode
  • unsigned int 16-bit: UDP port

After receiving this message, if we are still looking for the external UDP port, the potential UDP port is added to the UDP port candidates list. The port included in the message doesn’t necessarily coincide to the real external port because, if the internal port has been used recently in a communication with the client, some routers may remember this port and assign this as source.

The search for the external UDP port is stopped when the same port is received 2 out 3 tries.


KADEMLIA_FIREWALLED2_REQ (opcode 0x53)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA_FIREWALLED2_REQ opcode
  • unsigned int 16-bit: TCP port
  • unsigned int 128-bit: local contact ID
  • unsigned int 8-bit: connect options

This message requests the receiver to connect to the specified TCP port, on which a local TCP server is listening for connections. The details about how this connection works and what the connect options are will be probably discussed in the next post. Anyway a KADEMLIA_FIREWALLED_RES packet is sent back.


KADEMLIA_FIREWALLED_RES (opcode 0x58)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA_FIREWALLED2_REQ opcode
  • unsigned int 16-bit: receiver IP address

This message comes back from a firewall request and includes just our IP address. If this one is different from the one we already know, this one is updated. A counter is also increased: when it reaches 4, the firewall checks are not anymore needed. Anyway the counter is reset every hour.

So, these are the first messages sent in a Kad session. The TCP connection that verifies the contacts is a little bit tricky and requires a dedicated post.

I hope it’s clear until now, but anyway feel free to comment in order to enhance 🙂

Catch ya soon…

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s