Remote function call, calling convention?

[lweid]

First of all I understand that I am new to this community, and if you do not want to answer my question because I have not given anything back to this community as of yet, I understand. However hopefully in time, and learning, I can give something back

Yesterday I was able to (first time for me) inject a dll into a target process, at first I played around with a 'hackme' test dummy application before I jumped right in to messing with World of Warcraft.

Upon injecting code into my test dummy application, I used the MessageBox() api to let me know that DLL_PROCESS_ATTATCH was currently in execution flow, then I had a test function inside of my test dummy app, which for the sake of simplicity we will say the call procedure lies at 0xDEADBEEF.

I used this method to call the function

DWORD location=0xDEADBEEF;

__asm
{
CALL location
}

that was the best I could come up with, and it worked. The function was called in the target application, with no deadlocks and no crashes.

Its a different story with WoW however.

I have a certain function that I chose from TOM_RUS' post of 4.0.6 static data.

I know that my injection works, it gets to the the MessageBox() api, however it crashes out after that, which is where the asm function call is located.


so basically what I need to know here is, am I using the proper calling convention? What am I missing and what am I doing wrong?

[IceFire32]

I didn't read ur post very carefully now (sorry :b), but maybe it would be helpful if you'd say us which function u want to call. It's not the same for all the functions.

/edit:
To give you a short example (untested and YES, it IS dirty code-style :b)

#define ChatFrame_AddMessage 0x00455F80

void AddChatMessage(std::string text)
{
   char *szPTR = (char*)text.c_str() ;
   DWORD dwFunc = (DWORD)GetModuleHandle(NULL) + ChatFrame_AddMessage ;
   __asm
   {
      push 0
      push 0
      push szPTR
      mov eax, dwFunc
      call eax
      add esp, 0x0C
   }
}

Btw you can also use function pointers to call remote functions.

[lweid]

I didn't read ur post very carefully now (sorry :b), but maybe it would be helpful if you'd say us which function u want to call. It's not the same for all the functions.

/edit:
To give you a short example (untested and YES, it IS dirty code-style :b)

#define ChatFrame_AddMessage 0x00455F80

void AddChatMessage(std::string text)
{
   char *szPTR = (char*)text.c_str() ;
   DWORD dwFunc = (DWORD)GetModuleHandle(NULL) + ChatFrame_AddMessage ;
   __asm
   {
      push 0
      push 0
      push szPTR
      mov eax, dwFunc
      call eax
      add esp, 0x0C
   }
}

Btw you can also use function pointers to call remote functions.

Wow thanks for the fast reply

is it necessary to use the eax register? like you did in your sample?

[IceFire32]

Nope, you can also use "call dwFunc" directly, don't ask my why I did it like that ;p

/edit:

#define ChatFrame_AddMessage 0x00455F80
typedef DWORD(__cdecl *pFunc_t)(char *szText, DWORD dwUnk, DWORD dwUnk2) ;

void AddChatMessage(std::string text)
{
   pFunc_t pFunc = (pFunc_t)((DWORD)GetModuleHandle(NULL) + ChatFrame_AddMessage) ;
   pFunc((char*)text.c_str(), 0, 0) ;  
}

With a typedef it'd look like this

[lweid]

Oh I should post the function I was trying to call "which I chose at random" is

617320 CGUnit_C::PlayEmoteSound

Not entirely sure how you pass arguments with asm, but you dont need to tell me, I can figure that out on my own.

Was just wondering if I need to call that function by name directly or not.

[_Mike]

617320 CGUnit_C::PlayEmoteSound

Do note that CGUnit_C is a C++ class, so you have to use thiscall convention and feed it with a valid class pointer.
You might want to start with a "normal" cdecl function first if you're trying to learn the basics. Oh, and I wouldn't call it _remote_ function calling if you're calling it from within the same process

Not entirely sure how you pass arguments with asm, but you dont need to tell me, I can figure that out on my own.

Don't. Function pointers are there for a reason.

And read x86 calling conventions - Wikipedia, the free encyclopedia if you haven't already.

[lweid]

Do note that CGUnit_C is a C++ class, so you have to use thiscall convention and feed it with a valid class pointer.
You might want to start with a "normal" cdecl function first if you're trying to learn the basics. Oh, and I wouldn't call it _remote_ function calling if you're calling it from within the same process


Don't. Function pointers are there for a reason.

And read x86 calling conventions - Wikipedia, the free encyclopedia if you haven't already.

thank you _Mike

I will definitely read that.

IceFire32, thank you much for the example

[amadmonk]

Please be aware that there are a number of customcall functions in WoW, which you're simply not going to ever be able to call correctly using standard calling conventions. With customcall (don't know if there's an "official" name for this calling convention that, really, ISN'T a calling convention...) you have to reverse the function and look at its usage to know how to handle params, which registers are volatile, etc. Pray you don't run into these functions

I don't believe, however, that any of the "usual" offsets found per patch use customcall.

[Cypher]

Please be aware that there are a number of customcall functions in WoW, which you're simply not going to ever be able to call correctly using standard calling conventions. With customcall (don't know if there's an "official" name for this calling convention that, really, ISN'T a calling convention...) you have to reverse the function and look at its usage to know how to handle params, which registers are volatile, etc. Pray you don't run into these functions

I don't believe, however, that any of the "usual" offsets found per patch use customcall.

Pray also that Blizzard don't decide to start setting their compiler to use IPO/PGO/etc more aggressively.

[amadmonk]

Yeah, I'm kinda hoping that too.

[lweid]

Another question, in most cases of the injected module being (far lack of a better term) kicked back out after an attempted call to a function, but WoW does not crash. Would this most likely mean I have messed up the params/return type? Or is it because my function pointer is pointing to something that isnt the beginning of a procedure?

thanks

edit-

i should add. I usually stick to cdecl, most of the time it just kicks my library back out. but i fear its because I have messed up the parameters.

[amadmonk]

Seriously, if you don't know the calling convention, you're doing it wrong. Either stick to offsets that other people have reversed (and for which you know the cconv), or reverse it yourself.

Just wildly flailing around trying different random cconv's is a non-starter.