Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.
Sign up to join this community
I have a dll file, containing some exported functions and COM methods.
Here is my dll information opened by DLL Export Viewer:
But when i open the dll file in ida pro, i see just exported functions and none of COM methods are listed.
How I can view list of start address of the COM methods in ida pro?
This is not as trivial as one would hope for quite a simple reason, COM objects are internal objects, and do not expose their implementation details by exporting functions.
Instead, COM provides an interface to create COM instances of a specific class using a class UUID (commonly known CLSID) as means to identify a COM class.
COM objects are created by calling CoCreateInstance documented here.
The returned object is a C++ object implementing a set of APIs exposed as a virtual function table for that COM object, so there's no need to export those functions and that's you can't find them using IDA's exports view.
Side note: Although COM related reversing questions are not at all too scarce, there are a lot fewer questions related to reversing COM classes. Most COM related questions involve attempts to reverse engineer software using COM, while it appears the OP is trying to reverse engineer a COM class. I guess this is somewhat because most COM classes are documented to some extent.
DLL Export Viewer results
As documented here, DLL Export Viewer supports reading COM Type Libraries from type library resources embedded inside the DLL. I'll describe COM Type Libraries in a few paragraphs and you'll see how you could get that data in IDAPython.
From the original site:
Version 1.10
Added support for 64-bit DLL files.
New option: Display method and properties of COM type libraries.
Although your question was a bit misguided, there are still several resources that could help you RE COM object providers.
Documentation
Some resouces are available for in-depth COM understanding (and therefore reversing) online, such as MSDN's basic COM development guide, Microsoft System Journal about come type libraries
Oleview.exe
First, for basic understanding of COM objects and ability to browse COM objects defined on your machine you should try using Oleview, downloadable as part of windows Driver Kit or similar.
OleView.exe lets you list installed COM objects, the interfaces they provide (which describe the actual methods implemented by that COM object), each COM object's class ID, etc. If you can find your COM object here, it'll greatly help you in later stages.
Class informer plugin
Using the class informer IDA plugin, you might be able to find RTTI information for your COM object. This will help you find and partially map your COM object's Virtual Function Table (which, again, describes available functionality of a COM object by actually pointing to the implementation methods). Using IDA's builtin COM Helper plugin might also be useful.
Manually parsing type library files (*.tlb) using python
Although this is roughly what Oleview.exe (and the likes) are doing, you could manually parse any *.tlb file you find (usually located near the COM DLL or embedded as a resource inside it) to get the information you're interested in (including offsets in the binary where functions are implemented).
A python module called pythoncom exists for that, as part of the python for win32 extensions. Documentation is here, and the module can be downloaded here
There is an old plugin by Dieter Spaar which uses TypeLib API to enumerate COM methods and find their addresses. The code is somewhat old so might need some adjustments for the later IDA versions. Note that it relies on presence of the typelib info so might not work for barebones (typelib-less) COM objects.
It is based on this article by Matt Pietrek.
Edit: one more thing. To figure out the addresses of the interface's methods, the plugin has to actually create the class implementing the interface (by calling CoCreateInstance) which means that it will execute code from the DLL/OCX. So you need to take care with files of uncertain origins.
