hardwarefetish.com

Fixing a bug in Zarafa Client 7.2.4 that crashed it on Outlook >2013

A customer is running a Zarafa Server for some years now and it works nicely with its webinterface and all integrations. He also used the Zarafa Client (zarafaclient-7.2.4-52167.msi) on Outlook 2010 without issues, but only on 2 machines.
But as the number of users grew, it was desirable to get it running an new machines and unfortunately, Microsoft doesn’t sell licenses for old Outlook versions anymore. I tried running the Zarafa Client on Outlook 2022, but after installation, Outlook just crashed after the Splash screen.
So time to look into the internals of the Zarafa connector.
It seems to use an old “trick” to hook Outlook by placing a version.dll in Outlook’s program directory so that due to the DLL search path, the “prepared” version.dll gets loaded, which forwards the normal functions to the system’s version.dll but is hooking 2 functions on startup:

MAPILogonEx in olmapi32.dll and GetProcAddress in kernel32.dll to filter dynamically loaded functions.
GetProcAddress checks for the import or Ordinal 11 in olmapit32.dll, which also is MAPILogonEx and hooks it and it also hooks functions FValidEmsabpEntryID and FValidEmsabpEntryIDBin.
Interesting for the problem is the MAPLogonEx hook. In there, it checks current Outlook version from HKEY_CLASSES_ROOT\Outlook.Application\CurVer key and compares it to the value 15, because the “IMAPISession” class that it tries to overload changed in version 15.

And here is the problem. It does (in pseudocode):

if (!SUCCEEDED(GetOutlookVersion(&dwVersion)) || dwVersion != 15)
{
  *lppSession = &IMAPISessionWrapper;
}
else
{
  *lppSession = &IMAPISessionOlk15Wrapper;
}

Now Outlook 2022 is Version 16, (for a list of Outlook version numbers, see Wikipedia article on Outlook), therefore it falls back to Version 14 and below vtable and then the wrapper functions call the wrong functions and so – besides wrong function calls – we end up with a ruined stack that finally crashes Outlook.
The fix is incredibly simple: Change dwVersion != 15 to dwVersion < 15, so in ASM:

.text:100038BA                 cmp     [esp+8+arg_10], 0Fh
.text:100038BF                 jnz     short loc_100038E3

So change jnz to jb. And tadaa… It works! (with a Hex-Editor, you can change 75h to 72h on offset 2CBFh).
I made a little Patcher that does the work for you, if you are experiencing the same problem.
For me, this simple fix was enough to get it running.

Leave a Comment