ZoRoNaX' blog: Live Messenger

ZoRoNa's profileZoRoNaX' blogBlog

Tools

Help

Blog

Summary

Listed by:

<< First < Previous Next > Last >>

10/5/2006

Object Store types

Recently, Inky presented me a list of Object Store types (Object Store is the functionality that stores your messenger content [display pictures, emoticons, etc] on your computer) and asked me if I could fill in the blanks. Because I worked the last couple months on a tool that can enumerate all the installed content (the import and export functionality is currently on the to-do list) I was able the complete most of the list. After a small research, I was able to complete the whole list.

Value	Name	Comments
1	Avatar	Unknown, but already present since the beginning (MSN Messenger 6.0).
2	Custom Emoticons
3	User Tile	Static display pictures.
4	Shared File	Unknown, but already present since the beginning (MSN Messenger 6.0).
5	Backgrounds	Static backgrounds.
6	History
7	Deluxe Display Pictures	Dynamic display pictures.
8	Winks3	Winks.
9	Map File	A map file contains a list of items in the store.
10	Dynamic Backgrounds	Dynamic backgrounds.
11	Voice Clip
12	Plug-In State	Saved state of Add-ins.
13	Roaming Objects	For example, your roaming display picture.
14	Location	Information about your locations (City, Country, etc).

If you list it per Messenger version, you get the following list.

MSN Messenger 6.0

Avatar
Custom Emoticons
User Tile
Shared File
Backgrounds

MSN Messenger 6.1

Nothing new has been added in this version.

MSN Messenger 6.2

History

MSN Messenger 7.0

Deluxe Display Pictures
Winks3
Map File

MSN Messenger 7.5

Dynamic Backgrounds
Voice Clip

Windows Live Messenger 8.0

Plug-In State

Windows Live Messenger 8.1

Roaming Objects
Location

Unified User Notification (UUN)

Unified User Notification (UUN) was introduced together with Unified Buddy Notification (UBN) in MSNP13, to give clients the ability to exchange data with another without setting up a Switchboard session first. Although MSNP13 isn't the latest version of the protocol, the real purpose of the commands has come to the light with the introduction of Windows Live Messenger 8.1. If you send a UUN command to a buddy via your Notification Server, his or her client will receive it as a UBN command from the Notification Server.

When sending a UUN command to the server, 4 parameters are needed: a transaction identifier, the receiving buddy's e-mail address, the type of the data being send and the payload length. The type parameter can have the following values:

1 - Data for the Shared Folders sharing engine (in particular for the Synchronization Negotiation Manager).
2 - Not yet observed, so still unknown.
3 - MSNSLP data for starting a P2P session (in particular for starting a direct connection).

The differences between UUN and UBN are that the UBN command doesn't have a TrId parameter and that the parameter containing the e-mail address is the e-mail address of the sender.

Sending UUN - Abstract

Client: UUN <TrId> <receivers e-mail address> <type> <payload length>\r\n<payload data>

Server: UUN <TrId> OK\r\n

Sending UUN - Example

Client: UUN 10 buddy_b@live.com 1 78\r\n<SNM opcode="SNM" csid="{054F3A1E-229C-453a-8AAA-5530DEC402BB}" priority="0"/>

Server: UUN 10 OK\r\n

Receiving UBN - Abstract

Server: UBN <senders e-mail address> <type> <payload length>\r\n<payload data>

Receiving UBN - Example

Server: UBN buddy_a@live.com 1 78\r\n<SNM opcode="SNM" csid="{054F3A1E-229C-453a-8AAA-5530DEC402BB}" priority="0"/>

9/8/2006

MSNP15

With the release of Windows Live Messenger 8.1 BETA build 0064 today, the MSNP15 protocol has been enabled. This protocol introduces a new authentication scheme called RPS "Relying Party Suite". Where TWN "Tweener" authentication is used on protocol versions 14 and below, RPS authentication will be used on protocol versions 15 and above. Furthermore, users are now able to show their location in Messenger.

RPS Authentication

When a user wants to authenticate, not much values have to change. The sequence looks a lot like the Tweener authentication except that it uses SSO as name of the authentication system. Note that only the ticket is sent to the server, because the system is only used for authentication and thus the profile is obsolete.

Abstract

Client: USR <TrId> SSO I <email>\r\n

