Out-of-process hooking.

[wraithZX]

Okay, so I figured I'd actually take my own advice and add a bit of info.

This "tutorial" is going to be a bit light on the specifics, as I'm assuming you know what you're doing.
If you blatantly copy/paste this code without understanding, then come begging for people to fix your mess, you'll be met with laughter and ridicule. You have been warned.

So, out-of-process injection. I've used this successfully in a previous version of my mapping program - specifically hooking into IDirect3DDevice9::EndScene.

A few things you'll need.

1. A brain.
2. Basic knowledge of assembly.
3. Knowledge of reading and writing to remote processes.

The simple pseudocode for my tool for out-of-process hooking was as follows:

1. Pause all running threads in the target process.
2. Find the location of IDirect3DDevice9::EndScene in the remote processes address space.
3. Allocate memory and copy over the function I wish to run.
4. Apply the hook based on the above two locations.
5. Resume all threads.

Simple eh?

Now because I'm going to be nice, I'll put the two stubs I used:

// The detour stub
BYTE detour_stub[] = {
    0xB8, 0xAA, 0xAA, 0xAA, 0xAA,      // mov eax, 0xAAAAAAAA
    0xFF, 0xE0,                        // jmp eax
};

// The loader func we are going to use in order to execute the user code
BYTE loader_stub[] =
{
    0x9C,                            // pushfd
    0x60,                            // pushad
    0x68, 0xBB, 0xBB, 0xBB, 0xBB,    // push 0xBBBBBBBB (function arg)
    0xB8, 0xCC, 0xCC, 0xCC, 0xCC,    // mov eax,0xCCCCCCCC (function address - void Func(void*) )
    0xFF, 0xD0,                      // call eax
    0x83, 0xC4, 0x04,                // add esp,4 (fix up the stack from the function arg)
    0x61,                            // popad
    0x9D,                            // popfd
};

So how do those two interact with each other?

The detour stub replaces the code that we want to hook.
The 0xAAAAAAAA gets replaced with the location of the loader_stub, sitting in the remote process.
The 0xBBBBBBBB gets replaced with a pointer to a block of memory, which I used for RPC.
The 0xCCCCCCCC gets replaced with the location of the actual function we wish to execute.
....and another detour_stub is created with 0xAAAAAAAA replaced with the location we want to jump back to.

So, in the remote process, I'd allocate enough space for:

(loader_stub)
original hooked code
(detour_stub)
payload function we wish to execute
function data - memory used for RPC

I'll assume you can figure out the offsets on all of the above pieces used for allocating memory.

As far as applying the hook is concerned, the sequence then becomes:

1. Write the function payload to the required offset in memory.
2. Copy out the original executable code, then write that data to the required offset in the block of memory.
3. Replace 0xBBBBBBBB with the function data offset from the allocated memory.
4. Replace 0xCCCCCCCC with the payload function offset in the allocated memory.
5. Write the loader stub to the required location.
6. Replace 0xAAAAAAAA with the location of the instruction AFTER the copied bytes in memory.
7. Write the detour stub to the required location in the allocated memory.
8. Replace 0xAAAAAAAA with the location of the loader stub in memory.
9. Write the detour stub to the original code location.

Of course, you'll say: "but I'm not getting the function parameters or anything useful!"
That's what the RPC block of data is for. Put your offsets into a structure from your loader, and write the structure to the allocated memory location.

[flo8464]

Very nice.
I kinda dislike there is no way to hook a function without using Assembly code but well, gotta live with it.

[furang]

Great.
Is this techique's name called splicing (as i remember)?
2flo8464: You need just a little asm. You don't have to learn it perfectly fine for this.

[flo8464]

Great.
Is this techique's name called splicing (as i remember)?
2flo8464: You need just a little asm. You don't have to learn it perfectly fine for this.

No, using ASm is no problem, I just don't like ASM in my C++-application

[Apoc]

No, using ASm is no problem, I just don't like ASM in my C++-application

Then your programs must suck...

[flo8464]

Then your programs must suck...

I guess I don't have to understand what you mean.
Of course I mean I don't like having ASM in my source code.

[bigtimt]

the library i wrote (Voodoo) can call functions OOP without any asm required, you guys should check it out.

[Cypher]

Then your programs must suck...

I don't use inline ASM in any of my programs either. There's pretty much always a way to work around it (like rewriting RtlRemoteCall instead of just dumping bytes into the remote process and starting a new thread), or using compiler intrinsics rather than inline asm, etc.

One exception I do make is the use of AsmJit, but that is an architecture independent ASM generator, so it doesn't have the same restrictions as inline ASM. (As inline ASM is disabled entirely under MSVC when compiling for x64, you have to use FASM to compile ASM files manually then link them into your project, major pain in the ass)