OIMs (Offline IMs): The Next Escargot Undertaking

Escargot MSN Server
1

Hello guys! It’s been a long time since I’ve had an Escargot suggestion relating to MSN, with the last one being the first Escargot suggestion, implementing real Microsoft account usability (for those wondering if that’s still possible, it is still being considered, but @valtron needs more people who can undertake more complex disassembly and debugging, which will take some time), and the second one being a replacement MSN webcam server, which I still need to see if it’s still necessary to put out.

Anyways, I have figured out that OIMs (Offline IMs) are something Escargot can implement, after reading some documentation on it. Initially, I had thought that OIMs were possible already, considering my limited knowledge of TCP/IP, which I am still learning slowly almost by the day. But now that I’ve come to my senses, I decided to pitch in.

I have already addressed the innards of the OIM services on a GitLab issue I replied to, so I won’t go into too much here, but here’s a summary of what goes on with the OIM process:

Receiving OIMs

When you sign in, you will get an MSG MSNP command appended to the usual account settings MSG command that contains XML data holding your stored OIMs’ metadata.

MSN Messenger will retrieve each OIM’s GUID from their metadata XML nodes, then use each in a SOAP request to https://rsi.hotmail.com/rsi/rsi.asmx in which it will return the specified OIM in an SMTP-like format.

During an active Notification Server (NS) session, if an OIM is sent while you’re appearing offline, an MSG command is sent with a condensed version of the OIM metadata that only contains that OIM’s metadata. Then MSN will go back to the rsi.asmx service to retrieve the OIM’s actual message data.

If the total OIM metadata node count exceeds 25, the XML in the MSG command will be replaced with the string too-large. MSN Messenger will then send a SOAP request to https://rsi.hotmail.com/rsi/rsi.asmx to retrieve the metadata instead.

Sending OIMs

To send an OIM, MSN Messenger will send a SOAP request to https://ows.messenger.msn.com/OimWS/oim.asmx with the sender’s email and name, the recipient’s email, each OIM’s message type and body, and an MD5 hash of an internal value sent by the service that is manipulated by the client with the MSNP11 challenge algorithm (the Application ID used in the algorithm is also specified in the SOAP request).

If everything goes well, then a SOAP reply is sent with confirmation info.

Deleting OIMs

To delete OIMs, MSN Messenger will send yet another SOAP request to https://rsi.hotmail.com/rsi/rsi.asmx with any of the OIM’s GUIDs MSN specifies to delete the corresponding OIMs. If everything is successful, a response SOAP body is sent just containing confirmation info.

Back to the Notification Server (NS), an MSG command will be sent notifying the MSN client of the deletion of an OIM.

Epilogue

That’s really about it for OIMs. It will take some time to finish, but nothing too daunting. If you think that I am just the Yahoo! guy, you thought wrong! :wink:

However, I do need to arrange time for that, and it’s not necessary of a feature to look into, so actually implementing the thing will be sought after at a later date. :stuck_out_tongue:

9 Likes
2

:thinkeyes:

wait this isnt discord

anyways yea thats pretty nice

1 Like
3

So you’re also the Offline IMs guy as well?

1 Like
4

LOL if you want to put it like that. :stuck_out_tongue:

1 Like
5

I’m pretty excited for the feature. because everytime i tried to do that it showed a error. Just dont make it work for blocked contacts

1 Like
6

Now that the Yahoo! frontend has been merged into the dev branch, I can finally get to implementing OIMs. :wink:

7

maybe fix dummydata.py since it got broken since 8.x

8

@valtron has already spiffied up dummydata.py to utilize a new algorithm for adding dummy users, and aside from another module definition I had to fix, nothing else is broken. :stuck_out_tongue:

9

Update

So I was able to implement receiving and sending OIMs, both on the HTTPS and MSNP Notification Server side, so is that it?

No, unfortunately, because as I was debugging rsi.asmx, I found out that the t= token wasn’t sandwiched in between <t></t> as it would usually be (also includes the p= token, which isn’t used in Escargot auth, but whatever).

rsi%20request

That basically means the service can’t authenticate the user at all in order to send/receive commands to the right people, like triggering events when sending OIMs (if the recipient is technically online, of course), deleting OIMs, and whatever results in an Notification Server command during the OIM services’ runtime. The most odd thing about this, however, is that the other OIM services have said authentication tokens supplied. I can only point my finger at @valtron’s MSIDCRL used for Escargot auth atm, so we may need to either implement the function used to supply the tokens for these services, or simply find a way to patch the original MSIDCRL DLL altogether.

I hope you can understand and hold on to that last shred of patience you contain as we get to the bottom of this mystery. :stuck_out_tongue:

1 Like
10

Recently, @valtron’s been looking into another method of patching MSN 7.5+ to log on to Escargot, which involves injecting a DLL in the MSN executable that will override connections to specific URLs to Escargot, similar to Escargot Switcher, but embedded inside the executable. Since this will involve a different custom DLL, this means the original msidcrl will be used, also meaning that authentication for OIM retrieval will work properly. When valtron comes back with news that this patching method works, I’ll look into dusting off the OIM server code and tweaking it for deployment after the WLM 2009, Yahoo!, and IRC support are deployed.

5 Likes
11

Now that the new DLL.patch has been tested to work on the targeted MSN versions we’d like to support, I’ve taken the liberty of refining and testing the OIM feature for MSN, and so far, it works perfectly. Everything from sending to receiving to assembling and evem deleting the OIMs work. Only problem now is how to handle multiple messages in one offline messaging session, since the official client uses a persistent ID for each user until the sender re-logs in. So far, it looks like multiple messages are stored in a multipart format, which is a little confusing, but I’m aiming to adjust what’s needed and see how it plays out.

BTW, here’s a screenshot of a test OIM I sent and retrieved from my local server to get an idea of what they look like:

unknown

As for MSNP18 (WLM 2009), that uses a completely different, yet simpler system for sending OIMs, and I’ll look into that later.

4 Likes
12

I see no screenshot

13

Some core tweaks later, and now the OIM system works fully for MSN. I’m still wondering if MSNP18’s method for sending OIMs (which is actually just the command used for messaging Yahoo! contacts) uses the notification server when the target contact is invisible or if it wrote to the classic e-mail based system regardless. Either way, OIMs are basically dealt with, and will be committed to the server repository soon.

14

Good news! OIM support for MSN is fully complete and published. Escargot / Escargot Server · GitLab

Prepare for it to be released along with the other updates.

8 Likes
15

awesome!

16

Is OIM’s supposed to be working?

17

They’re not publicly available yet, like a lot of Escargot’s new features. They’ll come out when everything else is ready. :stuck_out_tongue:

18

I thought this was the case, there was another thread where someone said it was available so thought I would double check. :grinning: