30 Mar
2017
30 Mar
'17
2:58 p.m.
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-d…
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
30 Mar
30 Mar
8:16 p.m.
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-d…
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
4 Apr
4 Apr
5 p.m.
Hi Michael,
On 30/03/17 21:16, Michael Stefaniuc wrote:
Sure - I have the type information (it turns out) - thanks for the pointer.
Makes sense.
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
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. 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.
11 May
11 May
3:29 p.m.
Hi Michael,
On 30/03/17 21:16, Michael Stefaniuc wrote:
Thanks for your help here; we ended up writing something like this:
http://tml-blog.blogspot.com/2017/05/tracing-idispatchinvoke-calls-in-com.h…
Based on the Deviare code which can hook the IDispatch implementations
for remote COM calls and do something useful.
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. 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
21 Aug
21 Aug
2:39 p.m.
New subject: COM tracing ... - COLEAT ...
Hi Michael,
On 11/05/17 16:29, Michael Meeks wrote:
On 30/03/17 21:16, Michael Stefaniuc wrote:
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
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.
2078
days inactive
2587
days old
4 comments
2 participants
participants (2)
-
Michael Meeks -
Michael Stefaniuc