Server: USR <TrId> SSO S <policy> <base64 encoded nonce>\r\n

Client: USR <TrId> SSO S <ticket> <base64 something>\r\n

Server: USR <TrId> OK <email> <verified> 0\r\n

Example

Client: USR 10 SSO I buddy@live.com\r\n

Server: USR 10 SSO S MBI 0Xb2iqDOU4LeVUCUCWAQt6aYYz+xmobpwEDV9IshEaWUDUyyZ3KG961MHI3mKPYW\r\n

Client: USR 11 SSO S t=... HAAAAAEAAAADZgAABIAAAA...\r\n

Server: USR 11 OK buddy@live.com 1 0\r\n

If you look at the above sequence, you'll see that the response command after the initial command has an extra parameter to hold a nonce and that the policy has MBI as value. The value of the policy field should be used to authenticate against the Passport STS service (just like you had to do with the Tweener authentication: ?id=...&tw=...&ct=..&..). The nonce is, together with a couple of more values responsible for the the new base64 encoded parameter which is sent back with the ticket. I'm sure we'll find out later how to do that exactly.

Because of the new authentication system, we have to add a new token request to the SOAP authentication request. I assume that you are familiar with the SOAP authentication request, so I'll only explain some of the values.

Example

<wst:RequestSecurityToken Id="RST1">

<wst:RequestType>http://schemas.xmlsoap.org/ws/2004/04/security/trust/Issue</wst:RequestType>

<wsp:AppliesTo>

<wsa:EndpointReference>

<wsa:Address>messengerclear.live.com</wsa:Address>

</wsa:EndpointReference>

</wsp:AppliesTo>

<wsse:PolicyReference URI="MBI" />

</wst:RequestSecurityToken>

The value of the Id attribute in the RequestSecurityToken element may vary from RST1..RST<N> (where N is a number higher or equal to 1). The value of the URI attribute in the PolicyReference element has to be taken directly from the policy field in the received USR command. Furthermore, you have to specify the service target messengerclear.live.com for the moment. However, this may change in the future.

The response to the above request looks like the following response.

Example

<wst:RequestSecurityTokenResponse>

<wst:TokenType>urn:passport:compact</wst:TokenType>

<wsp:AppliesTo xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">

<wsa:EndpointReference>

<wsa:Address>messengerclear.live.com</wsa:Address>

</wsa:EndpointReference>

</wsp:AppliesTo>

<wst:LifeTime>

<wsu:Created>2006-09-08T12:24:14Z</wsu:Created>

<wsu:Expires>2006-09-08T20:24:14Z</wsu:Expires>

</wst:LifeTime>

<wst:RequestedSecurityToken>

<wsse:BinarySecurityToken Id="Compact1">t=...</wsse:BinarySecurityToken>

</wst:RequestedSecurityToken>

<wst:RequestedTokenReference>

<wsse:KeyIdentifier ValueType="urn:passport:compact" />

<wsse:Reference URI="#Compact1" />

</wst:RequestedTokenReference>

<wst:RequestedProofToken>

<wst:BinarySecret>...a base64 encoded value...</wst:BinarySecret>

</wst:RequestedProofToken>

</wst:RequestSecurityTokenResponse>

I won't go into detail, but the value of the BinarySecurityToken with Id="Compact1", should be used as value in the final USR command sent to the server.

Locations

Another new item is that persons are now able to set their geographical location in their PSM, which has been done by adding the element LOC to the Data element of the XML in the UUX payload. Now your UUX command could look like this:

Abstract

UUX <TrId> <Size>\r\n

<Data>...<LOC>\0Location\01\0<String formatting>\0<Value 1>\0<msnobj Creator="buddy@live.com" Type="14" SHA1D="..." Size="..." Location="0" Friendly="..."/>\01\0</LOC>...</Data>

Example

UUX 12 ...\r\n

<Data>...<LOC>\0Location\01\0Somewhere\0Somewhere\0<msnobj Creator="buddy@hotmail.com" Type="14" SHA1D="+k0sN0ojrTqOlpbDezJUFG/0Yz0=" Size="218" Location="0" Friendly="UwBvAG0AZQB3AGgAZQByAGUAAAA="/>\01\0</LOC>...</Data>

