Since March 10, 2003 - Version 2
hypothetic.org

MSN Messenger Protocol

Home Page

Forum
Chat

About

Resources

Research

Documentation
 General
 Notification
 Switchboard
 Protocols
 Reference

Validate XHTML
Validate CSS
Research - Client ID structure
Printable Version

Overview

Starting with MSNP8, a new value is included with ILN, NLN, and CHG messages. We still don't understand some of the exact details about this value, but it seems to be some kind of client ID structure. This page documents what we know so far and some of the theories that have been rejected. The main discussion of this topic is going on in thread 5153.

Note: Understanding the client ID structure requires some knowledge of binary. Since this structure is still somewhat under active research, the binary and hexadecimal representation is discussed in places. If you just want to implement the thing, skip the discussion.

Here is an example MSNP8 NLN message:

NLN 96 NLN example@passport.com example%20friendlyname 268435492

Here, "268435492" is the client ID structure. Although it is transmitted as a single decimal number, it represents a structure made up of four sections. Each section is one byte in length, so you can't make them out by looking at the decimal number. If you convert the number to hexadecimal, the sections are much easier to spot - for example, "268435492" is "0x10000024" in hexadecimal. The values of the sections are "0x10", "0x00", "0x00", and "0x24" respectively.

The first section is believed to represent the client version, the next two sections seem to be reserved for future use, and the final section advertises some of the capabilities of the client.

Client version section

The value of this byte is hardcoded into the official client, and seems to be increased in every version of MSN Messenger, but not in Windows Messenger. Our working hypothesis is that this is some kind of client version information, from which clients can deduce things like the type of file transfer the client supports.

You can extract the client version from the client ID by "modulo dividing" the client ID number by 16777216 (that is, dividing it then throwing away the remainder). Here is a list of client versions we've observed (the numbers in brackets are the version numbers in hexadecimal):

0 (0x00)
MSN Messenger version 5 and all versions of Windows Messenger use this value for their client version. Clients using this value are assumed to support old-style file transfer but not the new P2P file transfer mechanism. For some reason, MSN Messenger version 6 still (falsely) assumes that they support other P2P features like custom emoticons.
16 (0x10)
MSN Messenger version 6.0 uses this value for its client version. Clients using this value are assumed to support new-style file transfer.
32 (0x20)
MSN Messenger version 6.1 uses this value for its client version. Clients using this value are assumed to support new-style file transfer.

Capabilities section

Every single bit in this section has its own meaning - in other words, this section is a "bitfield". Unlike the client version section, the value of this section can change whenever the client sends a new status message - for example, the official client may advertise support for video conversations whenever a webcam is plugged into the machine it's on.

You can extract individual capabilities from the client ID by bitwise ANDing the client ID with the value of the capability. If the result is zero, the client doesn't support the capability at present, otherwise the client does support the capability. Here is a list of capabilities, and what we know about them (the numbers in brackets are the version numbers in hexadecimal):

1 (0x01)
Setting this bit means the client is running on a Windows Mobile device, such as a smartphone or Pocket PC. The official client changes the icon of a buddy with this bit set from a little man to a little man with a phone, and puts "(phone)" next to their name.
2 (0x02)
We don't know what this bit means, but the official client sometimes sets it when resetting its capabilities
4 (0x04)
The client is capable of viewing "ink" messages (see below).
8 (0x08)
The client is capable of viewing and creating "ink" messages (see below)
16 (0x10)
The client can participate in video conversations. The official client only sets this when you have a webcam connected and have chosen to share your webcam with others
32 (0x20)
We don't yet know what this means, but the official client always sets this bit (it's hardcoded into the client), so it must be something that can't be turned off.
64 (0x40)
Unknown (but definitely used by the official client)
128 (0x80)
Unknown (but definitely used by the official client)

What is "Ink"?

"Ink" is a technology from Microsoft that allows you to handwrite on a screen. It's available in tablet PCs, recent versions of Microsoft's Platform SDK, and in Microsoft's next version of Windows code-named "Longhorn".

A developer who worked on putting ink functionality into MSN Messenger has a page talking about his work.

What we know isn't represented

Nothing in this structure represents the native language of the MSN Messenger client, the OS version or the native OS language.

Installing Messenger Plus does not alter the structure in any way.

Build numbers of clients (e.g. the 0602 in version 6.0.0602) are not represented.

Enabling emoticons, custom emoticons, "show my display picture", and "show display picture from others in instant message conversations" have no effect on the bitmask.

Enabling the auto-idle and auto-busy features has no effect.

P2P support isn't directly represented. The official client uses the version number to guess at whether P2P file transfer is supported, but not whether other P2p things like custom emoticons are supported.

Copyright ©2002-2003 to Mike Mintz.