This is a txt I found today - help s you understand and Use/abuse the new MSN-Messenger 6
----
Microsoft's attempt to make the whole Passport framework more secure has resulted in the introduction of a HTTP Secure Socket Layer (HTTPS) to negotiate authentication.
The old system from MSNP7 and lower used MD5 hashes of your password concatenated with a server side generated seed to prevent the transmission of your password in plain text but it was inevitable that at some point or another this was going to change. The new authentication mechanism sends you on a wild goose chase accross the microsoft passport servers in search of a response string to use when authenticating with the notification server, which in itself, is not an easy task if you do not know the order things have to be done, or what data has to accompany your requests. This new protocol version has certainly turned up the heat for protocol analysts let alone programmers who just implement custom solutions for well known services. This article will explain the new secure authentication mechanism that lies behind MSNP9 and hopefully open a new way of thinking for those that dont currently work within the bounds of secure communications.
Initiating a connection with the MSN Messenger servers still remains exactly the same, you must open a TCP socket to messenger.hotmail.com on port 1863. Now would be a good time to offer some advice, always resolve the IP address of messenger.hotmail.com everytime you connect or use the actual host name itself. Many people experience problems from the very start because they try to connect to an IP address which is now outdated. At the time of writing this article, messenger.hotmail.com resolved to 207.46.104.20, in the past it resembled something of the following form 63.*.*.*, which is obviously very different.
Unlike previous MSN Messenger protocols, the CVR command has now become mandatory if you plan to use MSNP8, or MSNP9. The CVR command lets the notification server know what client version you are using so that it can tell you if there is a newer one available and where to get it from. Other than that the initial commands are exactly the same. What follows is what the start of a typical session should look like.
c: VER 4 MSNP8 CVR0
s: VER 4 MSNP8 CVR0
c: CVR 5 0x0409 winnt 5.1 i386 MSNMSGR 5.0.0540 MSMSGS...
s: CVR 5 6.0.0602 6.0.0602 1.0.0000 download URL...
C: USR 6 TWN I
[email protected]
s: USR 6 TWN S lc=1033,id=507,tw=40,fs=1,ru=http%3A%...
Once we get to this point we notice a difference in this protocols USR negotiation command. This time instead of using the old MD5 hashing method, we are introduced to a new method called TWN. First the client says USR 6 TWN I
[email protected], which lets the server know that the secure mechanism will be used, one note, if the MSNP9, or MSNP8 protocols are to be used, then the secure TWN method is mandatory, MD5 is not an option. The server responds with its own USR response containing a very large challenge string, which is the part that begins with lc=1033,i=.... Immediately, this challenge string should be stored in its own variable ready for easy use, and so begins the SSL connection.
With the challenge string aquired from the USR response, the journey through Microsoft's Passport servers begins. The first stop is nexus. To be able to retrieve our challenge response we must first find out where the Passport login server is, this must be done over a Secure HTTP connection. To begin with, you need to retrieve the HTTP headers of
https://nexus.passport.com/rdr/pprdr.asp. The headers returned should resemble something of the following.
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 27 Aug 2003 11:58:47 GMT
Connection: close
PassportURLs: DARealm=Passport.Net,DALogin=login.passport.com/login2.srf,...
Content-Length: 0
Content-Type: text/html
Cache-control: private
The value of DALogin in the PassportURLs header item is what is needed to proceed. In this case it is login.passport.com/login2.srf. This should also be stored in its own variable with
https:// added to the front, which becomes
https://login.passport.com/login2.srf. This URL represents the Passport login server. Now a Secure HTTP connection must be made to this url, but with a special custom header attached to the request headers. The start of the custom header looks like the following.
Authorization: Passport1.4 OrgVerb=GET,OrgURL=http%3A%2F%2Fmessenger%2Emsn%2E com,sign-in=USERNAME, pwd=PASSWORD,CHALLENGESTRING
This is all one line, so if your browser is breaking it up make sure that when it is sent to the server, it is all one line. The part that says USERNAME must be replaced with your passport login address, with the @ symbol escaped. This means that the @ symbol must be replaced with %40. So if you want to login to
[email protected], you would replace USERNAME with, someaccount%40hotmail.com. The part that says PASSWORD must be replaced with the account password, and the part that says CHALLENGESTRING must be replaced with the challenge string you retrieved earlier. In the end, your custom header item should look similar to the following.
Authorization: Passport1.4 OrgVerb=GET,OrgURL=http%3A%2F%2Fmessenger%2Emsn%2E com, sign-in=someaccount%40hotmail.com,pwd=mysecretpassword, lc=1033,id=507, tw=40,fs=1,ru=http%3A%...
Remember that this must all be one line, and also please not that the sample challenge string that was added in this example is not a full challenge string, it is merely a cut down version to reduce the amount of text in the example. You should now connect to the URL you retrieved earlier,
https://login.passport.com/login2.srf, using a Secure HTTP connection, along with the custom header item in the request header. The Passport Login server should respond to your request with something similar to the following.
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 02 Jun 2003 11:59:00 GMT
PPServer: H: LAWPPIIS6B061
Connection: close
Content-Type: text/html
Expires: Mon, 02 Jun 2003 11:58:00 GMT
Cache-Control: no-cache
cachecontrol: no-store
Pragma: no-cache
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: MSPSec1= ; expires=Thu, 30-Oct...
Set-Cookie: MSPSec=5Cdd1SshOELpwqafsSuY...
Set-Cookie: MSPAuth=5yDBU0BqvDa7UiY9W9nVEn...
Set-Cookie: MSPProf=5a0mKE6PKDsxz!*4apQt0amnQ...
Set-Cookie: MSPVis=507;domain=.passport....
Set-Cookie:
[email protected]; HTTPOnly=...
Set-Cookie: MSPShared= ; HTTPOnly= ; domain...
Authentication-Info: Passport1.4 da-status,...
Content-Length: 0
Please note that some of the lines where shortened to prevent filling the screen with redundant information that would normally get annoying. If you didnt receive this reply and infact received a redirection then simply follow the redirections until you get something that looks like above. But remember, for every redirection you visit it is very important that you also send the custom request header we prepared earlier. Taking a closer look at the Authentication-Info header item.
Authentication-Info: Passport1.4 da-status=success,tname=MSPAuth,tname=MSPProf,tname=M SPSec, from-PP=t=4vdeV4dhRDGcValSvuC143tFgayRBmfO5qNWGfpxzq61I yJwBaUtH2ic20kviN Xqj9ix7YaHIiWi2d4jCUy8I9ow$$&p=4J3jAFU45AeG0OgpJkq C8XWMRPlGvw8hKTETWMcgl UJUgiE7Ggg!bOH!qjmK3SumCXNwnao1ltnDcubRIGe0*tL5uxz C4mw5b97plTslhPeIEErkO ACmoDmWsVQMXcgNCwoAOF4ahuefugrSFMDDBjXpGTyvnFV51Wd 6vHUo*2AVo$', ru=http://messenger.msn.com
Here we are presented with quite alot of text, all of which is very important. The first item in the list is da-status, the value of this tells us wether or not our login was successful, if it was successful the value is success, as above, whereas if your login failed it will present you with the value failed. Upon failure of a login, a new item is added to this heap of text, it is named cbtxt, and it will tell you why your login failed. But luckily in this attempt, the login was a success. Looking closer at this text you will notice a value called from-PP, and you'll be happy to know that this is the challenge response we return to the notification server with. Extracting the value from the text heap above we get the following.
t=4vdeV4dhRDGcValSvuC143tFgayRBmfO5qNWGfpxzq61IyJw BaUtH2ic20kviNXqj9ix7Ya HIiWi2d4jCUy8I9ow$$&p=4J3jAFU45AeG0OgpJkqC8XWMRPlG vw8hKTETWMcglUJUgiE7Ggg !bOH!qjmK3SumCXNwnao1ltnDcubRIGe0*tL5uxzC4mw5b97pl TslhPeIEErkOACmoDmWsVQM XcgNCwoAOF4ahuefugrSFMDDBjXpGTyvnFV51Wd6vHUo*2AVo$
This should be stored in its own variable for now. At this point all Secure HTTP connections are over and we return to the notification server. You will remember that the last thing that the notification server said to us was USR 6 TWN S lc=1033,id=507,tw=40,fs=1,ru=http%3A%... To respond to this challenge we simply reply with the last USR command, including our challenge response string as shown below.
USR 7 TWN S (And our challenge response string)
Which becomes
USR 7 TWN S t=4vdeV4dhRDGcValSvuC143tFgayRBmfO5qNWGfpxzq61IyJw BaUtH2ic20kviNXqj9ix7Ya HIiWi2d4jCUy8I9ow$$&p=4J3jAFU45AeG0OgpJkqC8XWMRPlG vw8hKTETWMcglUJUgiE7Ggg !bOH!qjmK3SumCXNwnao1ltnDcubRIGe0*tL5uxzC4mw5b97pl TslhPeIEErkOACmoDmWsVQM XcgNCwoAOF4ahuefugrSFMDDBjXpGTyvnFV51Wd6vHUo*2AVo$
These responses must be one line only. Once this has been done the server will either say OK or it will disconnect harshly, if it disconnects go back and make sure that you are extracting values properly, and that the order you visit the passport servers is infact the correct order. If worse comes to worse and you still cant work it out, post a comment to this article and I will reply to you privately.
Secure communications are extremely important, first and foremostly they give you the privacy you need, and secondly, they are just plain cool.