Mid-Hook Function Help [Solved]

The reason being is that a mid-function detour is established at a point where either the arguments haven't yet been processed or that they have but the effect of them being process can be reversed and then re performed with altered arguments. I suppose one could programatically find a convenient place for a mid-function detour but the logic behind locating it would be a complete hell to program(I had to build instruction dependency trees with my polymorhpism engine and it was quite a bit of work on its own.)

It's possible to write a (semi-)universal mid function hook by looking at stackframes. I found that you can easily build a generic approach to midfunction hooking if only you take a few things for granted:

Code:

A static location on the stack is present and known( this can be the previous stack frame, or a static variable)
The function does not alter the variables directly ( only reads their contents )

I made a somewhat generic function to hook members of the d3d library. Having studied the library before writing the function, I knew that all (relevant) functions inside the d3d library install exception handlers. So I used a signature (mov eax, dword ptr fs:[0x4], I think) to find these functions in memory. Once I found the right instruction I replaced them with a call to a special function which walks the stack, allocates a *new* stack and copies the relevant arguments onto it.

It then calls the function you intended to be your main hook, this function can just act as if the stack hasn't been tempered with and use the arguments as it pleases. When it returns we arrive at the function that originally created the stack for the main hook. Depending on how you want to use this scheme you could use this function to copy the new stack over the old, and thus changing the arguments. I've only used it to *spy* on arguments, and not actually change them, since that would indeed require more research and/or your function would no longer be generic.

I used this to hook the DIP function once, it's speed is passable and works flawlessly on the d3d library I was using. So perhaps someone could try this too one day.

Here's the function that created the new stack for the hook function to use (a few things are left out, since it's part of a much larger project and the idea is clear for anyone who is familiar with assembly and who's read the text above)

Code:

PreparePseudoStack proc FistArgument:DWORD, PreviousPseudoStack:DWORD  ; where first argument is the static variable
OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

mov esi, [esp+8h]
cmp esi, 0h
    jne @stillStack

invoke GlobalAlloc, GPTR, 400h
mov PseudoStack, eax
add eax, 200h                                     ; eax = middle of pseudo stack (it can grow and shrink)

@@1:

mov SaveEbp, ebp
mov SaveEsp, esp

xor esi, esi
mov edx, [esp+4]
add esp, 4h
@2:
add esp, 4h
cmp [esp], edx
jne @2                                          ; if past here, esp -> first parameter

sub esp, 4h                                     ; esp -> return address (proper)
mov StackSearch, esp

mov esp, eax
mov ebp, eax 
xor ebx, ebx
mov edx, StackSearch 

@1:

mov ebx, [edx+esi]
mov [esp+esi], ebx

add esi, 4h
cmp esi, 28h
jne @1

push 0
mov ebp, esp                                     ; put everthing in place for usage (first argument always = ebp + 8 (instead of 4) because push ebp in prolog code

mov eax, SaveEsp
mov eax, [eax]
mov Jumper, eax
add SaveEsp, 0Ch                                  ; remove call + 2 arguments
mov eax, PseudoStack                             ; return a pointer to the stack
mov esi, SaveEbp
mov [eax], esi
mov esi, SaveEsp
mov [eax+4h], esi                                ; save origional esp + ebp on the pseudo stack (for DestroyPseudoStack)
jmp Jumper

@stillStack:
mov eax, [esp+8h]
mov PseudoStack, eax
add eax, 200h
jmp @@1

Interesting, the mov eax, dword ptr fs:[0x00] instruction is relevant to the installing of an exception handler - which can be translated usually into a try-catch block as FS:[0x0] points to the first entry in the SEH chain but I don't think FS[0x04] is ever used when installing exception handlers(unless the SEH entry was setup near the top of the stack) in the SEH chain, its probably compiler-dependent but I find exception handlers setup for try-catch blocks are usually setup in the functions stack-frame.

Depending on the calling convention, you could find the function's base of its stack frame, and gather all the arguments passed to it (i.e, you would probably just be able to read EBP to get the stack frame's base regardless to where you were in the function given it was an stdcall or cdecl). Also, the passed arguments typically aren't altered from within the function(unless they're passed via reference) so spying on the stack isn't a bad idea using this method. Altering arguments still would prove a bit more work, and, as I said, probably have no universal method.

Ofcourse, it can be generalized that particular compilers & applications may posses signatures that allow one to programatically locate places for a mid-function detour but that such signatures usually aren't universal and thus it cannot be used as means for universal mid-function detouring.

Interesting method though.

I had forgotten which signature I used exactly to locate a suitable place in the targets function, I think it indeed was mov eax, dword ptr fs[0]

The reason I didn't use ebp to find the previous stack frame here, is because the version of the library I was interested in used edi to save esp. Since I didn't want to assume that the library would always be using edi I chose for a more generic search function to locate my static variables.

Besides I used the TIB of another thread once to locate it's top level SEH and hook it though the 4th offset. But that is another matter entirely

Originally Posted by .::SCHiM::.

I had forgotten which signature I used exactly to locate a suitable place in the targets function, I think it indeed was mov eax, dword ptr fs[0]The reason I didn't use ebp to find the previous stack frame here, is because the version of the library I was interested in used edi to save esp. Since I didn't want to assume that the library would always be using edi I chose for a more generic search function to locate my static variables.Besides I used the TIB of another thread once to locate it's top level SEH and hook it though the 4th offset. But that is another matter entirely

Well where the base pointer is stored (or if it even is) is dependent on the calling convention(and sometimes the compilers as some calling conventions have loose standards), which can vary even from within a library, so the easier route I suppose would have been to look up the calling convention and use signatures to identify them. Anyway, interesting conversation

Alright, I'm out. Getting too complicated for me haha. I really must take the time to learn ASM in more depth one of these days.

Post a Reply

Similar Threads

Tags for this Thread