The MSN Messenger Protocol Torn Apart: Part 1/3 - Digging Into the Protocol
(Page 2 of 7 )
Msn messenger uses tcp/ip to communicate. All data transmitted from the client and the server is in clear text. That means if you monitor msn messenger on your pc, you can actually read the data being passed.
Before starting off, let me introduce you to a few concepts of the msn messenger protocol. There are 3 servers involved in this entire process:
The dispatch server This is the server which we initially connect to. The main function of this server is the basic authentication of the client. You can connect to the dispatch server through 64.4.13.17 (or its FQDN which is messenger.hotmail.com) on port 1863.
The notification server After the basic authentication is handled through the dispatch server, the dispatch server refers the client to a notification server. Until the client lives, he is connected to the notification server. The main functions of the notification server are to store most of the clients session details. Things like contact list management, status changes, email arrivals, etc are all sent to you through the notification server.
The switchboard server The switchboard server is mainly used to initiate chat sessions between you and your msn contacts. Let me give you an example. When "Fred" sends a message to "Tom", the following are the steps that would take place:
- Fed would send a request to the notification server that he would like to chat with Tom.
- The notification server then refers Fred (sender) to a switchboard server.
- Soon Tom (receiver) gets a notification from the Notification server to connect to the same switchboard server that Fred (sender) is connected to.
- Once connected to a common switchboard server, they begin instant messaging.
It's not easy to reverse-engineer a protocol just by looking at the data packets being passed through the network using that protocol. If you at this moment take a port monitor and try to figure out the entire msn messenger protocol by just looking at what's being transmitted, its not that simple. I suggest you complete reading this article and then try. I assure you that after you have read this article the packets you monitor on your PC will make a lot more sense than they would right now.
Also, make sure that you get a good port monitor. I suggest you use Uasoft's sniffer -- it's what I use. You can choose which packets you want to monitor too. You should choose to monitor just the TCP and the IP packets, because that's what the msn messenger protocol works on.
Commands
Whenever the client and the server want to communicate with each other, they send commands to do so. Every command has a 3-word identifier. This tells the receiver of the command what it’s all about. Most of these commands end with a new line character to tell the receiver they have ended. There are a few exceptions to this. I will tell you about those commands a little later. For now, the typical command syntax (with the exception of a few) would be something like this:
(COMMAND IDENTIFER) (TRANSACTION ID) (VALUE) (NEWLINE)
Transaction Id's
Whenever the client sends a command to the server, the server sometimes has to respond back. Now let me give you a small example. Have you ever come across a support ticket system somewhere on the Internet? (If not, see ours). How does it work? Well, when you enter your query into the system you are given a support ticket id. Whenever your question is answered, it is accompanied by the support ticket id just to let you know that it's your question being answered.
Similarly in case of the msn messenger, when the client sends a command to the server he sends along with the command a transaction ID. It’s any number between 0 and 4294967295. When the server responds back to your command it includes the transaction id that you sent through with that command. Many a time the server would send more than one reply to your command.
What happens when the server wants to send a command to the client? We must remember that commands are mostly send from the server to the client. When this is the case, the server sends a transaction id of 0. This means that the server doesn't really require any response back from the client. Usually these are challenge commands (I will discuss challenge commands a bit later).
Errors
Whenever an error occurs, the server sends error command. The error command is nothing but a three-digit code accompanied by the transaction id of the command, which has caused the error. Every error command also includes a short description of the error thrown. So a typical error command sent by the server to the client would look like this:
(ERROR IDENTIFER) (TRANSACTION ID*) (ERROR DESCRIPTION)
We have a list of these error identifiers and their description in Microsoft's official draft on the protocol. I have attached this as part of the support material for this article on the last page.
Next: The Workings of the Protocol >>
More HTML Articles
More By Neville Mehta
