COM Interface problem! [Archive] - RCE Messageboard's Regroupment

View Full Version : COM Interface problem!

NaZAf

January 5th, 2008, 22:14

Hello:
I have a Type Library File (.tlb) for a COM component (.dll) and I found an interesting interface inside it. Now, I want to invoke some methods of this interface in order to dig in the code, but the problem is that this Interface does NOT belong to any CoClass, further more, it is marked as hidden

Is there someway around this?
I am not expert in COM, I have searched a lot about this and found nothing.

I was thinking of modifying the Type Library and assing the interface to any CoClass object, but it dosn't seem to work.

disavowed

January 6th, 2008, 13:13

I am not a COM expert, but regarding the "hidden" aspect, I would think that if this is marked via a flag in the DLL that prevents you from calling it, then you could just flip that flag so that it's no longer hidden. Please keep in mind that I know little-to-nothing about COM, so this is just based on instinct rather than on an understanding of COM.

dELTA

January 6th, 2008, 14:17

Could this be of any help?

http://www.woodmann.com/collaborative/tools/COMView

Seems quite competent.

NaZAf

January 6th, 2008, 22:29

I already downloaded this tool. It just shows data about COM components in the registry no more.

dELTA

January 7th, 2008, 07:27

I was actually hoping that the following two lines in its description could be of any use?

Quote:

* Can generate ASM include files from type libraries
* Object properties may be edited and methods be executed.

jms

January 7th, 2008, 11:01

I wrote a script for ImmunityDebugger that will resolve COM methods to their effective address. You can get the script from here: http://openrce-snippets.googlecode.com/svn/trunk/pycommand/activex/ ("http://openrce-snippets.googlecode.com/svn/trunk/pycommand/activex/")

Not sure if that will help you a bunch, but take a look at it and let me know.

NaZAf

January 7th, 2008, 17:07

Quote:

[Originally Posted by dELTA;71557]I was actually hoping that the following two lines in its description could be of any use?

This is not the problem. The problem is to find a way to invoke the methods only.

NaZAf

January 7th, 2008, 17:08

Quote:

[Originally Posted by jms;71560]I wrote a script for ImmunityDebugger that will resolve COM methods to their effective address. You can get the script from here: http://openrce-snippets.googlecode.com/svn/trunk/pycommand/activex/ ("http://openrce-snippets.googlecode.com/svn/trunk/pycommand/activex/")

Not sure if that will help you a bunch, but take a look at it and let me know.

I am not debugging anything yet. I just want to know how to invoke them only.

Kayaker

January 8th, 2008, 02:17

Maybe you can approach this from a strictly reversing point of view. I'm with disavowed, I think his instinct is correct.

I know nothing about this either so I may be on the wrong track. You mentioned the properties 'hidden' and 'non-creatable' and you want to be able to switch those so you might be able to use them. Maybe you can give a specific example.

Making use of the tools at hand...

Taking a look at the .NET file mscorlib.tlb in COMView, I see many TypeLibs classified as 'hidden'. For example

Code:



Name	GUID	TypeKind	Flags	Functions	Variables	Interfaces	Idx

_Debugger	{A9B4786C-08E3-344F-A651-2F9926DEAC5E}	DISPATCH (4)	Hidden, Dual, Dispatchable	7	0	1	957



_DebuggerStepThroughAttribute	{3344E8B4-A5C3-3882-8D30-63792485ECCF}	DISPATCH (4)	Hidden, Dual, Dispatchable	7	0	1	958

Now taking a look at the COMView Oaidl.inc source file and digging a bit I see TYPEFLAG definitions attributed to a TYPEATTR structure and accessed by a GetTypeAttr method. MSDN gives us the relevant details:

Code:



ITypeInfo::GetTypeAttr 



This method retrieves a TYPEATTR structure that

contains the type description attributes.



HRESULT GetTypeAttr( 

  TYPEATTR FAR* FAR* ppTypeAttr 

);



oleaut32.lib, uuid.lib





typedef struct FARSTRUCT tagTYPEATTR {

  GUID guid;

  LCID lcid;

  unsigned long dwReserved;

  MEMBERID memidConstructor;

  MEMBERID memidDestructor;

  OLECHAR FAR* lpstrSchema;

  unsigned long cbSizeInstance;

  TYPEKIND typekind;

  unsigned short cFuncs;

  unsigned short cVars;

  unsigned short cImplTypes;

  unsigned short cbAlignment;

  unsigned short wTypeFlags;

  unsigned short wMajorVerNum;

  unsigned short wMinorVerNum;

  TYPEDESC tdescAlias;

  IDLDESC idldescType;

} TYPEATTR, FAR *LPTYPEATTR;





