Hi guys, Rather a peripheral question; apologies for that - but I'd imagine there are experts here that may be able to help. I have a black-box problem - a Windows app dealing with confidential data that I can't easily touch (and thus can't get to run under Wine) - which does some small but critical automation of MS Office - using VBS / COM scripting. I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far): http://www.rohitab.com/apimonitor which, while closed, looks interesting; but traces a lot in a hard-to-search way and doesn't appear to do the trick. https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-di... Sounds useful: using Event Tracing for Windows (ETW) but has this rather unhelpful property: "The binary file must be formatted by Microsoft so that it can be analyzed. Please forward the .etl files to your support contact. ..." ;-) Component models used to be all the rage in my youth ;-) surely someone solved the "strace for COM calls" problem elegantly some-when ! Crazily - might it be possible to instrument, interpose and use Wine's COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ? Anyhow - help much appreciated & sorry for the noise ! Regards, Michael. -- michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot
Hello, On 03/30/2017 04:58 PM, Michael Meeks wrote:
Rather a peripheral question; apologies for that - but I'd imagine there are experts here that may be able to help.
I have a black-box problem - a Windows app dealing with confidential data that I can't easily touch (and thus can't get to run under Wine) - which does some small but critical automation of MS Office - using VBS / COM scripting.
I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far): don't you have at least a tlb file for the culprit COM stuff? You can look at that with oleview; Wine implements one too should you be on Linux.
http://www.rohitab.com/apimonitor which, while closed, looks interesting; but traces a lot in a hard-to-search way and doesn't appear to do the trick.
https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-di... Sounds useful: using Event Tracing for Windows (ETW) but has this rather unhelpful property: "The binary file must be formatted by Microsoft so that it can be analyzed. Please forward the .etl files to your support contact. ..." ;-)
Component models used to be all the rage in my youth ;-) surely someone solved the "strace for COM calls" problem elegantly some-when !
Well Wine has that built in for the stuff it implements. For the rest we write tests that exercises the respective API.
Crazily - might it be possible to instrument, interpose and use Wine's COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ? You don't need Wine for that. You can write wrappers around the COM classes you need, easily if you have the info from the TLB.
Anyhow - help much appreciated & sorry for the noise !
bye michael
Hi Michael, On 30/03/17 21:16, Michael Stefaniuc wrote:
I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far):
don't you have at least a tlb file for the culprit COM stuff? You can look at that with oleview; Wine implements one too should you be on Linux.
Sure - I have the type information (it turns out) - thanks for the pointer.
Component models used to be all the rage in my youth ;-) surely someone solved the "strace for COM calls" problem elegantly some-when !
Well Wine has that built in for the stuff it implements. For the rest we write tests that exercises the respective API.
Makes sense.
Crazily - might it be possible to instrument, interpose and use Wine's COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ?
You don't need Wine for that. You can write wrappers around the COM classes you need, easily if you have the info from the TLB.
Ok ? so I have a huge chunk of XML from tlb2xml from here - which is nice; the approach you'd suggest is manually, incrementally writing wrappers and interposing them between MS Office and the automation to work out what methods are being invoked ? an incremental approach makes the problem somewhat hard to scope I suspect. Anyhow - many thanks for the input. ATB, Michael. -- michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot
Hi Michael, On 30/03/17 21:16, Michael Stefaniuc wrote:
I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far):
don't you have at least a tlb file for the culprit COM stuff? You can look at that with oleview; Wine implements one too should you be on Linux.
Thanks for your help here; we ended up writing something like this: http://tml-blog.blogspot.com/2017/05/tracing-idispatchinvoke-calls-in-com.ht... Based on the Deviare code which can hook the IDispatch implementations for remote COM calls and do something useful.
You don't need Wine for that. You can write wrappers around the COM classes you need, easily if you have the info from the TLB.
Of course, a more general solution for in-process COM interception would be really ideal, but much more work I guess. Thanks very much for your help ! Regards, Michael. -- michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot
Hi Michael, On 11/05/17 16:29, Michael Meeks wrote:
On 30/03/17 21:16, Michael Stefaniuc wrote:
I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far):
don't you have at least a tlb file for the culprit COM stuff? You can look at that with oleview; Wine implements one too should you be on Linux.
Thanks for your help here; we ended up writing something like this:
You don't need Wine for that. You can write wrappers around the COM classes you need, easily if you have the info from the TLB.
Just an update - and in case it is useful to any noble Wine hackers out there for some reason :-) we eventually implemented COLEAT: https://www.collaboraoffice.com/coleat/ based on your advice, and a chunk more research - that lets us trace OLE automation in its several forms: even pre-compiled VB6 executables' usage - such that we can create COM interoperability APIs for Collabora Office / LibreOffice. We used IAT patching in the end to inject our tracing proxies, and of course - all patches most welcome. Thanks for the pointers, Michael. -- michael.meeks(a)collabora.com <><, GM Collabora Productivity Hangout: mejmeeks(a)gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe
participants (2)
-
Michael Meeks -
Michael Stefaniuc