a.k.a. Implementing Real Accounts onto Escargot Pt. 2: Not blindly listening to people saying that it isn’t possible and doing more extensive research! 
On a certain Escargot GitLab issue regarding a formerly hot topic about Escargot, logging on with real Microsoft accounts, one of the devs linked an older Escargot GitLab issue. Number 4, to be exact. Most of the issue is pretty interesting to read and watch how much progress the dev team tried to make in terms of getting it working.
Basically, a file MSN Messenger fetches during authentication, ppcrlconfig.bin, contains XML that includes the RST.srf URL we desperately needed to get the account services intertwined.
However, there were some miscalculated roadblocks along the way. Aside from the aforementioned dev’s unnecessary suggestion to decrypt Microsoft tokens when the Escargot server gets them, there’s also his outrageous statement that the ppcrlconfig DLLs in WinSxS, a DLL cache, mind you, are encrypted and was thus considered a dead end, even though I wouldn’t be relying on a DLL cache to look at an application’s DLL modules. 
Alongside that is also the apparent fact that the ppcrlconfig DLL in the ProgramData folder (C:\ProgramData\Microsoft\IdentityCRL and C:\ProgramData\Microsoft\IdentityCRL\production) auto-repairs itself, which sounded very odd.
Several hours ago, I had put that to the test.
I had modified a copy of ppcrlconfig.bin I had downloaded from Microsoft’s servers over a year ago to contains links to custom domains I then “hacked” with HOSTS entries.
Then came the setup of the Escargot dev server to host the .bin under HTTP for MSN to download and the URLs I had to change, which are listed below:
https://login.live.com (Stored inside ppcrlconfig.bin; used for RST location)
http://clientconfig.passport.net/ppcrlconfig.srf (Stored in MSN 7.5; somehow redirects to the .bin file anyway)
loginnet.passport.com (Also stored in MSN 7.5; used for RST location)
When I logged in on the dev server, I had come to the realization that it connected to the real RST.srf anyway, due to the entry in the ppcrlconfig DLL in the ProgramData folder (C:\ProgramData\Microsoft\IdentityCRL ONLY). I kept an original copy of the DLL and modified it so it would connect to Escargot’s RST.srf handler. Needless to say, no auto-repairing of ppcrlconfig.dll happened during the 40+ minutes I had been testing the new setup.
However, MSN 7.5 refused to even connect to the MSNP server when these changes were put into effect. I also noticed that whenever I typed in anything in the e-mail address column, it would make a new GET request to http://<local ppcrlconfig host>/ppcrlconfig.bin for every keystroke.
I am not giving up yet, considering that I had just tried this out. And I also might have forgotten some other key things to modify and tweak. The only problem I have is reinstalling MSN 7.5 over and over again, since I don’t have any spare computers ATM, plus whenever I access the HTTPS portion of the dev server via my XP VM, IE and the server start complaining. So I may not be able to look into this as much as what the Escargot team has on their to-do list.
Let’s see how far we can go with this, regardless.
