{"id":2280,"date":"2014-02-09T06:28:52","date_gmt":"2014-02-09T06:28:52","guid":{"rendered":"http:\/\/www.hexacorn.com\/blog\/?p=2280"},"modified":"2014-09-20T22:22:53","modified_gmt":"2014-09-20T22:22:53","slug":"beyond-good-ol-run-key-part-7","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2014\/02\/09\/beyond-good-ol-run-key-part-7\/","title":{"rendered":"Beyond good ol\u2019 Run key, Part 7"},"content":{"rendered":"

In my last post of this series I discussed the VBA Monitor mechanism<\/a> that can be used to execute code anytime Visual Basic application is started. Today’s topic is similar and talks about yet another internal Microsoft component that could be abused to load arbitrary code – this time it happens anytime the application crashes. As far as I can tell, it only works on XP, so it’s a bit old and not that practically useful, but given the fact XP is still out there in large quantities it is worth documenting it.<\/p>\n

The component that we will abuse is called OAClient. It is an agent that is a part of a distributed test management system called Oasys (Office Automation System) and which is used internally by Microsoft to test their Office suites.<\/p>\n

How do I know?<\/p>\n

I have read about it in this pdf<\/a> (‘Exploring Cross-Platform Testing Strategies at Microsoft”) that I found online while looking for the meaning of the HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\OASys\\OAClient key – and I looked for it, because I spotted this key being queried by DWWIN.EXE anytime the application crashes under Windows XP.<\/p>\n

Once I found out, all I had to do is to add the key, force the application to crash<\/p>\n

\"notepad_crash\"<\/a><\/p>\n

– so that DWWIN.EXE is launched and then confirm that the presence of the OAClient key leads the DWWIN.EXE to attempt loading of the BTLOG.DLL file from c:\\windows\\system32.<\/p>\n

\"dwwin_load_btlog_dll\"<\/a>There you have it.<\/p>\n

To reproduce:<\/p>\n