Identify and intercept function call

Question

I'm developing a launcher for a game. Want to intercept game's call for a function that prints text.

I don't know whether the code that contains this function is dynamically linked or statically. So I dont even know the function name.

I did intercepted some windows-api calls of this game through microsoft Detours, Ninject and some others.

But this one is not in import table either.

What should I do to catch this function call? What profiler should be used? IDA? How this could be done?

---

EDIT:

Finally found function address. Thanks, Skino!

Tried to hook it with Detours, injected dll. Injected DllMain:

typedef int (WINAPI *PrintTextType)(char *, int, float , int);

static PrintTextType PrintText_Origin = NULL;

int WINAPI PrintText_Hooked(char * a, int b, float c, int d)
{
    return PrintText_Origin(a, b, c , d);
}

HMODULE game_dll_base;
/* game_dll_base initialization goes here */

BOOL APIENTRY DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    if(fdwReason==DLL_PROCESS_ATTACH)
    {
        DisableThreadLibraryCalls(hinstDLL);
        DetourTransactionBegin();
        DetourUpdateThread(GetCurrentThread());
        PrintText_Origin = (PrintTextType)((DWORD)game_dll_base + 0x6049B0);
        DetourAttach((PVOID *)&PrintText_Origin , PrintText_Hooked);
        DetourTransactionCommit();
    }
}

It hooks as expected. Parameter a has text that should be displayed. But when calling original function return PrintText_Origin (a, b, c , d); application crashes(http://i46.tinypic.com/ohabm.png, http://i46.tinypic.com/dfeh4.png)

Original function disassembly:

http://pastebin.com/1Ydg7NED

After Detours:

http://pastebin.com/eM3L8EJh

EDIT2:

After Detours:

http://pastebin.com/GuJXtyad

PrintText_Hooked disassembly http://pastebin.com/FPRMK5qt w3_loader.dll is the injected dll

Im bad at ASM, please tell what can be wrong ?

Answer 1

Want to intercept game's call for a function that prints text.

You can use a debugger for the investigative phase. Either IDA, or even Visual Studio (in combination with e.g. HxD), should do. It should be relatively easy to identify the function using the steps below:

1. Identify a particular fragment of text whose printing you want to trace (e.g. Hello World!)
2. Break the game execution at any point before the game normally prints the fragment you identified above
3. Search for that fragment of text^† (look for either Unicode or ANSI) in the game's memory. IDA will allow you to do that IIRC, as will the free HxD (Extras > Open RAM...)
4. Once the address of the fragment has been identified, set a break-on-access/read data breakpoint so the debugger will give you control the moment the game attempts to read said fragment (while or immediately prior to displaying it)
5. Resume execution, wait for the data breakpoint to trigger
6. Inspect the stack trace and look for a suitable candidate for hooking
7. Step through from the moment the fragment is read from memory until it is printed if you want to explore additional potential hook points

^{†provided text is not kept compressed (or, for whatever reason, encrypted) until the very last moment}

Once you are done with the investigative phase and you have identified where you'd like to inject your hook, you have two options when writing your launcher:

1. If, based on the above exercise, you were able to identify an export/import after all, then use any API hooking techniques
2. EDIT Use Microsoft Detours, making sure that you first correctly identify the calling convention (cdecl, fastcall, stdcall) of the function you are trying to detour, and use that calling convention for both the prototype of the original as well as for the implementation of the dummy. See examples.
3. If not, you will have to
   • use the Debugging API to programatically load the game
   • compute the hook address based on your investigative phase (either as a hard-coded offset from the module base, or by looking for the instruction bytes around the hook site^‡)
   • set a breakpoint
   • resume the process
   • wait for the breakpoint to trigger, do whatever you have to do
   • resume execution, wait for the next trigger etc. again, all done programatically by your launcher via the Debugging API.

^{‡to be able to continue to work with eventual patch releases of the game}