WTVP/Processes/Headwaiter

Registered WebTV/MSN TV clients logging in in any scenario contact the headwaiter service.

Initial Login

To start the login process, a client connects to the available headwaiter server(s) it has defined in its service list, and sends a WTVP GET request to "wtv-head-waiter:/login":

GET wtv-head-waiter:/login?\r\n
Referer: file://rom/HTMLs/SonyLogo.html\r\n
wtv-request-type: primary\r\n
wtv-system-cpuspeed: 166164662\r\n
wtv-system-sysconfig: 3116068\r\n
wtv-disk-size: 8006\r\n
wtv-incarnation: 4\r\n
wtv-client-address: 0.0.0.0\r\n
Accept-Language: en\r\n
wtv-connect-session-id: cafa1349\r\n
wtv-client-serial-number: {SSID}\r\n
wtv-system-version: 16276\r\n
wtv-capability-flags: {capability-flags}\r\n
wtv-client-bootrom-version: 2046\r\n
wtv-client-rom-type: US-LC2-disk-0MB-8MB\r\n
wtv-system-chipversion: 53608448\r\n
User-Agent: Mozilla/4.0 WebTV/2.8.2 (compatible; MSIE 4.0)\r\n
wtv-encryption: true\r\n
wtv-script-id: 184867725\r\n
wtv-script-mod: 1579644943\r\n
\r\n

The server responds with a 200 OK, adding a wtv-log service entry to the client, setting wtv-visit to "wtv-head-waiter:/login-stage-two", and most importantly, sending the wtv-challenge header, and thereby starting the challenge/response process.

(NOTE: It is assumed that the wtv-challenge contains specific data structured in it, and the one shown in the following example is from a third party private server (no longer available to the public) that might not be totally accurate to the original implementation. If you want to look at one sent from official servers, go here)

200 OK\n
Connection: Keep-Alive\n
Expires: Wed, 09 Oct 1991 22:00:00 GMT\n
wtv-expire-all: wtv-head-waiter:\n
wtv-service: name=wtv-log host=xxx.xxx.xxx.xxx port=1609 connections=1\n
wtv-log-url: wtv-log:/log\n
wtv-challenge: FI/nEB3hWDmHvW/QHcGbskOvcr70YoF39d3llvk2wouGDmVybY1Q0cd30tt8kGagRskcMnGhBUOzt9kI6DQUoK/XNEaT08WOcUdyRDxLxeSqog71A3U1Z8usS/X0XeQ/NlZHIjllGaOQ6eGDe0YgaA==\n
wtv-relogin-url: wtv-head-waiter:/login?relogin=true\n
wtv-reconnect-url: wtv-head-waiter:/reconnect\n
wtv-visit: wtv-head-waiter:/login-stage-two-wtv-token-XXXXXXXXXX-YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY?\n
Content-length: 0\n
Content-type: text/html\n
\n

Challenge/Response

To get past initial login, the WebTV/MSN TV client now has to perform the challenge/response process, which will result in a generated challenge response that will be sent to the headwaiter to validate the client's session. During this process, the client will also obtain two 128-bit RC4 session keys used for protocol encryption along with a copy of the wtv-initial-key embedded in the challenge data, which is swapped in in the middle of an ongoing challenge/response, but otherwise doesn't have a clear purpose.

The data sent in the wtv-challenge header from the last request contains a structured blob when Base64-decoded, which contains the following data:

Field Name	Length	Description
???	8 bytes	Unknown purpose. Appears to be randomly generated on each challenge generated by the headwaiter. Need more documentation on this. This is also sent in the challenge response.
Encrypted challenge	Variable length	DES-ECB encrypted data containing actual challenge information.

The data following the initial 8 bytes carried in this structure is encrypted with DES-ECB, using the last wtv-initial-key stored on the service for the connecting client's SSID as the encryption key. This challenge/response model assumes the client has the same wtv-initial-key given by the service when it connected through the pre-registration servers, which makes it so the server is not required to send it again for login requests. When the encrypted data is decrypted, another data structure is exposed:

