Protocols/MSNP/Scenarios/WebTV - Revision history

Animadoria: Remove speculation (ugh)

2023-03-26T19:43:23Z

Remove speculation (ugh)

← Older revision		Revision as of 19:43, 26 March 2023
Line 2:		Line 2:
	= Authentication =		= Authentication =

	On all verified MSNP versions supported by WebTV/MSNTV on receiving a server-side subsequent <code>USR</code> (<code>USR MD5 S</code> or <code>USR TWN S</code>), instead of calculating the response locally, WebTV/MSNTV clients delegate the hashing to a WTVP (WebTV Protocol) service on <code>wtv-passport:/messengerlogin</code> where it sends the challenge (<code>wtv-passport:/messengerlogin?challenge</code>). 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~~.		On all verified MSNP versions supported by WebTV/MSNTV on receiving a server-side subsequent <code>USR</code> (<code>USR MD5 S</code> or <code>USR TWN S</code>), instead of calculating the response locally, WebTV/MSNTV clients delegate the hashing to a WTVP (WebTV Protocol) service on <code>wtv-passport:/messengerlogin</code> where it sends the challenge (<code>wtv-passport:/messengerlogin?challenge</code>). 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).

	<span id="identification"></span>		<span id="identification"></span>

Animadoria at 09:26, 28 October 2022

2022-10-28T09:26:39Z

← Older revision		Revision as of 09:26, 28 October 2022
Line 2:		Line 2:
	= Authentication =		= Authentication =

	~~For~~ MSNP versions ~~< 8,~~ on receiving a server-side subsequent <code>USR</code> (<code>USR MD5 S</code>), instead of ~~hashing~~ the ~~password~~ locally, WebTV/MSNTV clients delegate the hashing to a WTVP (WebTV Protocol) service on <code>wtv-passport:/messengerlogin</code> where it sends the ~~MD5~~ challenge (<code>wtv-passport:/messengerlogin?challenge</code>). 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.		On all verified MSNP versions supported by WebTV/MSNTV on receiving a server-side subsequent <code>USR</code> (<code>USR MD5 S</code> or <code>USR TWN S</code>), instead of calculating the response locally, WebTV/MSNTV clients delegate the hashing to a WTVP (WebTV Protocol) service on <code>wtv-passport:/messengerlogin</code> where it sends the challenge (<code>wtv-passport:/messengerlogin?challenge</code>). 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.

	~~The same <code>wtv-passport</code> service is used for MSNP8 connections as well, but is assumed to accept and return different data, and we have yet to get information on how that works.~~

	~~''TODO: Logs of request and responses of official <code>wtv-passport</code> service.''~~

	<span id="identification"></span>		<span id="identification"></span>

Animadoria at 20:39, 8 July 2022

2022-07-08T20:39:45Z

← Older revision		Revision as of 20:39, 8 July 2022
Line 2:		Line 2:
	= Authentication =		= Authentication =

	For MSNP versions < 8, on receiving a server-side subsequent <code>USR</code> (<code>USR MD5 S</code>), instead of hashing the password locally, WebTV/MSNTV clients delegate the hashing to a WTVP (WebTV Protocol) service on <code>wtv-passport:/messengerlogin</code> where it sends the MD5 challenge ~~and email~~ (~~split into the username and domain parts~~). 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.		For MSNP versions < 8, on receiving a server-side subsequent <code>USR</code> (<code>USR MD5 S</code>), instead of hashing the password locally, WebTV/MSNTV clients delegate the hashing to a WTVP (WebTV Protocol) service on <code>wtv-passport:/messengerlogin</code> where it sends the MD5 challenge (<code>wtv-passport:/messengerlogin?challenge</code>). 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.

	The same <code>wtv-passport</code> service is used for MSNP8 connections as well, but is assumed to accept and return different data, and we have yet to get information on how that works.		The same <code>wtv-passport</code> service is used for MSNP8 connections as well, but is assumed to accept and return different data, and we have yet to get information on how that works.

Animadoria at 14:43, 6 July 2022

