get the real address(or index in vTable) of virtual member function

Question

In c++ is there any way to get the real address of member function, or the index in vTable ?

Updated:

I don't know the INDEX in vTable and I don't know the address

Here's why I want to know this:

I want to hook the function ID3DXFont->DrawText of DirectX. If I know the index of the DrawText in the vTable, I can replace it to do the hook. But how to get the index? If it's able to get the the real address, I can search it in the vTable to get the index.

And not particularly ID3DXFont->DrawText, maybe some other functions in the future, so I'm trying to write a generic hook function.

Here's what I've tried so far:

#include <iostream>
using namespace std;

struct cls {
    virtual int fn1() {
        cout << "fn1 called" << endl;
        return 1;
    }
    virtual int fn2() {
        cout << "fn2 called" << endl;
        return 2;
    }
};

template <typename fn_t>
DWORD fn_to_addr(fn_t fn) { // convert function to DWORD for printing
    union U {
        fn_t fn;
        DWORD addr;
    };
    U u;
    u.fn = fn;
    return u.addr;
}

int main() {
    cls c;

    DWORD addr = fn_to_addr(&cls::fn2);
    cout << hex << addr << endl;
}

In debug mode, the code above outputs the address of jump table. And in release mode, the &cls::fn2 returns 0x00401058, which points to some optimized code:

00401058   .    mov     eax, dword ptr [ecx] // get vptr
0040105A   .    jmp     dword ptr [eax+4] // jmp to the second function (fn2)

Both are not the real address. Anyway to do that?

Thanks.

Answer 1

Don't give up so easily!

While the other answers are correct in saying that the C++ language doesn't allow you to do this in a portable way, there's an important factor in your particular case that may make this a more reasonable thing to do.

The key is that ID3DXFont is a COM interface and the exact binary details of how those work are specified separately from the language used to access them. So while C++ doesn't say what you'll find at the other end of that pointer, COM does say that there's a vtable there with an array of function pointers in a specified order and with a specified calling convention. This allows me to tell you that the index of the DrawText function is 314 (DrawTextA) or 15 (DrawTextW) and that this will still be true in Visual C++ 28.0 many years from now. Or in GCC 8.3.1 for that matter: since COM is a binary interface specification, all compilers are supposed to implement it the same way (if they claim to support COM).

Have a look at the second link below for a ready-made implementation of COM function hooking using two different methods. Approach#2 is the closest to what you're asking for but I think you may want to consider the first one instead because it involves less voodoo.

Sources:

[http://msdn.microsoft.com/en-us/library/ms680573(v=vs.85).aspx] [http://www.codeproject.com/Articles/153096/Intercepting-Calls-to-COM-Interfaces] [http://goodrender.googlecode.com/svn/trunk/include/d3dx9core.h]

Answer 2

There's nothing anywhere near portable. Your attempt using &cls::fn2 can't work, since the results must work in cases like (pCls->*fn)() even when pCls points to a derived class which overrides the function. (Pointers to member functions are complicated beasts, which identify whether the function is virtual or not, and provide different information depending on this. And if you're experimenting with MSC, be aware that you have to specify /vmg for pointers to member functions to work correctly.)

Even for a given implementation, you need an instance of the correct type. Given that, if you know the class layout, and the layout of the virtual function table, you can track it down. Typically, the pointer to the virtual function table is the first word in the class, although this is not guaranteed. And usually, the functions will appear in the order they are declared. Along with additional information, however, like pointers to the RTTI, and possibly offset information required to fix up the this pointer when calling the function (although many compilers will use a trampoline for this). For 64 bit g++ under Windows (CygWin version):

struct C
{
    virtual ~C() {}
    virtual void fn1() const { std::cout << "In C::fn1\n"; }
    virtual void fn2() const {}
};

void const*
fn1ToAddr( C const* pC )
{
    void const* const* vPtr = *reinterpret_cast<void const* const* const*>(pC);
    return vPtr[2];
}

fn1ToAddr returns the address of fn1 for the object passed to it; if the object is of type C, it returns the address of C::fn1, and if it is of a derived type which overrides fn1, it returns the address of the overriding function.

Whether this works all of the time or not, I cannot say; I think g++ uses trampolines in cases of multiple inheritance, for example (in which case, the returned address would be the address of the trampoline). And it might not work the next major release of g++. (For the version of MSC I have at hand, replacing the index 2 with 1 seems to work. But again, I only tried very simple cases. There are absolutely no guarantees.)

Basically, you would never want to do anything like this in production code. It can be useful, however, if you're trying to understand how the compiler works.

EDIT:

Re your edit with the why? Just because you have the address (maybe), it doesn't mean that you can call the function. You cannot call a member function without an object, and depending on any number of things, you may not be able to pass the function the object. (With MSC, for example, the object will usually be passed in ECX.)

Answer 3

as mentioned in this wiki page:

Whenever a class defines a virtual function (or method), most compilers add a hidden member variable to the class which points to a so-called virtual method table (VMT or Vtable). This VMT is basically an array of pointers to (virtual) functions.

as far as I know, you don't have access to the Vtable, the compiler doesn't even know the number of entries in the table.