Field Name	Length	Description
Challenge data	40 bytes	Randomly generated data to be sent back in the challenge response. Not sure if it has some structure or if it's entirely random.
RC4 session key #1	16 bytes	Session key to be used for encrypting SECURE messages. Used for encrypted client -> server messages.
RC4 session key #2	16 bytes	Session key to be used for encrypting SECURE messages. Used for encrypted server -> client messages.
Initial key	8 bytes	The wtv-initial-key used for the challenge/response process. The one sent in challenges is usually the same one the client obtains during the pre-registration process and doesn't appear to change often between challenge/responses. It's believed that it can change under unknown criteria, and in that case, the initial key being used by the client must be switched in the middle of the current challenge/response. Whether this carries over into future challenge/responses isn't entirely clear yet. Need more documentation on this.
MD5 checksum	16 bytes	Checksum of preceding data in this structure (Challenge data + session key #1 + session key #2 + initial key).
Padding	Variable length	Extraneous padding, usually of 8 bytes. Pad byte used in official challenges is 0x08, but can technically be any value to our knowledge.

Once the client Base64-decodes the wtv-challenge value sent from the server and successfully decrypts the encrypted portion of the challenge, it'll supposedly validate the specified checksum of the challenge data, session keys, and initial key. If the checksum is valid, the client will then grab the challenge data, two session keys, and initial key. The initial key and session keys are stored in memory (not NVRAM), with the latter in particular being crucial for encrypted communication, while the challenge data will be used for the following steps in the challenge/response procedure:

• Challenge data is MD5-hashed
• MD5 hash of challenge data, the challenge data itself, and 8 bytes of 0x08 pad bytes are concatenated, and then encrypted with DES-ECB, using the current initial key as the encryption key.
• The first 8 bytes from the original wtv-challenge structure and the encrypted result from earlier are then concatenated and Base64-encoded.

---

Once the challenge response is generated, the client sends it back to the server in a wtv-challenge-response header through a GET request to the "login-stage-two" URL mentioned earlier (this is also from a network capture of the third party private server mentioned earlier):

GET wtv-head-waiter:/login-stage-two-wtv-token-XXXXXXXXXX-YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY?\r\n
Referer: wtv-head-waiter:/login?\r\n
wtv-request-type: primary\r\n
wtv-system-cpuspeed: 166164662\r\n
wtv-system-sysconfig: 3116068\r\n
wtv-disk-size: 8006\r\n
wtv-incarnation: 4\r\n
wtv-challenge-response: FI/nEB3hWDmqNsDw+cPzdbEpkgzopq/wh71v0B3Bm7JDr3K+9GKBd/Xd5Zb5NsKLhg5lcm2NUNHHd9LbfJBmoJDp4YN7RiBo\r\n
wtv-client-address: 0.0.0.0\r\n
\r\n

The following will assume that the challenge response is accepted by the headwaiter and no problems arise, as we do not have details on what happens if the response is incorrect.

If the client's SSID doesn't have an account associated with it, the server will send a response with a wtv-ticket, a wtv-service definition for wtv-register, and a wtv-visit header pointing to a wtv-register URL:

200 OK\n
Connection: Keep-Alive\n
wtv-encrypted: true\n
wtv-client-time-zone: PST -0800\n
wtv-client-time-dst-rule: PST\n
wtv-client-date: Tue, 21 Jan 2020 22:15:44 GMT\n
wtv-country: US\n
wtv-language-header: en-US,en\n
wtv-visit: client:closeallpanels\n
wtv-expire-all: client:closeallpanels\n
wtv-ticket: htYnqwym4LB90IoLnTi1UySEZN74mcoKlg7ksr7MNBGAng9kyCIcTEqzCMXHlqYyWKNloHA85K/bpF/RwNiBv0VGJNLIy7/nikNZ16tXxXO1jAqVpHEbjTyt3wMWbo5EbmCxEBSuWoeozSRSGDff3hRDWGM9VxA3HCSVRCQ8f1YCQ...\n
wtv-noback-all: wtv-\n
wtv-service: name=wtv-register host=xxx.xxx.xxx.xxx port=1607\n
wtv-visit: wtv-register:/register-wtv-token-XXXXXXXXXX-YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY?ForceRegistration=true\n
wtv-phone-log-url: wtv-log:/phone-log\n
Content-length: 0\n
Content-type: text/html\n
\n

If the person logging in has an account associated with their SSID but also has a password set on it, a response with the wtv-ticket will still be sent(?) but compressed and encrypted HTML content for what's usually the password screen will be sent in the entity body as well. This means that even on the headwaiter, the client should expect to deal with encrypted data at any point after completing the challenges. The wtv-challenge is also re-sent for some reason (this response was also taken from network traffic on a third-party private server, the accuracy of this compared to official services cannot be determined right now):

200 OK\n
Connection: Keep-Alive\n
wtv-encrypted: true\n
wtv-client-time-zone: PST -0800\n
wtv-client-time-dst-rule: PST\n
wtv-client-date: Sun, 26 Apr 2020 16:48:46 GMT\n
wtv-country: US\n
wtv-language-header: en-US,en\n
wtv-visit: client:closeallpanels\n
wtv-expire-all: client:closeallpanels\n
wtv-offline-user-list: {Base64-encoded XML}\n
wtv-bypass-proxy: false\n
wtv-ticket: ZNtSz87VwvsIkT/vJC0CJgXynUPaRaEQGRfdQo57O128wcccR9WdfxeftLiz1bZMDwUIiBCtXRcbiXiWWWUm8u/DGC/8e54RvrU39pttY80MqoQu+wsPAMcjOw08x7wyhYz1C0JMepjffcszC2GNQi75Db/cpjhc9nYy8...\n
wtv-challenge: D/404AmCRb00IjHBL/6gzqTjuhIvkDdIGCxkz2iUKqs2e6wHS04Aw27unVi0UAKK88Ua1z3HyYNhtnIJSPVfaK3lnxv/VPRYtva3ofHvdqXN6vSGDhDCETeAYnVf8g6vsN2pgjQtbNEfF6YPw+h3Vg==\n
wtv-phone-log-url: wtv-log:/phone-log\n
wtv-lzpf: 0\n
Content-length: xxxx\n
Content-type: text/html\n
\n
{compressed and encrypted HTML data}

Keep in mind that starting from login-stage-two, the wtv-encrypted header has to be present in all responses for headwaiter services regardless of if the box actually supports encryption. This will tell the client to allow pages from headwaiter to load assets (images, etc.) remotely from WebTV/MSN TV servers. If this header isn't present, then the client will refuse to load any page assets that aren't stored in ROM.

(TODO: Cover scenario where client SSID has multiple associated accounts, and possibly has a password on any if present)

Post-Login

If the account the user chooses successfully authenticates through the WebTV/MSN TV service (with/without password), a large response containing basic account info, configuration for certain services, a service list for all supported WTVP services aside from wtv-1800, and more are sent. Because of the large amount of data this contains, examples of this response will be hosted on its own page: WTVP/Processes/Headwaiter/Final Responses. A small note that the final headwaiter response can be sent on either wtv-head-waiter:/login-stage-two, wtv-head-waiter:/ValidateLoginName, or wtv-head-waiter:/VLN-stage-two (circa 2003). This is possibly the result of not requiring too many or too few requests if an account doesn't have extra users or doesn't need a password to log in.

Along with the headwaiter details, the final server response also returns the splash screen page the user will see after a successful login attempt. This page contains a META refresh tag pointing the client to go to the service URL wtv-head-waiter:/check-tellyscript?next-url=wtv-home:/home&dummy={hex}, {hex} being the string "0x" and a random hexadecimal string that has been observed to be up to 8 characters in length. It is unknown what the function of the URL is past sending a response to direct the user to the URL specified in next-url, which in this case is the service URL to the home page (wtv-home:/home):

GET wtv-head-waiter:/check-tellyscript?next-url=wtv-home:/home&dummy=0x5ea5bb82\r\n
User-Agent: Mozilla/4.0 WebTV/2.6 (compatible; MSIE 4.0)\r\n
Referer: xxxxx\r\n
wtv-show-time: 3\r\n
wtv-request-type: primary\r\n
wtv-incarnation: 46\r\n
wtv-client-address: 192.168.1.98\r\n
Accept-Language: en-US,en\r\n
wtv-ticket: {wtv-ticket}\r\n
wtv-connect-session-id: 1499ac58\r\n
wtv-client-serial-number: {SSID}\r\n
wtv-encryption: true\r\n
wtv-capability-flags: {capability-flags}\r\n
wtv-system-version: 16250\r\n
wtv-client-rom-type: US-BPS-flashdisk-0MB-8MB-softmodem-CPU5230\r\n
wtv-client-bootrom-version: 2525\r\n
wtv-system-chipversion: 84017152\r\n
wtv-system-sysconfig: 3133702\r\n
wtv-system-cpuspeed: 147993946\r\n
wtv-disk-size: 3990\r\n
wtv-script-id: 1611862638\r\n
wtv-script-mod: 1587909919\r\n
\r\n

200 OK\n
Connection: Keep-Alive\n
wtv-visit: wtv-home:/home\n
Content-length: 0\n
Content-type: text/html\n
\n

Miscellaneous

These responses have been observed to be sent right after the headwaiter process. Where they originate from is currently unknown, but regardless it is important to catalogue them.

200 OK\n
Connection: Keep-Alive\n
wtv-encrypted: true\n
wtv-spot-queue-add: queue=1&adID=0000001202cbda8500000000&creative=wtv-spot:/shared/ads/ZD/YIL.GIF\n
wtv-videoad-playid: 0000001c02cbda8500000000\n
wtv-videoad-playname: joinus.mpg\n
Content-length: [...]

---

200 OK\n
Connection: Keep-Alive\n
wtv-encrypted: true\n
Content-Type: x-wtv-addresses\n
Content-length: 0\n
\n

---

200 OK\n
Connection: Keep-Alive\n
wtv-encrypted: true\n
wtv-backgroundmusic-clear: no_zits\n
wtv-backgroundmusic-add: wtv-setup:/MusicCache/headspace/RMF/moods/mystical.rmf\n
wtv-backgroundmusic-add: wtv-setup:/MusicCache/headspace/RMF/moods/quietude.rmf\n
wtv-backgroundmusic-add: wtv-setup:/MusicCache/headspace/RMF/mellow/sunlane.rmf\n
wtv-backgroundmusic-add: wtv-setup:/MusicCache/headspace/RMF/ambient/backwaters.rmf\n
wtv-backgroundmusic-add: wtv-setup:/MusicCache/headspace/RMF/ambient/cozy.rmf\n
wtv-backgroundmusic-add: wtv-setup:/MusicCache/headspace/RMF/ambient/personal-twilight.rmf\n
wtv-backgroundmusic-add: wtv-setup:/MusicCache/headspace/RMF/classical/moonlight_sonata.rmf\n
wtv-backgroundmusic-add: wtv-setup:/MusicCache/headspace/RMF/classical/mendelssohn-prelude.rmf\n
wtv-backgroundmusic-add: wtv-setup:/MusicCache/headspace/RMF/classical/mouret-rondeau.rmf\n
wtv-backgroundmusic-add: wtv-setup:/MusicCache/headspace/RMF/classical/la-barriera.rmf\n
wtv-backgroundmusic-add: wtv-setup:/music/classicl/bach/bach_cmaj_prelude.mid\n
wtv-backgroundmusic-add: wtv-setup:/music/classicl/bach/bach_fugue_cmajor.mid\n
wtv-backgroundmusic-add: wtv-setup:/music/classicl/bach/bach_menuet_in_G.mid\n
wtv-backgroundmusic-add: wtv-setup:/music/classicl/bach/bach_violin_partita_in_e.mid\n
wtv-backgroundmusic-add: wtv-setup:/music/newmusic/keyboards/cata_wtv.mid\n
wtv-backgroundmusic-add: wtv-setup:/music/newmusic/keyboards/home_wtv.mid\n
wtv-backgroundmusic-add: [...]

Diagram

Notes

If the client logs in after finishing registration or performs a relogin, then the first login URL will be requested with either "?new_registration=1" or "?relogin=true" respectively appended to it. This applies to any further login URLs the client is pointed to during this process (excluding ValidateLogin possibly). The purpose of these query parameters being passed through the URLs is unknown right now.