Ever wanted to build your own MSN messenger? In this article series Neville rips apart the MSN messenger protocol for all to see. It's a must read for any developer!
The MSN Messenger Protocol Torn Apart: Part 1/3 - The Workings of the Protocol (Page 3 of 7 )
All the messages are in red are sent from the client to the server. All the messages in green are sent from the server to the client.
Deciding on the Protocol Version The first phase in any messenger protocol is the connection phase. You as a client have to be authenticated by the dispatch server. We start off by opening a connection to the dispatch server through 64.4.13.17 (or its FQDN which is messenger.hotmail.com) on port 1863. Once connected, the VER command is the first one we send to the server. It looks something like this:
VER 0 MSNP7 MSNP6 MSNP5 MSNP5 CVR0
This command is actually meant to decide upon which version the client and server would use to communicate. As a client we send the versions we can support to the server. The command identifier is VER and the transaction ID is 0.
The server sends back a reply, which looks like this:
VER 0 MSNP7
By receiving this command the server and the client have decided which version to communicate with.
Deciding on the Authentication Protocol Once we decide which version of the protocol we will be using, we decide upon the authentication protocol that will be used. We will send the INF command to the server now. It looks something like this:
INF 1
In this command we ask the server which authentication method it wants to use. It's accompanied by a new unique transaction id, which is 1.
The server sends back a reply, which looks like this:
INF 1 MD5
By receiving this command the server and the client have decided that they will use MD5 authentication.
MD5 is an encryption algorithm. The algorithm accepts text and encrypts it into a "message digest", or encrypted text. You don’t have to write the algorithm yourself. You would however need an API in the programming language you are using that can help you convert plaintext into encrypted text using the MD5 algorithm. That is all you need to know about MD5 for now.
Referral to Notification Server Now we will send the USR command to the dispatch server. It looks like this:
USR 2 MD5 I you@hotmail.com
We send this command to the server just to get the notification servers address and port. We also send with it a new unique transaction id (which is 2), the authentication protocol and the email id of the person who wants to connect. The 'I' just tells the USR command that we are imitating the authentication process. For the entire authentication process to take place we would have to send a number of messages to and fro.
Remember, only part of the authentication takes place on the dispatch server. The actual login and password validation would take place on the notification server.
The server replies like this:
XFR 2 NS 2.3.4.5:1234
The server sends us an XFR command in reply to our USR command. The XFR command is a referral command. In this case 'NS' denotes the notification server. The IP address and the port number are followed after that. This means that the server is referring us to a Notification server. It also sends across the notification servers IP address and port number, which we need to connect to.
Username and Password Authentication Once we receive details about the notification server, the initial stages of authentication are similar to the ones we had in the dispatch server. They look like this:
VER 3 MSNP7 MSNP6 MSNP5 MSNP5 CVR0 VER 3 MSNP7 INF 5 INF 4 MD5 USR 5 MD5 I you@hotmail.com
Now hopefully you remember what each of these messages mean. Remember, we are sending these messages to the notification server this time. Also note each of the transaction id's. They are all unique from the ones we used earlier. Usually we use a simple counter variable and keep incrementing it for setting the transaction ids from the client side.
Ok, now after we have sent the Initial authentication message to the notification server, it sends us back a message, which looked like this:
USR 5 MD5 S 0987654321.123456789
The server replies by sending us a USR message. It also sends us the transaction id (which is the same one we sent in our initial USR command to the server), the authentication protocol and a challenge string. The 'S' in the USR command stands for subsequent. It denotes that the authentication process has already started and this is one of the subsequent authentication commands. Now this command has a MD5 hash (or challenge string) sent along with it.
What we need to do now is take that challenge string, concatenate (join) it with our password and use the MD5 algorithm to create a lowercase hexadecimal hash. Of course as I mentioned, you would have whatever API in your programming language you are using to implement MD5 encryption. After we generate the hash this is what we send to the server.
USR 6 MD5 S 45tc56cd52aq6fcdsw3cdkl3ds3dddsc
This command begins with the command identifier, which is USR. It has an all-new unique transaction id. We have the 'S' keyword to denote that it's a subsequent authentication message. Finally, we have the MD5 hash we have generated using the challenge string (sent by the server in the last message) and our password.
If this step fails the server would throw an authentication-failed error. On the other hand, if all goes well and the user is authenticated the server sends us a reply, which looks like this:
USR 6 OK you@hotmail.com NevilleMehta
The server sends us the last USR command. It also has the transaction id, email id and the screen name of the person logged in. We also have the keyword "OK", which denotes that the user is authenticated.
HTML 
