Well thanks. I mostly wrote this at a dev’s perspective. So let me break it up:
For NotRST.srf/RST.srf:
- Get the necessary data (Email, password)
- Create a RST request server-side with the email, password, and policy the Escargot server sent to the client (the policy is something like this: if Escargot sent “?MBI_KEY_OLD=<nonce>” to a client, it uses the same policy when creating the RST request). If you somehow get the original MSIDCRL to work with Escargot’s RST url, just retrieve the request (SOAP).
- Setup a connection to the actual RST.srf (login.live.com/RST.srf) as a gateway.
- Send the data you had just created, regardless of whether it is correct for a request.
- When you receive the reply (also SOAP), check on the server-side for errors. This is just so that you can retrieve the token and setup account details in the database if the token is sent successfully.
For Tweeener (Nexus):
- Once MSN is redirected to the login URL (m1.escargot.log1p.xyz/login), also setup a connection to RST.srf (the login.live.com one). This time, however, we send a template version of the request to get our token. Alongside this, we also connect to login.live.com and find a way to get the auth cookies (MSPAuth, MSPProf, MSPSec, etc). If both methods reply successfully, we send the data accordingly back to the MSN client.
With Tweener using RST.srf, it’s not much of a problem since we could use the MSN 7.5 policy the server usually sends and it’s GUID, but with actually proxying RST.srf we can’t use it to the fullest to cater to each version of Messenger that does utilize it (also including WLM). And since finding out that MBI_KEY_OLD was supposed to be a base64-encoded nonce (number used once, to prevent replay attacks), I have plans to implement that, which make the policies more important than ever.