The format of the value in the LOC element looks a lot like the value for the current song playing aka Music. The <String formatting> field should have the Location name as value, just like the <Value 1> field. Followed by a MSNObject with Type=14 (Location) and with the Location name as friendly name, which is in turn base64 encoded.

6/25/2006

Capabilities

Most MSNP documents make reference to a “ClientID” field. This bitmask is officially called “Capabilities”. The bitmask allows a client to broadcast, to others, its capabilities (e.g. GIF Ink support). New Windows Live Messenger 8 bitmask values are in bold below.

Value	Name	Description
0x000001	Mobile Online	The client is running on a mobile device.
0x000004	Renders GIF	The client is able to handle Ink in GIF format.
0x000008	Renders ISF	The client is able to handle Ink in ISF format.
0x000010	Webcam Detected	The client has a webcam and allows others to see it.
0x000020	Supports Chunking	The client allows a large message to be received in chunks.
0x000040	Is Mobile Enabled	This is used when the client is running on a MSN Mobile device. This is equivalent to the MOB setting in the BPR list.
0x000080	MSN Direct deviceⁱ	This is used when the client is running on a MSN Direct device. This is equivalent to the WWE setting in the BPR list.
0x000200	WebIM Client	The client is a web-based Messenger client.
0x000800	Connected via TGW	The client is an internal Microsoft client and/or Microsoft Office Live client.
0x001000	Has Space	The user owns a space on MSN Spaces.
0x002000	MCE User	The client is running on Windows XP Media Center Edition.
0x004000	Supports DirectIM	The client supports DirectIM.
0x008000	Supports Winks	The client supports Winks.
0x010000	Supports Shared Search	The client supports shared searching between users.
0x020000	Is Botⁱⁱ	Set by the server if the account has been provisioned by MSN as being a Bot account (and thus have its limitations removed).
0x040000	Supports VoiceIM	The client supports Voice Clips.
0x080000	Supports SChannel	The client allows others to set up a secure channel (via which to send secure messages).
0x100000	Supports SIP Invite	The client supports unknown SIP-based communications.
0x400000	Supports SDrive	The client supports Shared Folders.

Value	Client Version
0x10000000	MSN Messenger 6.0
0x20000000	MSN Messenger 6.1
0x30000000	MSN Messenger 6.2
0x40000000	MSN Messenger 7.0
0x50000000	MSN Messenger 7.5
0x60000000	Windows Live Messenger 8.0
NOTE: If any of the client version values are set, the “P2P Aware” capability (internal) is set. This indicates the client is able to talk via the MSNC protocol.

ⁱ On version 8.0, this flag appears to be inactive.
ⁱⁱ Not new in version 8.0, but unmentioned elsewhere.

3/22/2005

GCF

As with MSN Messenger 7.0 build 0732, it looks like we have a new protocol command in action. After the client sends the SYN command to the server, it sends the command GCF to the server with a request for a certain Xml file. The server at its turn sends back the Xml sheet. As for now, it's only being used with the Shield.xml file. That file affects a range of clients, which probably need to block a certain feature of the application in the future.

Currently it looks like this:
OUT: GCF <TrID> Shields.xml\r\n
IN: GCF <TrID> Shields.xml 117\r\n<?xml version="1.0" ?>\n<config>\n <shield>\n <cli maj="7" min="0" minbld="0" maxbld="9999" />\n </shield>\n</config>

9:31 AM | Add a comment | Permalink | Blog it | Live Messenger - Protocol

3/3/2005

Offline IM

Okay, so it seems we are going to get an update in MSN Messenger 7 with Offline IM. The options which were disabled by default are now enabled by default. Though it seems that offline IM isn't working yet, we are going to get closer to it. It is from now on also possible to add a contact to your list by providing his or her mobile phone number. To do this you need to send this to the server:

ADC 14 FL N=tel:+311234567 F=Test

The country code which you can choose from the list is in this case 31 and 1234567 is the number of the phone I entered. The F= parameter is optional and shows the display name. I also noticed that the SYN command might have been changed on MSNP11. If you send the two date/time stamps to the server which you might have received before and they match, you aren't getting the full list anymore. If it doesn't match with the one the server has, you are getting the full list again.

It also seems that the offline banner is now working again in MSN Messenger 7.0.0604 and you are able to add a mobile number to a contact. See screenshot.