Messenger patches for feature availability

After reviewing some old notes and looking into some of the configuration issues with Messenger some of the XML files will be required just to enable some features. The system.xml file is responsible for a lot of option enable flags with newer versions controlling things like yahoo chat, sms, yahoo360, launchcast, pingbox, and avatars. Enabling/disabling some features can be done via a set of flags passed in the user profile packet but not all. The good thing is that so far the default settings used when the file is not available seem to be working ok but I’m not expecting that to hold out when I hit 8.1

The biggest blocker for this is the signing requirements of the files which carry over to other files such as filter.xml (packet field filtering - you want this, trust me!), imvironments.xml, and partner.xml. Later versions have other options for avatars, plugins, etc. that are found in the XML files. There are additional files downloaded to support the features enabled by system.xml. The newer the version the more files will be required - guess where the emoticons are defined in newer versions :slight_smile: For example in the videos I posted Messenger 5.6 had Net2Phone enabled but 5.6 introduced messaging to mobile devices. I managed to swap the two but the approach is a bit unstable. Being able to include and modify that file would be a much better approach.

Supporting the feature is possible but requires validating the carrier via (dead domain) and an SMS provider with an API. I’ll map out the packet for completeness but plan on removing both Net2Phone and mobile messaging until I start supporting 8.1. Other features like IMVironments and Audibles are a lot more practical but will require a bit of tedious investigation and may require you to create you own. At least for Messenger 6.0 IMVironments are required if you want to support features like file or photo sharing. Messenger 5.6 appears to have 3 IMVironments embedded in res_msgr.dll so if you can figure out how to point to them from the configuration file you’ll at least be able to support the ones available.

Interestingly enough there are also some dialogs that point to features that aren’t readily available.

  • Support for logging into AIM servers
  • Support for logging into ICQ servers.
  • Alternate logins for company portals
  • Parental control
  • Creating a poll
  • Message Box / Answering Machine
  • Creating custom tabs

Some like the company portals, AIM and ICQ services are probably registry hacks although they could require an active session for enabling AIM and ICQ support. The only one I’m interested in is the portal login as it’s a possible solution for alternate authentication methods.

Nice work, Chet. You seem to be pretty invested in this. If possible, could you send the XML files somewhere, if they’re THAT important? :stuck_out_tongue:

Just to quickly address:

Actually, the IMVironments are archived, from looking around. (Wayback Machine*)

As for Audibles, there only seem to be a handful of them archived, but here are the archives nonetheless: Wayback Machine*

(Little note: Try to avoid any archives that begin or contain any captures from post-2012)


I decided to take a leap of faith with the Audible URLs, and tried out this URL:<locale>

Tried it with an Audible file name I was familiar with (, and it downloaded without any effort.

So basically, the Audibles still exist. All you have to worry about now are file names. :stuck_out_tongue:

I’ll send what I have when I get home. I did locate the code that queries the signature so I’ll be targeting that for modification. There are two callsites that need to be patched and I’m hoping to nop it all out otherwise you may still have to provide a signature attribute with an empty string. This should hopefully limit the patches to 2 callsites per version which is better than the first approach.

Thanks for the links. I’ll be archiving them first thing this evening.

1 Like

Well, your welcome! :slight_smile:

As for the IMVironments, I almost forgot to mention. They had config files server-side. Here’s a Hello Kitty one for example:

(Personally, I’d figure out how the signatures are verified, but you do you. :stuck_out_tongue:)

Interesting. I am curious about one thing. How are you managing the development of the server since Messenger won’t connect to an IP assigned to the local NIC’s (plus loopback) without a bit of help?

Actually, I have my PC port forwarded, mainly because I have a Windows 2000 virtual machine for testing YMSG (with a second Yahoo! ID) and I need it to connect to the server somehow, obviously lol. So I have my public IP for Yahoo! Messenger to connect to, both on my host and virtual machine.

Risky, I know. But interestingly enough, Yahoo! Messenger 5.5 connected to localhost from initial testing. :stuck_out_tongue:

You can thank me for the connectivity differences between 5.5 and 5.6. Yahoo! started checking the IP address returned by gethostbyname() because I was redirecting messenger connections. Trivial to get around so it didn’t exactly slow me down.

1 Like

I haven’t tested this but you should be able to bypass the signature by setting 004C3608 to 0xc3 (ret). 0x4c3603 is the entry point to the signature verification function and the call sites test EAX for non-zero value for success. Since 0x4c3603 sets EAX to a value other than zero that should be it.,

[EDIT: This is for 5.6 build 1358]

I think you misunderstood the end of the reply. I stated that I’d personally find out how the signatures are verified. As in, reverse-engineer the signature verification to suit the modifications made to the XML file(s) without patching the executable itself. :stuck_out_tongue:

But thanks for the tidbit anyway.