Protocols/MSNP/MSNC/MSN Object

This section tries to explain what the MSN Object is, what it is being used for and how to create your own MSN Object. The MSN Object was introduced in MSN Messenger 6.0 and has since then been expanded to meet new features of newer client versions. The reason why it was introduced was to identify Backgrounds, Custom Emoticons, (Dynamic) Display Pictures and Winks (introduced in MSN Messenger 7.0).

In this section we will use the data of the following example to discuss how it has to be made. As you can see the MSN Object is just a custom XML tag.

Example 1

A typical MSN Object:

The MSN Object always consists of the following fields:

Creator

The Creator field contains the e-mail address of the person who uses (or sends) the file.
Size

The Size field contains the size of the file in bytes.
Type

The Type field indicates the type of the file. If the value of the field is 2 we are dealing with a Custom Emoticon, when it's 3 a Display Picture, 5 for a Background image, 7 for a Dynamic Display Picture and 8 for an Wink. The meaning of 1, 4 and 6 is still unknown.
Location

The Location field contains the name of the file under which it is stored on the creators computer.
Friendly

The Friendly field can contain a friendly name for the file in Unicode format and is encoded with Base64. At the moment it is only being used with background images, Winks and display pictures which you can buy and download.
SHA1D

The SHA1D field contains the SHA-1 hash from the data of the file which is later encoded with Base64. This value can be used to check if the file sent has been received without errors and that it is the file you expected. This field can also be called the SHA-1 Data field.
SHA1C

The SHA1C field contains the SHA-1 hash of all the previous fields and is later encoded with Base64 as well. Though be aware that not everything is being used, only the names and values. You have to append the field value to the field name and the next pair to that one, demonstrated in the following example. This field can also be called the SHA-1 Checksum field.

Example 2

Input for the SHA-1 hash for the given MSN Object:

Creatorbuddy1@hotmail.comSize24539Type3LocationTFR2C.tmpFriendlyAAA=SHA1DtrC8SlFx2sWQxZMIBAWSEnXc8oQ=

Downloadable content

As with MSN Messenger 7.0 not only were Winks added, but downloadable content as well. This allows you to buy backgrounds, (dynamic) display pictures or emoticons and then download it directly to your computer. However, if you have paid for it, your contact can't add the emoticon to his own list. This is the result of some minor adjustments of the MSN Object.

Therefore, the following fields has been added:

contenttype

The contenttype field indicates what type of content the file is. If it's free to download the value is D, but if you need to pay for it, the value is P. If the value is P, it will prevent the official client from adding it to the other users list.
contentid

The contentid field contains the identifier of the item which the Content Partner gave it.
partnerid

The partnerid field contains the name of the Content Partner. American Greetings/Blue Mountain for example, is identified by AG. This field applies only for Custom Emoticons. But if this field is not present in the Content XML file when it was downloaded, the value of this field is -1.
stamp

The stamp field contains the Base64 encoded signature of the file. It is a S/MIME signature of the Base64 encoded hash of the Content cabinet file and is signed by the MSN Content Authority. The stamp field is used in the Content XML file to make sure that the file isn't modified. Currently, it's only being included in the MSN Object for dynamic (Flash) contents like Winks and Dynamic Display Pictures.

Note that all extra fields are NEVER part of the data which is used to create the SHA-1 Checksum.

Example 3

A typical MSN Object for a Wink (note that the stamp is truncated):

Dynamic display pictures

Dynamic display pictures in MSN Messenger 7.0 consists of two files, a so-called "downlevel" image and the flash file. The reason why downlevel image is being used is that if a client doesn't support a dynamic display picture, it still can view a display picture. But if the client does support it, it should use the value of the avatarcontentid field from the "downlevel" MSN Object to get the MSN Object for the Dynamic Display Picture.

The extra fields for the "downlevel" MSN Object are:

avatarid

The avatarid field indicates what type of avatar is being referenced to. This field is currently only being seen with {6AD16E96-BC60-401B-89E2-5BB545DD2BF0} as value and is probably being used as a reference to the Shockwave Flash player. The Base64 encoded variant of this value is being sent as Context parameter if a client wants to receive the Shockwave Player XML object with the MSN Object for the dynamic display picture in it.
avatarcontentid

The avatarcontentid field contains the SHA-1 hash of the cabinet file which contains the content and is later encoded with Base64 as well.

Example 4

A typical "downlevel" MSN Object for a Dynamic Display Picture:

Example 5

A typical MSN Object for a Dynamic Display Picture (note that the stamp is truncated):

Protocols/MSNP/MSNC/MSN Object

Navigation menu

Search