2022-07-06T14:43:36Z

← Older revision		Revision as of 14:43, 6 July 2022
Line 1:		Line 1:
	~~<span id="authentication"><~~/~~span>~~		{{Protocols/MSNP}}
	= Authentication =		= Authentication =

Animadoria at 14:42, 6 July 2022

2022-07-06T14:42:44Z

← Older revision		Revision as of 14:42, 6 July 2022
Line 1:		Line 1:
	~~Convert from markdown, plus archived URLs largely moved:~~		<span id="authentication"></span>
			= Authentication =

	<~~pre~~>		For MSNP versions < 8, on receiving a server-side subsequent <code>USR</code> (<code>USR MD5 S</code>), instead of hashing the password locally, WebTV/MSNTV clients delegate the hashing to a WTVP (WebTV Protocol) service on <code>wtv-passport:/messengerlogin</code> where it sends the MD5 challenge and email (split into the username and domain parts). 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.
	Due to the ~~current lack~~ of ~~sufficient sources for~~ WebTV ~~info pertaining~~ to ~~Messenger, this page won't~~ be ~~updated for some time~~.

	~~# Authentication~~		The same <code>wtv-passport</code> service is used for MSNP8 connections as well, but is assumed to accept and return different data, and we have yet to get information on how that works.

	~~For MSNP versions~~ < ~~8, on receiving a server-side subsequent `USR` (`USR MD5 S`), instead of hashing the password locally, WebTV/MSNTV clients delegate the hashing to a WTVP (WebTV Protocol) service on `~~wtv-passport:/~~messengerlogin` where it sends the MD5 challenge and email (split into the username and domain parts). 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.~~		''TODO: Logs of request and responses of official <code>wtv-passport</code> service.''

	~~The same `wtv-passport` service is used for MSNP8 connections as well, but is assumed to accept and return different data, and we have yet to get information on how that works.~~		<span id="identification"></span>
			= Identification =

	TODO: Logs of request and responses of official `wtv-passport` service.		On real hardware, it’s been observed that WebTV build 2.8 (MSN TV) sends a <code>CVR</code> after logging in:

	~~# Identification~~		<pre>CVR (TrID) 0x0409 webtv 2.8 MIPS msntvim 2.8 msntv</pre>
			It identifies the client as <code>msntv</code> version 2.8, and the OS as <code>webtv</code> with the same version. It also identifies the running architecture as MIPS, with the client library being identified as <code>msntvim</code>. 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 <code>CVR</code>s but the reason for this is unknown.

	~~On real hardware, it's been observed that~~ WebTV ~~build 2.8 (MSN TV) sends a `CVR` after logging in:~~		<span id="webtvmsntv-first-commands"></span>
			= WebTV/MSNTV-first commands =

	~~```~~		<span id="ims"></span>
	~~CVR (TrID) 0x0409 webtv 2.8 MIPS msntvim 2.8 msntv~~		== <code>IMS</code> ==
	~~```~~

	~~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 `CVR`s but the reason for this is unknown~~.		<code>IMS</code> 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 [http://web.archive.org/web/20070609031946/http://msnpiki.msnfanatic.com/index.php/MSNP8:Miscellaneous#Disabling_Instant_Messaging archives] of [http://web.archive.org/web/20100817050916/http://msnpiki.msnfanatic.com/index.php/Command:IMS MSNPiki] (along with an [http://web.archive.org/web/20080423201511/http://msnpiki.msnfanatic.com/index.php/Command:IMS earlier archive] of the individual page on it that erroneously refers to it as <code>ILM</code> in the title, initially written by “Leadpumper”; the correction was added in by “BiM”), with the first [http://web.archive.org/web/20070218124123/http://msnpiki.msnfanatic.com/index.php?title=MSNP8:Miscellaneous&action=history mention] being written by a user named “MrData” around February 2006.

	# WebTV~~/MSNTV-first commands~~		<code>IMS</code> toggles whether a user can send <code>XFR</code>s for switchboards and receive <code>RNG</code>s 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`~~

	`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](http:~~//~~web.archive.org/web/20070609031946/http://msnpiki.msnfanatic.com/index.php/MSNP8:Miscellaneous#Disabling_Instant_Messaging)~~ of ~~[MSNPiki]~~(~~http:~~//~~web.archive.org/web/20100817050916/http://msnpiki.msnfanatic.com/index.php/Command:IMS~~) ~~(along with an [earlier archive](http://web.archive.org/web/20080423201511/http://msnpiki.msnfanatic.com/index~~.~~php/Command~~:~~IMS) 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](http:/~~/~~web~~.~~archive.org/web/20070218124123/http://msnpiki.msnfanatic.com/index.php?title=MSNP8~~:~~Miscellaneous&action=history) being written by a user named "MrData" around February 2006.~~		<code>IMS</code> only requires two parameters: the TrID, and a value of either <code>ON</code> or <code>OFF</code>, corresponding to the ability of whether the user can create switchboards and be invited to them (<code>ON</code> for yes, <code>OFF</code> for no). The response contains three parameters: the TrID, a number which has only been observed as <code>0</code> 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` toggles whether a user can send `XFR`s for switchboards and receive `RNG`s 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.		<pre>>>> IMS (TrID) ON
			<<< IMS (TrID) 0 ON</pre>
	`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:		The behavior that results from a user setting <code>IMS</code> to <code>OFF</code> has so far been undocumented completely, but we assume that <code>XFR</code>s are simply ignored and <code>RNG</code>s aren’t sent to the user at all (with normal errors being sent to inviters).

	~~```~~
	>>> 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 `XFR`s are simply ignored and `RNG`s ~~aren't~~ sent to the user at all (with normal errors being sent to inviters).

	~~---~~

	~~This is all the info we have so far on MSNP on WebTV/MSNTV. We will update this page when we get more information.~~
	~~</pre>~~

AD: Created page with "Convert from markdown, plus archived URLs largely moved:

 **Due to the current lack of sufficient sources for WebTV info pertaining to Messenger, this page won't be upda..."

2021-03-13T13:44:09Z

Created page with "Convert from markdown, plus archived URLs largely moved: <pre> **Due to the current lack of sufficient sources for WebTV info pertaining to Messenger, this page won't be upda..."

New page

Convert from markdown, plus archived URLs largely moved:

<pre>
**Due to the current lack of sufficient sources for WebTV info pertaining to Messenger, this page won't be updated for some time.**

# Authentication

For MSNP versions < 8, on receiving a server-side subsequent `USR` (`USR MD5 S`), instead of hashing the password locally, WebTV/MSNTV clients delegate the hashing to a WTVP (WebTV Protocol) service on `wtv-passport:/messengerlogin` where it sends the MD5 challenge and email (split into the username and domain parts). 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.

The same `wtv-passport` service is used for MSNP8 connections as well, but is assumed to accept and return different data, and we have yet to get information on how that works.

*TODO: Logs of request and responses of official `wtv-passport` service.*

# 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 `CVR`s 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](http://web.archive.org/web/20070609031946/http://msnpiki.msnfanatic.com/index.php/MSNP8:Miscellaneous#Disabling_Instant_Messaging) of [MSNPiki](http://web.archive.org/web/20100817050916/http://msnpiki.msnfanatic.com/index.php/Command:IMS) (along with an [earlier archive](http://web.archive.org/web/20080423201511/http://msnpiki.msnfanatic.com/index.php/Command:IMS) 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](http://web.archive.org/web/20070218124123/http://msnpiki.msnfanatic.com/index.php?title=MSNP8:Miscellaneous&action=history) being written by a user named "MrData" around February 2006.

`IMS` toggles whether a user can send `XFR`s for switchboards and receive `RNG`s 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 `XFR`s are simply ignored and `RNG`s aren't sent to the user at all (with normal errors being sent to inviters).

---

This is all the info we have so far on MSNP on WebTV/MSNTV. We will update this page when we get more information.
</pre>