如何迭代COM coclass的vtable?

发布于 2024-08-25 00:56:28 字数 159 浏览 7 评论 0原文

如何迭代/访问 COM coclass 的 vtable 来实现其公开接口的方法?

我需要访问 vtable 中存储其接口的公开方法的所有地址的部分。

例如Math是COM对象,它暴露的接口是“Operations”,“Sum”是该接口的方法,我如何获取“Sum”的地址?

How can I iterate/access the vtable of COM coclass which will implement the methods of its exposed interfaces?

I need to access the part of the vtable where all addresses of exposed methods of its interfaces are stored.

e.g. Math is COM object, its exposed interface is "Operations" and "Sum" is the method of this interface, how do I get the address of "Sum"?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

末蓝 2024-09-01 00:56:28

我不会问你为什么这样做,但也许这会有所帮助......
每个 COM 对象必须至少实现 IUnknown 接口。因此,COM 对象实例的前四个字节是指向 IUnknown 对象的指针。 IUnknown 对象(以及任何其他具有虚函数的对象)的前四个字节是指向 vtbl 的指针。

(本例中没有错误检查,所以请不要在这个问题上争论不休。)

我使用了 IReferenceClock 的实例进行演示。

int main()
{

    CoInitialize( NULL );

    IReferenceClock* pRefClock;
    HRESULT hr = CoCreateInstance( CLSID_SystemClock, NULL, CLSCTX_INPROC_SERVER, IID_IReferenceClock, (void**)&pRefClock );

    DWORD* pIUnknownAddress = (DWORD*)pRefClock;
    DWORD* pVTBLaddress = (DWORD*)*pIUnknownAddress;

    // for example, the next interface could be accessed like this
    DWORD* pNextInterfaceAddress = ( (DWORD*)pRefClock ) + 1;
    DWORD* pNextVTBLaddress = (DWORD*)*pNextInterfaceAddress;
    // and you would access virtual functions in the same way as QueryInterface, AddRef and Release below in this example

    HRESULT (__stdcall *pQueryInterfaceFunction)(void*, REFIID, void**);
    ULONG (__stdcall *pAddRef)( void* );
    ULONG (__stdcall *pRelease)( void* );

    // IUnknown looks like this:
    // 
    // virtual HRESULT QueryInterface( REFIID riid, void** ppvObject);
    // virtual ULONG AddRef( void );
    // virtual ULONG Release( void );
    //
    // So, the first function in vtbl is QueryInterface, the second is AddRef...

    pQueryInterfaceFunction = (HRESULT (__stdcall*)(void*, REFIID, void**))*pVTBLaddress;
    pAddRef = (ULONG (__stdcall *)( void* ))*( pVTBLaddress + 1 );
    pRelease = (ULONG (__stdcall *)( void* ))*( pVTBLaddress + 2 );

    // Note: extra void* is actually this pointer.. see below that we pass pRefClock to every call

    IUnknown* pUnknown;
    UINT nRefCount;

    hr = pQueryInterfaceFunction( pRefClock, IID_IUnknown, (void**)&pUnknown );

    if( SUCCEEDED( hr ) )
    {
        nRefCount = pUnknown->Release();
        ATLTRACE( TEXT( "nRefCount = %d\n" ), nRefCount );
    }

    nRefCount = pAddRef( pRefClock );
    ATLTRACE( TEXT( "nRefCount after AddRef() call = %d\n" ), nRefCount );

    nRefCount = pRelease( pRefClock );
    ATLTRACE( TEXT( "nRefCount after Release() call = %d\n" ), nRefCount );

    nRefCount = pRefClock->Release();

    CoUninitialize();

    return 0;
}

I'm not going to ask why are you doing it this way, but perhaps this could help...
Every COM object must implement at least the IUnknown interface. Hence, the first four bytes of the COM object instance is the pointer to IUnknown object. The first four bytes of the IUnknown object (and any other object with virtual functions) is the pointer to vtbl.

