Botnets surrounding us: performing requests, sending out KADEMLIA2_REQ and asking “contact, where art thou?”

“Are we there yet?” Nope, I’d say no. The journey to have a basic botnet running is still pretty long, but the enthusiasm is big enough to cover it all.

So, here we are. The next major step is to understand how the lookup process works (pretty important one): the concept behind this process is that, even if a client doesn’t know all the other peers in the Kad network, it will still be able to find any other Kad client.

Let’s start with the definition of the KADEMLIA2_REQ/S messages:

KADEMLIA2_REQ (opcode 0x21)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA2_REQ opcode
  • unsigned int 8-bit: contacts count
  • unsigned int 128-bit: target ID
  • unsigned int 128-bit: local contact ID

33 bytes long, this message is sent to know information about the target ID specified in the message: the maximum results that must be returned is specified in the message itself. The target ID can be the client ID of a peer or the hash value of sources, keywords and notes. Looking for a source would mean looking for the MD4 hash of a file. Looking for keywords is what is made by humans, as every file published in the Kad network is identified by a filename: each filename is split into several keywords and published into the Kad network. The search is then performed on the MD4 of the keyword. A note is a comment in the file, so it will be also identified with the source ID.

The different targets are the following, each one associated to a different number of desired contacts in the reply:

  • FIND_NODE (11 contacts requested): NODE, NODECOMPLETE, NODESPECIAL, NODEFWCHECKUDP
  • FIND_VALUE (2 contacts requested): FILE, KEYWORD, FINDSOURCE, NOTES
  • STORE (4 contacts required): FINDBUDDY, STOREFILE, STOREKEYWORD, STORENOTES

In short, if a contact wants to be closer to a target, it selects the 50 different closest-to-the-target contacts in its routing table and sends a request to the three closest ones and with a contact type lower than 4. When one of these contacts receives the requests, a search in the routing table is performed in order to find the closest-to-the-target contacts stored with contact type lower than 3 (the quantity is the one specified in the message).

KADEMLIA2_RES (opcode 0x29)

  • unsigned int 8-bit: Kad packet identifier
  • unsigned int 8-bit: KADEMLIA2_RES opcode
  • unsigned int 128-bit: target ID
  • unsigned int 8-bit: contacts count
  • 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

When the message is received, all the previously-unknown contacts are added to the routing table. If a FIND_NODE search was performed, the search stops here, otherwise all the received contacts are added to the list of contactable ones and search goes on.

Actually, for botnet purposes, it’s not needed to go further with the search process, as only KADEMLIA2_REQ/S seem to be required for it. I’d say we can start the rock’n’roll (but I’ll do some code cleaning before).

Advertisements

One thought on “Botnets surrounding us: performing requests, sending out KADEMLIA2_REQ and asking “contact, where art thou?”

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