__thiscall convention question, whilst injected.

[lweid]

So thanks to alot of you on this forum, I have been able to write alot of different tools and also learn a great deal. To name a few _Mike, amadmonk, and icefire32 (Ende) calling a function that does not use the _thiscall convention is easy to set up with a typedef and a function pointer.

I can easily reverse a function that uses _thiscall, and then I know to retrieve the (hidden) so to speak*this pointer that is passed when invoking a member function.

However what I do not understand is, what would a typedef look like for this kind of function, would I need to include *this as an argument? Also, how can I feed it a valid class pointer?

Thanks

[namreeb]

In C# it looks something like this:

        [UnmanagedFunctionPointer(CallingConvention.ThisCall)]
        private delegate IntPtr SendGameDataDelegate(IntPtr thisPtr, IntPtr bufferPtr, bool boolean);

Where the 'thisPtr' variable corresponds to the ECX register. The other two parameters are normal.

[Bananenbrot]

You can just use normal member function syntax.

class Obj
{
public:
    int Foo(int i) { return i; }
}
 
// could use __thiscall to make it explicit
typedef void (__thiscall Obj::*FooPtr)(int);
 
int main(int argc, char* argv[])
{
    Obj obj;
    FooPtr ptr = &Obj::Foo;
 
    int i = (obj.*ptr)(5);
   assert(i == 5);
 
    // or with pObj as synonym for the this ptr: 
    Obj* pObj = &obj;
    i = (pObj->*ptr)(5);
 
   assert(i == 5);
}

This works as long as WoW's compiler uses the same calling conventions as yours.
They use some version (together with runtime version 8.0) of MS' compiler, so you will be perfectly fine with using visual studio.
Just remember, GCC uses a different thiscall calling convention (http://www.mmowned.com/forums/world-...n32-mingw.html).

Edit: code format is ****ed up...

[lweid]

Thanks for the help namreeb much appreciated

Bananenbrot you too, Im not sure if you were just trying to paint me a clear picture to help me understand better (which you did ) however correct me if im wrong here maybe im just retarted, but my function would need the address of an actual WoW subroutine yes? And it would also then need to use the ECX register for the *this pointer to the object. Unless of course you guys are somehow "emulating" the object based off alot of analysis or something.

My typedef in cpp looks like this -

typedef DWORD(__thiscall *mfunc)(Obj *pThis, DWORD a1, DWORD a2);

and then since im injected, I set it manually like this -

mfunc funct=(mfunc)((DWORD)GetModuleHandle(NULL)+import[13]);

// import[13] is the offset of this subroutine

so what I dont understand here is, should I be using some "place holder" so to speak object for the *this parameter and then just obtain ECX and pass it?

[_Mike]

I'm not sure what you mean by placeholder.
Say you're trying to call one of the CGUnit_C methods.. You just pass the address* of the unit object as the first parameter.
You don't have to worry about manually setting registers. The compiler will know to pass the first parameter (pThis in your case) in ecx when you declare the function pointer as thiscall.

*) There are tons of posts here on how to get these addresses. Just search for any of the object manager threads.

[lweid]

thanks _Mike, that all makes sense to me, I also have the location of this object already. So what I am still not sure on, is what the data type needs to be for the parameter of that first argument? can it just be an unsigned int*?

so then the typedef would look like -

typedef DWORD(__thiscall *mfunc)(DWORD *pThis, DWORD a1, DWORD a2);

and the call would look like (after the function pointer has been assigned a proper location), and 0xdeadbeef is the object -

dwFunc((DWORD*)0xdeadbeef,0,0)

assuming what you said before, that the compiler knows to pass ecx the pointer to said object.

or am i still brain dead :P

[_Mike]

thanks _Mike, that all makes sense to me, I also have the location of this object already. So what I am still not sure on, is what the data type needs to be for the parameter of that first argument? can it just be an unsigned int*?

Technically it should be a class pointer of the type of class that the function is a member of. But any pointer type (or any data type with the same size as a pointer, but beware of portability issues) works.

so then the typedef would look like -

typedef DWORD(__thiscall *mfunc)(DWORD *pThis, DWORD a1, DWORD a2);

and the call would look like (after the function pointer has been assigned a proper location), and 0xdeadbeef is the object -

dwFunc((DWORD*)0xdeadbeef,0,0)

assuming what you said before, that the compiler knows to pass ecx the pointer to said object.

or am i still brain dead :P

Correct for MSVC. GCC does it a bit differently, see Bananenbrot's link above for details if that's what you're using.

[lanman92]

Whenever I used a prototype as such, MSVC threw an error. I had to use inline asm to get the results I wanted. Completely possible that I was doin' it wrong though.

[lweid]

Thanks again _Mike, much appreciated.

Also lanman, that happens to me too sometimes, to which i just resort to inline asm and it always works out in the end. Its a messy way of doing things but for me its just a hobby and a way to learn more.

[amadmonk]

Class inner method pointer typedefs have been pretty much a black art (at least until the advent of the STL function pointers wrappers). I'm not surprised the compiler puked. I did the testing on ISO compatibility for class inner pointers back on MSVC 2k3, and there were a LOT of ICE's (internal compiler errors) back in the day...

[Cypher]

Class inner method pointer typedefs have been pretty much a black art (at least until the advent of the STL function pointers wrappers). I'm not surprised the compiler puked. I did the testing on ISO compatibility for class inner pointers back on MSVC 2k3, and there were a LOT of ICE's (internal compiler errors) back in the day...

If you think the STL binders are cool, you should check out Phoenix v3.