Beyond good ol’ Run key, Part 10

Posted on by

There is no doubt that Microsoft products are a subject to a lot of testing – this is understandable as it’s undeniably the most used office software in the world. It’s hard to imagine software packages that complex to be completely separated from the platform/modules that are used to testing them – it’s not a surprise then that references to various Microsoft testing platforms or modules can be found in strings or Process Monitor logs. One of them is called Oasys (Office Automation System) and I discussed it in the 7th part of the series. This is not the only one though and this short post will talk about yet another trick (or two) that are most-likely side-effects of deep integration with testing platforms – they can be both used to load a phantom DLL anytime Office programs start, and in some cases when other programs do as well.

Office 2007, 2010 and 2013

Adding a key/value pair shown below to the Registry will guarantee that the test.dll will load anytime Office 2007, 2010 or 2013 programs are started (e.g. WinWord, Excel):

[HKEY_CURRENT_USER\Software\Microsoft\Office Test\Special\Perf]
@="C:\\test\\test.dll"

Interestingly, sometimes the DLL will be also loaded when e.g. Internet Explorer launches – as long as one of the office plugins is loaded into IE (and the plugin’s code or its libraries refer to the aforementioned Office Test value). There are most likely other cases since Office COM objects can be easily instantiated from other software.

The respective global key exists under the HKLM branch i.e. HKLM\SOFTWARE\Microsoft\Office Test\Special\Perf.

Office 2010 and WinWord

Adding a key/value pair shown below to Registry will guarantee that instead of a WWLIB.DLL that is distributed with Office 2010 a different DLL will be loaded instead anytime WinWord starts – a DLL named WWLIBcxm.DLL.

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word]
"CxmDll"=dword:00000001

In other words, placing a custom WWLIBcxm.DLL in the Office directory (or any listed under PATH) will do the trick. Note that such DLL will need to act as a proxy for WWLIB.DLL – otherwise the WinWord won’t load (it requires WWLIB.DLL to work).