(There is no error checking in this example, so please don't split hair on that subject.)

I used an instance of IReferenceClock for demonstration.

int main()
{

    CoInitialize( NULL );

    IReferenceClock* pRefClock;
    HRESULT hr = CoCreateInstance( CLSID_SystemClock, NULL, CLSCTX_INPROC_SERVER, IID_IReferenceClock, (void**)&pRefClock );

    DWORD* pIUnknownAddress = (DWORD*)pRefClock;
    DWORD* pVTBLaddress = (DWORD*)*pIUnknownAddress;

    // for example, the next interface could be accessed like this
    DWORD* pNextInterfaceAddress = ( (DWORD*)pRefClock ) + 1;
    DWORD* pNextVTBLaddress = (DWORD*)*pNextInterfaceAddress;
    // and you would access virtual functions in the same way as QueryInterface, AddRef and Release below in this example

    HRESULT (__stdcall *pQueryInterfaceFunction)(void*, REFIID, void**);
    ULONG (__stdcall *pAddRef)( void* );
    ULONG (__stdcall *pRelease)( void* );

    // IUnknown looks like this:
    // 
    // virtual HRESULT QueryInterface( REFIID riid, void** ppvObject);
    // virtual ULONG AddRef( void );
    // virtual ULONG Release( void );
    //
    // So, the first function in vtbl is QueryInterface, the second is AddRef...

    pQueryInterfaceFunction = (HRESULT (__stdcall*)(void*, REFIID, void**))*pVTBLaddress;
    pAddRef = (ULONG (__stdcall *)( void* ))*( pVTBLaddress + 1 );
    pRelease = (ULONG (__stdcall *)( void* ))*( pVTBLaddress + 2 );

    // Note: extra void* is actually this pointer.. see below that we pass pRefClock to every call

    IUnknown* pUnknown;
    UINT nRefCount;

    hr = pQueryInterfaceFunction( pRefClock, IID_IUnknown, (void**)&pUnknown );

    if( SUCCEEDED( hr ) )
    {
        nRefCount = pUnknown->Release();
        ATLTRACE( TEXT( "nRefCount = %d\n" ), nRefCount );
    }

    nRefCount = pAddRef( pRefClock );
    ATLTRACE( TEXT( "nRefCount after AddRef() call = %d\n" ), nRefCount );

    nRefCount = pRelease( pRefClock );
    ATLTRACE( TEXT( "nRefCount after Release() call = %d\n" ), nRefCount );

    nRefCount = pRefClock->Release();

    CoUninitialize();

    return 0;
}
余生再见 2024-09-01 00:56:28

很抱歉回答一个问题,但我必须问“从哪里来?”

如果您的意思是,如何从 COM 客户端迭代 vtable,我认为您不能。在客户端,您拥有的只是一个知道如何与 COM 服务器通信(可能是跨单元或跨进程)的代理。您也许可以探测该代理的 vtable,但它永远无法告诉您 COM 服务器内函数的地址。

当然,如果服务器实际上运行在不同的进程中,则函数的地址可能对您没有什么用处。即使服务器位于同一个进程中,但在不同的单元中,获取函数地址也可能是危险的:您可以直接调用函数,绕过 COM 的拦截,并打破服务器类对调用线程的假设等。

我猜迭代vtable 是达到目的的手段...?也许发布你实际上想要做的事情,我认为 COM 可能有办法做到这一点。

Sorry to answer with a question, but I have to ask "from where?"

If you mean, how can you iterate through the vtable from a COM client, I don't think you can. On the client side, all you have is a proxy that knows how to communicate (maybe cross-apartment or cross-process) with the COM server. You could maybe probe the vtable of that proxy, but it can never tell you the addresses of the functions inside the COM server.

Of course, if the server is actually running in a different process, the address of the functions might be of little use to you. Even if the server is in the same process, but in a different apartment, getting function addresses might be dangerous: you could call the functions directly, circumventing COM's interception, and break the server class's assumptions around calling thread, etc.

I guess that iterating the vtable is a means-to-an-end...? Maybe post what you're actually trying to do and I think COM probably has a way to do it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文