The MSN Messenger Protocol

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! As I sat
at my desk one night, I wondered "How do these damn messenger programs work?". I
wondered if I could make a client of say yahoo or msn messenger myself, or maybe
understand how instant messaging software communicated. To start off, I got hold of a
port monitor and monitored the msn messenger packets as I worked on it. After a while I
went and checked the log file, which were recording all of my activity on the port just to
find lots of data transferred.

Truly, at the first glance it was looking quite alien. Then I thought instead of sitting and
trying to figure out what all these packets meant, let me just try to search online for
some information. Well I found more information than expected.

The program I have spoken about is a port monitor not a port scanner. It's important that
you know the difference. A port scanner is a program that tells you which ports are open
on a host (don't port scan just any host. If they find out you may be in trouble). A port
monitor is a program, which monitors all activity on a particular port on a host. That's
what I used to monitor msn messenger on my local machine.

Now let me tell you why I choose msn messenger and not any other. Firstly, I use msn
messenger a lot more than any other messenger. Secondly, on searching, I found out
that Microsoft (to my surprise) has published an official protocol draft on the msn
messenger protocol - It is quite informative. I also came across a few tutorials on the net
which had explained bits about the msn messenger protocol. Those too were quite
helpful.

So, you're a bit confused? You see, I really can’t sit and explain what packets are and
how data is transferred exactly between two sources -- this is not a networking tutorial.
You will need some basic networking knowledge to follow this tutorial. You should be
aware of networking terminology such as packets, sockets, ports, port scanners, port
monitors etc.

I will be explaining as much as I can as I proceed. I do advise complete beginners who

are fascinated by the idea of creating their own version of msn messenger to keep
away. This article is not targeted at beginners.

Digging Into the Protocol

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

1
 The MSN Messenger Protocol

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.

2
 The MSN Messenger Protocol

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.
The Workings of the Protocol
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

3
 The MSN Messenger 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.

4
 The MSN Messenger Protocol

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

5
 The MSN Messenger Protocol

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.

Change Your Initial Status

After we are authenticated, the first thing we do is to change our current status. We
have a command called CHG. This command helps us to change our current status.
This is what we sent to the server to change our initial status:

CHG 7 NLN

We have the command identifier CHG. We have the unique transaction id. We also
have a parameter called "NLN". NLN tells the server to change our status to online. Like
NLN, we have various parameters for other statuses. For example this would be the
command we would send the server if we wanted to change our status to Hidden or
Invisible:

CHG 7 HDN

Yes, HDN is the parameter we send to tell the server to change our status to
Hidden/Invisible. There is a list of these parameters and what each one does in
Microsoft's official draft on the protocol. I have attached the same at the end of this
article.

The server then sends us back this reply confirming the status change:

CHG 7 HDN

The reply consists of the command identifier, the transaction id and the current status of
the user.

Retrieval of a Few Important Server Messages

By now, the client should be ready for a few messages from the server. What are these
messages? Well, we could regard them as commands sent to us by the server but
commands having a different format. We have seen the standard command format,
which looks like this:

<COMMAND IDENTIFIER> <TRANSACTION ID> <PARAMETERS>

The message command doesn't in anyway look like this. If we see one such message
we would be able to understand the format. As soon as we notify the server of our initial
status, the server sends us this message command:

MSG Hotmail Hotmail 450

MIME-Version: 1.0

6
 The MSN Messenger Protocol

Content-Type: text/x-msmsgsprofile; charset=UTF-8

LoginTime: 1034601891
EmailEnabled: 1
MemberIdHigh: 93760
MemberIdLow: -52562410
lang_preference: 1033
preferredEmail: neville2150895@hotmail.com
country: IN
PostalCode:
Gender: m
Kid: 0
Age: 19
BDayPre: 2
Birthday: 30245
Wallet: 0
Flags: 1031
sid: 507
kv: 4
MSPAuth: 4voZp65RUDJlf6KzMhWAgJKts*N3Wn8OVQB6AW
JfFNos3D0een95XDaOLIFTt3q6!L7M*cdoHvKQ6*2NrYOaMG7Q$$

This is what the command looks like. We first have MSG, which is the command
identifier. The next two parameters, say Hotmail and Hotmail and finally the number
450. The number 450 denotes the total number of bytes in the entire message
excluding the current line (The line which has MSG in it, the first line).

Next, we have the mime version and content-type. The mime version would be same in
all cases but the mime content-type is "text/x-msmsgsprofile" in this case. The char set
of the message is mentioned in the same line thereafter. All the lines after that consist
of the mime body.

This message, which the server sent us contains details about the .NET passport we
signed into. The body of this message thus contains details of the user signed in like
age, gender, birthday, postal code etc.

Another such message we should be ready to except is the following one:

MSG Hotmail Hotmail 221

MIME-Version: 1.0
Content-Type: text/x-msmsgsinitialemailnotification; charset=UTF-8

Inbox-Unread: 0
Folders-Unread: 2
Inbox-URL: /cgi-bin/HoTMaiL
Folders-URL: /cgi-bin/folders
Post-URL: http://www.hotmail.com

7
 The MSN Messenger Protocol

Again, like all other message commands, this one consists of the command identifier,
the two Hotmail parameters and the total number of bytes on the first line. Next we have
a mime version, which is the same in all messages and the Content-Type, which is
"text/x-msmsgsinitialemailnotification" in this case. We also have the char set on the
same line thereafter.

This message contains details about email in the inbox of the user. You must have
noticed when you login into your messenger account and you have any new unread
mails you are prompted. Well this is the message responsible for that prompt. You see
the string Inbox-Unread :0 in the mime body. That shows there are 0 unread mails in
your inbox. This message also has a few other details about your inbox.

Again, these are messages that your client may or may not want to respond to. I have
just included these in this article to let you know about the entire process in detail. In
your version of msn messenger it’s entirely up to you to prompt the user about new
mail. In this case if you don’t want your messenger to care about new unread mails in
your inbox then you could ignore these messages. The first message sent to us by the
server, which has the users .NET passport details passed through, is quite useless.

Order the List

Now is the time to ask for your contact list. Before I proceed, let me tell you about the
four types of lists. Firstly we have the forward list denoted by 'FL'. It consists of the
users on your contact list. Secondly we have the reverse list denoted by 'RL'. It consists
of all the users who have added you to their contact lists. Thirdly we have the 'AL' or the
allow list. These are the users who are allowed to see your online status. Finally, we
have the block list denoted by 'BL'. These are the users who you have blocked. Get the
idea? Let me summarize it for you once more:
FL – Forward list (Users who you have added to your contact list)
RL – Reverse list (Users who have added you to their respective contact list)
AL – Allow list (Users who are permitted to see your status)
BL – Block list (Users who are not permitted to see your status)
We have a command called LST, which we could use to request any of these lists. The
command we would send to the server to request our forward list would look like this:

LST 8 FL

Firstly, we have the command identifier LST. Next we have the transaction id of this
command. Finally, we have a two-letter list code that we want to request from the
server. Yes, you could replace FL with RL, AL or BL, depending on which list you want
to request from the server:

LST 8 FL 35 1 4 yourpal1@hotmail.com Pal1 0

LST 8 FL 35 2 4 yourpal2@hotmail.com Pal2 1
LST 8 FL 35 3 4 yourpal3@hotmail.com Pal3 2
LST 8 FL 35 4 4 yourpal4@hotmail.com Pal4 1

8
 The MSN Messenger Protocol

The server replies to us with all of the users on our list. There are four lines because we
have four users on our list. Lets look at what all of these parameters the server sent us
mean.

Firstly we have the command identifier LST. Then we have the transaction id (which is
the same as one we sent to the server. This is just to let us know that all of these
commands are in response to that one LST command we sent to the server). The next
parameter is something called a list version id, i.e. 35 in all the lines.

Next we have the users serial number. It's just like a normal counter. After that, we have
a parameter that tells us the total number of users in this list. In this case it is 4. Moving
on, we have the email id of the user on our list. The screen name of the user is next,
followed finally by the group id.

I haven't yet come to groups so lets keep that pending for now but do keep in mind; the
last parameter is the group id of that respective user.

More on Statuses
Once you are connected to your messenger account, the server would send you the
status of each user on your list. We did use the CHG command initially. Do you
remember what that was for? Yes, that was to change our initial status. The command
looked like this:

CHG 7 HDN

The transaction id we used for this command was 7.

Remember that whenever the server notifies us of the status of users on our contact list,
it would send us necessary commands using the same transaction id we used to send
the CHG command to the server. In this case the server would use 7. Lets have a
closer look:

ILN 7 BSY yourpal1@hotmail.com Pal1

ILN 7 AWY yourpal2@hotmail.com Pal2

These are the commands that the server sent us once we connected to our messenger
account. We assume there are just two people on our contact list. Each line denotes the
status details of a user. We start of with ILN, which is the command identifier. It is the
command used to notify initial statues of users on your forward list. Then we have the
transaction id i.e.7 (I already explained why it is 7). Next we have the current status of
that user. In the first line it is ‘BSY’ that denotes Busy. In the second line it is 'AWY' that
denotes Away. We have a list of parameters that denote the current status of the user.
For e.g. NLN denotes online, AWY denotes away, PHN denotes on the phone etc.

A list of these parameters and what each one does is present in Microsoft's official draft

9
 The MSN Messenger Protocol

on the protocol. I have attached the same at the end of this article. Lastly, we have the
respective users email id and finally his screen name.

Apart from these steps, the messenger has to be ready for many other commands sent
to the client from the server. The client should understand, recognize and respond to
every kind of command sent to it from the server to avoid any kind of errors.

User Statuses
Every time a user comes online your msn messenger alerts you, doesn't it? The client
knows when this happens because the server tells it. That's what your client should be
ready to handle. The server uses NLN and FLN commands to tell us the real time status
of users. Lets have a closer look:

NLN AWY yourpal1@hotmail.com Pal1

FLN yourpal2@hotmail.com

Look at the first command. It begins with the NLN command identifier. The NLN
command notifies the client when users go online or their online state changes. The
NLN command doesn't contain any transaction id because you really don't need to
respond to this message (respond as in respond back to the server with a command).
It's just to let you know that a users online state has changed. After that we have the
current state of the user. 'AWY' in this case means the user has changed his status to
away. After that we have the respective users email id and his screen name.

Let's have a look at the second command. It's the FLN command identifier. The FLN
command notifies the client when the user goes offline. Again, this command doesn't
have a transaction id (the same reason why the NLN command doesn't have a
transaction id). This command sends us just one more parameter, which is the users
email id that has gone offline.

Challenges
In order to make sure that your msn client is active, the server keeps sending something
called challenges at regular intervals. These commands are sent at random times. Let
me show you what these commands are and how you should respond to them. This is a
typical challenge message the server would send you:

CHL 0 90938290383838737622

It contains the command identifier CHL. Next we have a transaction id, which is 0.
Whenever the server needs to send you any commands it usually would use the
transaction id of 0. The final parameter is a challenge string.

What you would have to do is take this challenge string, concatenate it with the string
'Q1P7W2E4J9R8U3S5' and encrypt the resultant string with the MD5 algorithm. So in
this case you would encrypt '90938290383838737622Q1P7W2E4J9R8U3S5' using the
MD5 algorithm and send it back to the server. We would send a reply, which looked like

10
 The MSN Messenger Protocol

this:

QRY 9 msmsgs@msnmsgr.com 32
1293ft670983hydr5423yhdv67f6f4f5

We respond to this challenge with the QRY command. We send with it an all-new
unique transaction id. Next, we send the string 'msmsgs@msnmsgr.com' and finally the
number 32. 32 denotes the number of bytes in the command excluding the current line,
which contains the QRY command identifier. After that we have a line break and we
send the encrypted MD5 digest along.

The server would respond back with this message:

QRY 10

The server sends you the QRY command with the same transaction id you had used to
send the server the answer of the challenge i.e. 10. Receiving this message would
mean you have successfully passed the challenge. In case you fail to challenge, the
server would disconnect you and send you an error command.

Server Messages
There are a few other server messages that the server sends to us on a few occasions.
Again, it's up to you to respond to them or not.

This is the message command the server sends to us when we receive a new email:

MSG Hotmail Hotmail 340

MIME-Version: 1.0
Content-Type: text/x-msmsgsemailnotification; charset=UTF-8

From: Mehta
Message-URL: /cgi-bin/getmsg?msg=MSG1029401739.3&start=1610592&
len=402&curmbox=ACTIVE
Post-URL: https://lc1.law13.hotmail.passport.com
/ppsecure/domessengerlogin/EN
Subject: Hi
Dest-Folder: ACTIVE
From-Addr: example@passport.com
id: 2

The first 3 lines I have already explained earlier. The Content-Type of this message is
'text/x-msmsgsemailnotification'. The mime body again contains the details about the
new email message, which has just arrived. It contains details like its subject, who it is
from, which email id is it from etc.

This is the message the server sends to us when delete an email from our inbox:

11
 The MSN Messenger Protocol

MSG Hotmail Hotmail 145

MIME-Version: 1.0
Content-Type: text/x-msmsgsactivemailnotification; charset=UTF-8

Src-Folder: ACTIVE
Dest-Folder: trash
Message-Delta: 1

The first 3 lines are explained earlier. The Content-Type of this message is 'text/x-
msmsgsactivemailnotification'. The mime body again contains the details about the
inbox and message deleted.

12