Members:

wTypeFlags - TYPEFLAGS value describing this information.



typedef enum tagTYPEFLAGS {

  TYPEFLAG_FAPPOBJECT = 0x01, 

  TYPEFLAG_FCANCREATE = 0x02, 

  TYPEFLAG_FLICENSED = 0x04, 

  TYPEFLAG_FPREDECLID = 0x08,

  TYPEFLAG_FHIDDEN = 0x10, // The type should not be displayed to browsers

  TYPEFLAG_FCONTROL = 0x20, 

  TYPEFLAG_FDUAL = 0x40,  

  TYPEFLAG_FNONEXTENSIBLE = 0x80, 

  TYPEFLAG_FOLEAUTOMATION = 0x100, 

  TYPEFLAG_FRESTRICTED = 0x200, 

  TYPEFLAG_FAGGREGATABLE = 0x400, 

  TYPEFLAG_FREPLACEABLE = 0x800, 

  TYPEFLAG_FDISPATCHABLE = 0x1000, 

  TYPEFLAG_FREVERSEBIND = 0x2000, 

} TYPEFLAGS;

Continuing with the logical train of thought..

TYPEFLAG_FHIDDEN | TYPEFLAG_FDUAL | TYPEFLAG_FDISPATCHABLE = 0x1050

Which are the TypeFlag settings for the example _Debugger TypeLib. In fact, Comview tells you the same thing in the status bar if you double click on the TypeLib entry.

So, what good is this? There is a ITypeInfo::GetTypeAttr function in oleaut32.dll, but as far as I can tell there is no SetTypeAttr function. However it is a first step in being able to access the TYPEATTR structure where you may be able to modify the wTypeFlags setting.

If you disassemble COMView and search for an error string containing the text "ITypeInfo::GetTypeAttr failed[%X]", you can find where COMView apparently makes use of the oleaut32.dll GetTypeAttr function (by ordinal).

.text:00422719 call dword ptr [edx+0Ch] // GetTypeAttr call ???
.text:0042271C or eax, eax
.text:0042271E jnz errormsg

It is was me, I'd put a breakpoint on that call and trace it to check how the TYPEATTR structure pointer is handled and where the information comes from. Depending on the source you might be able to runtime or raw file change the flags to what you want.

Let us know of any progress (or if this was even remotely what you were looking for).

Kayaker

disavowed

January 8th, 2008, 11:13

Kayaker inspired me to dig a little deeper.

y0da's Metapuck tool is capable of parsing interface flags AND it comes with full source code: http://www.programmersheaven.com/d/click.aspx?ID=F25005
NaZAf, you can use Metapuck's source to figure out where in the assembly the flags are that you want to modify, and then use a hex editor to modify them.

dELTA

January 9th, 2008, 04:27

...and it's also in th CRCETL (now

):

http://www.woodmann.com/collaborative/tools/MetaPuck

Disavowed, you are very welcome to expand the description of this entry with what you know about its COM interface parse/view/analyze abilities, I could not find any info about that?

disavowed

January 10th, 2008, 12:16

Actually, it parses .NET "typelibs". I don't know if that's really COM-based or not :\

jms

January 10th, 2008, 12:24

Ok let's see if I can help some more here:

1) All registered COM objects can be parsed out of the registry, and all of their methods, parameters, etc. are stored in there as well.

2) If you are looking for information on an interface just so that you know how to invoke it, then use oleview from Microsoft.

3) If you are looking at a COM object to determine if you can find a bug and exploit remotely then use COMRaider from iDefense. COMRaider also provides lots of information about the COM control itself.

I hope this helps a bit more.

xtc

January 10th, 2008, 14:18

I'm a bit suprised about the confusion about what a COM interface is, given that COM is a fundamental building block in so much Windows based technology.

To illustrate the usage of interfaces in COM, let's take a hypothetical example of a simple drawing application, which can draw different types of shapes such as squares, circles and triangles.
In the realization that squares, circles and triangles all share similar traits, an interface is created to describe their similiarites, as relevant to the application:

Code:

