Home arrow HTML arrow Page 3 - The MSN Messenger Protocol Torn Apart: Part 1/3
HTML

The MSN Messenger Protocol Torn Apart: Part 1/3


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!

Author Info:
By: Neville Mehta
Rating: 5 stars5 stars5 stars5 stars5 stars / 93
October 20, 2002
TABLE OF CONTENTS:
  1. · The MSN Messenger Protocol Torn Apart: Part 1/3
  2. · Digging Into the Protocol
  3. · The Workings of the Protocol
  4. · Change Your Initial Status
  5. · Order the List
  6. · User Statuses
  7. · Conclusion

print this article
SEARCH DEVARTICLES

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.
blog comments powered by Disqus
HTML ARTICLES

- Does HTML5 Need a Main Element?
- Revisiting the HTML5 vs. Native Debate
- HTML5: Not for Phone Apps?
- HTML5 or Native?
- Job Hunting? Freelancer.com Lists This Quart...
- HTML5 in the News
- Report: HTML5 Mobile Performance Lags
- The Top HTML5 Audio Players
- Top HTML5 Video Tutorials
- HTML5: Reasons to Learn and Use It
- More of the Top Tutorials for HTML5 Forms
- MobileAppWizard Releases HTML5 App Builder
- HTML5 Boilerplate: Working with jQuery and M...
- HTML5 Boilerplate Introduction
- New API Platform for HTML5

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials