COM tracing ...

[Michael Meeks]

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 Stefaniuc]

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

[Michael Meeks]

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]

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.

COM tracing ... - COLEAT ...

[Michael Meeks]

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.