Steam Friends is an instant messaging protocol that is built into Steam, a game

content delivery system developed by Valve. This page details the protocol

specification for Steam Friends as was ascertained though reverse-engineering.

Steam Friends uses UDP on port 27017. Connections have been made to at least

the following servers:

* 68.142.64.165

* 68.142.64.164 (resolves to valve-68-142-64-164.cust.phx3.llnw.net)

* 72.165.61.185

* 69.28.145.170

* 69.28.145.172

The client is using WSASendTo to send messages to friends

On top of UDP, another layer is implemented to keep track of sequencing and

splitting of packets. This layers prepends every packet with the following

36-byte structure:

<table>

<tr>

<th>offset</th>

<th>0x00</th>

<th>0x02</th>

<th>0x04</th>

<th>0x06</th>

<th>0x08</th>

<th>0x0A</th>

<th>0x0C</th>

<th>0x0E</th>

</tr>

<tr>

<th>0x00</th>

<td colspan="2">"VS01"</td>

<td>packet len</td>

<td>type & bits</td>

<td colspan="2">source</td>

<td colspan="2">destination</td>

</tr>

<tr>

<th>0x10</th>

<td colspan="2">sequence #</td>

<td colspan="2"> last rcv.#</td>

<td colspan="2">split count</td>

<td colspan="2">seq. # of 1st packet</td>

</tr>

<tr>

<th>0x20</th>

<td colspan="2">data length</td>

</tr>

</table>

**Note**: These values are little-endian, which is not network order.

Field | Type | Length (bytes) | Description

----- | ---- | -------------- | -----------

"VS01" | 4 chars | 4 | the 4 characters 'V', 'S', '0', '1' (0x56, 0x53, 0x30, 0x31)

packet len | integer | 2 | the length of the packet after this header

type & bits | byte & bit-field | 2 | the first byte is possibly some type identifier. It is always <8

destination | integer | 4 | the destination ID of the packet

source | integer | 4 | the source ID of the packet

sequence # | integer | 4 | the packet's sequence number. server and client keep track of own numbers

last recv. # | integer | 4 | the sequence number of the last packet received

split count | integer | 4 | the number of packets the current message was split in to

seq. # of 1st packet | integer | 4 | the sequence number of the first packet for current message

data length | integer | 4 | the length of the data in this message (which will be greater than packet length if the message is split)

Client initiates the login by sending a type: 0x0001, seq: 1, src: 0x00000200,

dst: 0x00000000, split: 0, and no data to the server

Server responds with type: 0x0002, seq: 1, ack: 1, src: 0x00000000, dst:

0x00000200, split: 0, with 8 bytes of data attached

Client responds with type: 0x0403, sequence: 1, last: 1, dst: 0x00000200,

split: 1, with 4 bytes of data attached. This 4 bytes corresponds to the first

4 bytes that the server sent (in LE) XORed with 0xA426DF2B

Server responds with type: 0x0404, seq: 2, ack: 1, src: this becomes the dest

for all subsequent packets from client, split: 1

Server sends type: 0x0406, seq: 3, acq: 1, with the following 28 byte data

stream: "17 05 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 01 00 00

00 01 00 00 00"

Client responds type: 0x0406, seq: 2, acq: 3, with the following data stream:

"18 05 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 01 00 00 00 80 00

00 00 [128 byte RSA encrypted data block containing a 32 byte random session

key generated by the client, xx] [CRC32 of preceding 128 bytes, cc] 00 00 00

00".

Server responds with type: 0x0406 with the following 24 bytes of data: "19 05

00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 01 00 00 00"

Server and Client now sends messages which are AES encrypted with Cipher-block

chaining (CBC). The key for the packets is transferred within the previous

message exchange. The IV used for the CBC is computed from the first 16 bytes

of each message. The decypted message appear to be compressed uses the zlib

libraries, however I've been unable to decompress them thus far.

The encryption method has yet to be determined. There was some discussion on

the pidgin mailing list that they might use the ICE (Information Concealment

Engine) for encryption. According to the Valve Developer pages, ICE is used to

encrypt script files used for games, so it does not seem completely

unreasonable that they could use it for their communication protocol, however,

it doesn't necessarily imply that they do use it for encryption of network

data.

Dissecting the steamclient.dll, there doesn't seem to be anything obvious that

would identify the use of ICE. However, there are several references to the

Crypto++ Library:

* CryptoPP.

* AlgorithmParametersBase

* IKeyCallback

* RSAFunction

* CipherModeBase: GetNextIV() must be called on an encryption object

* CCrypto::RSAEncrypt

* CCrypto::HexDecode

In addition, there is some thought that the 128 bytes transferred from the

client to the server (see above) might be a 1024-bit RSA public encryption key.

Noticing that the client begins sending data to the server before the server

has been able to send a key to the client, it is likely that the client has the

server's public key stored locally somewhere. However, this doesn't help with

figuring out the requests being sent by the client, unless we were to somehow

insert a fake public key for which we have the private key, then decrypt what

the client tries to send to the server. Once that's been done, the rest would

be fairly straightforward: Just send our own public key to the server, then

decrypt the responses we get back.

128 unique bytes marked with {}

* [Third-party Plugin](http://code.google.com/p/pidgin-opensteamworks/)

developed for Pidgin (GNU GPL v3, uses Steam Mobile API as of version 1.0,

users of this appear to the network as if on a mobile device)

* Valve [developer wiki page](http://developer.valvesoftware.com/wiki/Friends)

for Steam Friends

* [Wikipedia page](http://en.wikipedia.org/wiki/Steam_%28content_delivery%29)

* [Ticket](http://developer.pidgin.im/ticket/3987) requesting support for the

Steam protocol within libpurple

* [Ticket request](http://developer.pidgin.im/ticket/14514): Create

cross-platform Steam chat plugin with Steamkit2

* December 2007 Pidgin mailing list

[thread](http://pidgin.im/pipermail/devel/2007-December/thread.html#4263)

* February 2008 Pidgin mailing list

[thread](http://pidgin.im/pipermail/devel/2008-February/thread.html#4876)

* Valve Developer Information about

[ICE](http://developer.valvesoftware.com/wiki/ICE)

* [Vapor](http://www.facepunch.com/threads/1057523-Vapor-Cross-Platform-Steam-Client) -

open-source Steam client for Linux/Windows

* [Open SteamWorks](https://bitbucket.org/VoiDeD/open-steamworks/overview) -

open-source, platform independent Steam client, written in Mono (MS NET)

* [SteamRE](https://bitbucket.org/VoiDeD/steamre/overview) - Successor of

Vapor, written in Mono

* [libsteam](https://github.com/SergeB/libsteam) - C-Library which offers basic

steam protocol functions such as login

* [SteamDroid](https://github.com/FlyingPie/SteamDroid) - SteamFriends chat

client for android devices (source, written in java)

* Even more implementations:

* [ChewieBot_SteamRE](https://github.com/cessna/ChewieBot_SteamRE/tree/master/ChewieBot_SteamRE)

* [BitlSteam](https://github.com/vahokif/BitlSteam)

* [python-steam](https://github.com/meltingwax/python-steam)

* [Vaporized](https://github.com/hekar/Vaporized)

* [pocketSteam](https://github.com/azzymaster/pocketSteam)

* [SteamMobileLib](https://github.com/Doridian/SteamMobileLib)