[...] interface IShape : IUnknown {

    void Draw([in]ICanvas* canvas, [in] long x, [in] long y, [in] long size);

};

This is just a type definition. There's no construction semantics or other code constructs associated with it.
What it says is: Given an IShape, you can invoke Draw on it. In other words it's a contract.

Now, to make use of IShape in the application, coclasses are added for the different shapes:

Code:

[...] coclass Square {

    interface IShape;

};

This specifies that a Square is a class which implements the IShape interface, ie. it fulfills the contract of providing a method to Draw itself.

The application now supports drawing a few different shapes. However as more shapes are added the cost of implementing them as coclasses seems to be overkill (coclasses can require alot of code, depending on which language you implement them in).
So the creation of shapes is abstracted into a Factory:

Code:

[...] interface IShapeFactory : IUnknown {

    IShape* CreateShape([in] BSTR name);

};

[...] coclass ShapeFactory {

    interface IShapeFactory;

};

Thus the different shape coclasses can be removed.

This leaves the application in an situation similar to yours, there's an interface but no associated coclass.
There are ofcourse many other scenarios where standalone interfaces are useful but hopefully my example will get you thinking

The noncreatable attribute is used for situations where a coclass is needed (providing events, for example) but an object cannot be meaningfully created outside a specific context. MSDN mentions an Excel Cell as an example. A Cell doesn't make sense outside of a Worksheet, however Cell's still need to provide events, so it's marked as noncreatable.

dELTA

January 10th, 2008, 14:59

CRCETL:
http://www.woodmann.com/collaborative/tools/COMRaider

http://www.woodmann.com/collaborative/tools/OLE/COM_Object_Viewer_%28OLEview%29

NaZAf

January 12th, 2008, 20:09

This is what I have been saying all time.

The only problem is WHAT the CoClass that implements such interface is. How to find it ?

The Interface alone is not more than a group of functions (methods) with predefined prototypes and without any single line of code behind those methods.

dELTA

January 13th, 2008, 16:08

Hey NaZAf, I think the confusion in this thread comes from the fact that few people are truly familiar with the unholy mess called COM. Let me make another stab-in-the-semi-dark attempt though. Might the following tool be of any help:

http://www.woodmann.com/collaborative/tools/CoClassSyms

It is referenced in this thread here on the board from 2003:

http://www.woodmann.com/forum/showthread.php?t=5046

And originally released with the following MSJ article back in 1999, written by Matt Pietrek:

http://www.microsoft.com/msj/0399/comtype/comtype.aspx

xtc

January 13th, 2008, 16:50

Quote:

[Originally Posted by NaZAf;71760]This is what I have been saying all time.

The only problem is WHAT the CoClass that implements such interface is. How to find it ?

The Interface alone is not more than a group of functions (methods) with predefined prototypes and without any single line of code behind those methods.

Oh for crying out loud. This is a simple problem which you're complicating by imposing an artificial limitation.
You've had no success locating a coclass which implements the interface, yet you insist it must be there.
Put your assumptions aside for a moment and think about how you'd solve your particular type of problem in the scenario which I outlined in my previous post.
I'll drop you a hint to spare myself from being yelled at again: Try searching for references to the interface (methods that take or return it, interfaces which inherit from it and so on) in the typelibrary.
If you cannot deduce the answer from the references, then post them here.

jms

January 13th, 2008, 17:07

Quote:

[Originally Posted by dELTA;71774]
And originally released with the following MSJ article back in 1999, written by Matt Pietrek:

http://www.microsoft.com/msj/0399/comtype/comtype.aspx

Yeah....look back at my first post, download the activex.py that I wrote, and you will see that it's a Python implementation of Matt's C++ code. The difference is that you run it from within ImmunityDebugger, so that you can take the addresses and dynamically trace calls to the functions.

NaZAf

January 14th, 2008, 17:44

Well I understand that locating the CoClass in the binary file is very hard (because it is not in the type library), especially if the Coclass is HIDDEN or worse if used internally.

Finally , I could get the IDispatch* for the interface in memory.

Is it possible to know the CLSID for the CoClass knowing the pointer to Dispatch interface running in memory ??

dELTA

January 26th, 2008, 08:45

Quote:

[Originally Posted by NaZAf;71796]Is it possible to know the CLSID for the CoClass knowing the pointer to Dispatch interface running in memory ??

Might the following be of use perhaps?

http://www.woodmann.com/collaborative/tools/GUID-Finder