Services/Technical/Messenger

Somewhere down the road, it was decided WebTV should have a Messenger feature. This feature was added in by the 2.5 client upgrade and lasted well into the MSNTV 2's lifespan.

Basic

WebTV/MSN TV's Messenger feature relies on another Microsoft service, the MSN Messenger service (also known as .NET Messenger Service or the Windows Live Messenger service), to operate, and it's assumed a corresponding Microsoft Passport (now Microsoft account) would have to be linked to a WebTV/MSN TV account for the feature to work. For first-generation WebTV/MSN TV, once a user successfully logs in through the headwaiter, the server will send to the box alongside all its account and configuration information: a hostname for the Messenger protocol server the box will connect to, flag values determining if the feature is authorized or enabled for the subscriber/user, the service URL to perform Messenger authentication on through WTVP (this will be covered on later), and several timeout flags that supposedly control how long the Messenger client should wait in certain scenarios.

The Messenger client on first-gen WebTV/MSN TV is mostly built into the firmware, and is very primitive. It allows a user to see whether their contacts are online or offline (FYI statuses such as Away, Busy, etc. that are supported by the underlying MSN Messenger service are translated by the client as an online status), send and receive plain text messages (first-gen WebTV/MSN TV's client doesn't support graphical emoticons, although MSNTV 2's did), manage availability and block list options through the settings on the WebTV/MSN TV service, manage their contact list through their e-mail address book, and receive notifications when people add them.

Images

Original WebTV/MSN TV

Messenger conversation window (screenshot taken from third-party server)

Notification from Messenger being shown in the title area (screenshot taken from third-party server)

MSNTV 2

Messenger contact list

Messenger contact list (empty)

Messenger conversation window

"Add a contact" window for Messenger

Protocols

Client

The Messenger client on WebTV/MSN TV uses the MSNP protocol to communicate with the Messenger protocol server, which operates over TCP port 1863. This protocol is out of this wiki's scope and unlike WebTV/MSN TV's protocols has a fair amount of documentation floating around on the internet, and we won't go into too much depth on it here. You can read more up on it here, here (MSNP8 - 10), here (MSNP2), and here (MSNP7).

Protocol support

What is currently known about protocol support is that version 2.5 of the WebTV Viewer supports version 3 of the MSNP protocol if you configure a SOCKS proxy on the Viewer to allow connections outside of the WebTV/MSN TV network, and firmware version 2.8 supports version 6 of the protocol. It's known the latest version of MSNP the first generation of WebTV/MSN TV supported is MSNP8.

Identification

So far, it's confirmed that firmware version 2.8 of WebTV (MSN TV) sends a CVR command on the Messenger protocol server after logging in:

CVR (TrID) 0x0409 webtv 2.8 MIPS msntvim 2.8 msntv

To quickly explain what this command does, it identifies the client logging into the Messenger service. In this case, the client is identified as "msntv" with a version of "2.8". The OS is identified as "webtv" with the same version. Other things sent for identification are the architecture, which in this case is "MIPS", and the client library, which is msntvim. We don't know yet if builds before 2.8 send this on real hardware, although it's known that the 2.5 version of the WebTV Viewer doesn't send any CVRs for unknown reasons.

WebTV/MSN TV-first commands

So far, the only MSNP command recorded to only be used on WebTV/MSN TV clients is IMS, and has been covered on to some degree years ago.

Supposedly this is triggered after a certain amount of idle time, but what the value of this time is or where it's obtained from is not known currently. The exact behavior of IMS being set to "OFF" aside from it blocking new conversations initiated by others is also unknown.

WTVP

Login

During the WebTV/MSN TV box's connection to the Messenger protocol server, it will receive a USR S command after sending the Passport email associated with the WebTV/MSN TV account to the server. This USR S response contains a challenge string. On version 8 of MSNP, this is a URL-encoded and comma delimited list of key-value parameters (e.g., lc=1033,id=507,tw=40,fs=1,ru=http%3A%2F%2Fmessenger%2Emsn%2Ecom,ct=1062764229,kpp=1,kv=5,ver=2.1.0173.1,tpf=43f8a4c8ed940c04e3740be46c4d1619), and on versions below that, it is a decimal value (e.g., "1013928519.693957190"), but technically it can be any value, at least for <= MSNP7. Whatever the challenge value is, this is passed over to a wtv-passport service located at "wtv-passport:/messengerlogin".

MSNP3-7

After receiving the challenge string from the protocol server, a SECURE'd GET request is sent to "wtv-passport:/messengerlogin?[CHALLENGE]", [CHALLENGE] being the aforementioned challenge string. The GET request alone does not appear to send any other headers identifying the WebTV/MSN TV user logging in, so it's assumed that authorization headers sent by a SECURE request (such as wtv-ticket) gives the messengerlogin service the necessary information about the WebTV/MSN TV user to authorize the request. In this case, if the user's request is authorized and they have a Passport account linked to their WebTV/MSN TV account, an MD5 hash of the challenge string concatenated with their Passport password is sent in hexadecimal format in a 200 OK response:

200 OK\n
Connection: Keep-Alive\n
wtv-encrypted: true\n
Expires: Wed, 09 Oct 1991 22:00:00 GMT\n
Content-Type: text/plain\n
Content-length: 32\n
wtv-lzpf: 0\n
\n
[encrypted and compressed MD5 hex response]

The MD5 response, when decrypted and decompressed from the WTVP response, is then sent to the protocol server and further authentication is handled there.

In the event anything goes wrong (e.g., no Passport linked to WebTV/MSN TV account), it's been observed that a generic 500 error is sent:

500 MSN TV ran into a technical problem. Please try again.\n
Connection: Keep-Alive\n
wtv-encrypted: true\n
\n

MSNP8

Once messengerlogin gets the challenge string, the first thing It'll do is request "messenger.msn.com/rdr/pprdr.asp" to get the URL used for actual authentication. The URL is in the "passporturls" header, under "DALogin". Once it has this URL, It'll send a request to the URL with an "Authorization" header that contains info about the user logging in. This header looks a little something like this:

"Authorization": "Passport1.4 OrgVerb=GET,OrgURL=http%3A%2F%2Fmessenger%2Emsn%2Ecom,sign-in=anemail@email.com,pwd=supersecurepassword,lc=1033,id=507,tw=40,fs=1,ru=http%3A%2F%2Fmessenger%2Emsn%2Ecom,ct=1062764229,kpp=1,kv=5,ver=2.1.0173.1,tpf=43f8a4c8ed940c04e3740be46c4d1619"

If authentication succeeds, the MSN Messenger service will send a 200 OK response with an "authentication-info" header. This header contains "from-PP", which is the token the client wants.

After that, the server will send the token in the data of the messengerlogin response, which will look something like this:

200 OK\n
Connection: Keep-Alive\n
wtv-encrypted: true\n
Expires: Wed, 09 Oct 1991 22:00:00 GMT\n
Content-Type: text/plain\n
Content-length: [Token length]\n
wtv-lzpf: 0\n
\n
[Token from MSN Messenger]

From there, the client will continue authenticating with MSN Messenger by itself.