Protocols/MSNP/Scenarios/WebTV
| MSNP Protocol |
| Introduction • Terms • Clients |
| Reference |
| Error List • Commands • Relying Party Suite • Spotlife |
| Services |
| XMPP • HTTP Gateway • Tabs • Activities |
| Documentation |
| Development Tools • MSNP Grid |
| Polygamy • URLs used by MSN |
| Documents |
| Protocol Versions |
| Version 21 |
| Version 18 |
| Version 16 |
| Version 15 |
| Version 14 |
| Version 13 |
| Version 12 |
| Version 11 |
| Version 9 |
| Version 8 |
| Version 2 |
| MSNC |
| Introduction • P2P • Object Descriptor • Display Pictures • File Transfer |
| Scenarios |
| Microsoft Messenger for Mac |
| MSNP on WebTV (MSNTV) |
Authentication
On all verified MSNP versions supported by WebTV/MSNTV on receiving a server-side subsequent USR (USR MD5 S or USR TWN S), instead of calculating the response locally, WebTV/MSNTV clients delegate the hashing to a WTVP (WebTV Protocol) service on wtv-passport:/messengerlogin where it sends the challenge (wtv-passport:/messengerlogin?challenge). The service then returns the challenge response on a successful lookup of the email being a valid Microsoft account (note that WebTV/MSNTV subscriber accounts and Microsoft accounts/Passports were separate from each other). The fact the service does not send the password at all in the request hints that passwords were assumed to be stored in cleartext and were retrieved from Microsoft’s databases as such.
Identification
On real hardware, it’s been observed that WebTV build 2.8 (MSN TV) sends a CVR after logging in:
CVR (TrID) 0x0409 webtv 2.8 MIPS msntvim 2.8 msntv
It identifies the client as msntv version 2.8, and the OS as webtv with the same version. It also identifies the running architecture as MIPS, with the client library being identified as msntvim. We’ve yet to determine if older builds (2.5 - 2.7) send this on real hardware as well. It’s been known that the 2.5 version of the WebTV Viewer doesn’t send any CVRs but the reason for this is unknown.
WebTV/MSNTV-first commands
IMS
IMS is a WebTV/MSNTV-first MSNP command with little documentation on its resulting behavior. So far it’s been determined that it was introduced by MSNP3, and the only (surviving) mentions of it reside in archives of MSNPiki (along with an earlier archive of the individual page on it that erroneously refers to it as ILM in the title, initially written by “Leadpumper”; the correction was added in by “BiM”), with the first mention being written by a user named “MrData” around February 2006.
IMS toggles whether a user can send XFRs for switchboards and receive RNGs or not. Its inferred usage is when a WebTV user doesn’t want to be pestered by any users wanting to message them, although we’ve only seen this command being triggered by WebTV Viewer 2.5 after an undetermined amount of idle time. The desktop MSN Messenger clients on the other hand don’t even mention the command in the binary strings.
IMS only requires two parameters: the TrID, and a value of either ON or OFF, corresponding to the ability of whether the user can create switchboards and be invited to them (ON for yes, OFF for no). The response contains three parameters: the TrID, a number which has only been observed as 0 for the time being (this can possibly be another flag), and the value the user specified for turning on/off switchboard usage. An example of the request and corresponding response is shown below:
>>> IMS (TrID) ON <<< IMS (TrID) 0 ON
The behavior that results from a user setting IMS to OFF has so far been undocumented completely, but we assume that XFRs are simply ignored and RNGs aren’t sent to the user at all (with normal errors being sent to inviters).