Understanding Detours and EndScene Hooking

[berlinermauer]

Hello Guys,
I'm a bit confused right now and have some security-related questions.

The first on is: How do you guys Hook EndScene?

I have heard of Microsoft Detours, which requires being an injected dll to WoW.exe
This is the first issue in my eyes: Are there alternatives as enumerating through the MemoryModules would unveal my DLL.
I think about hooking Module32Next to and if there is my DLL just Skipping it. Is this a good Idea or are there complete other methods?

The next thing is: When a Process Loads a Library, then every method in the DLL is load into the Process Memory? So when I use GetProcAddr() I get the Address where the FunctionPointer lies in Memory? If so, why is it called dynamic linked?

Another Point is: I won't try WoW.exe at first, but hooking MessageBoxA / W in notepad.exe. Is this a good Idea, or are the windows executables somehow special and I should consider writing an own Application?

Also: This kind of hooking only applys to Native Code, right?

Ok now let's say EndScene is hooked. What to do? I heard of spawning an CLR and Run my Bot from there, which not really what I wanted to do.
I don't want my whole Code to be in WoW.exe aswell as an CLR, which is a high security-risk in my eyes as well.
Do I have to keep the DLL in WoW.exe? If so, how would you IPC (Inter-Process-Comunicate)? I am thinking about TCPSockets or rather using Pipes?
Another nice try here would be hooking WindowProc and using WindowMessages (WM) but this is as well good detectable if not hooked first (or latest, however called first).

My thoughts would be: a) Inject DLL (no problem) b) Hook Module32Next (and probably Module32First) c) Hook EndScene d) Open Pipe (maybe communicate PipeName (has to be unique, ofc) using WM_XYZ with the Pipename as Param?)

I'm just wondering if there is no complete other Idea which is on top of that easier and more secure (which Injecting DLL is not).

[Empted]

You can manually detour EndScene, writing JMP opcode at the beginning, which will redirect flow to your codecade (that you allocated memory to and wrote needed code at, using ASM jit or using function pointers). Then you execute your code and instructions you replaced with JMP and jump back into endscene. That's very secure, though not that easy to maintain, but very easy to debugg.
So basically process will look like:
-suspend WoW main thread
-allocate memory for your codecave and copy all your code there
-alter EndScene memory page properties to be able to write at
-write jmp opcode at the beginning
-resume thread and probably set all changed properties back
-debugg in Olly or any other debugger to completely control the process
P.S. also you can detour any other frequently called function
P.P.S. if you need your code executed only once you can either make some kind of check in your codecave and synchronize with your application or you can just move replaced bytes at the beginning of EndScene back in your codecave. Though in second variant you'll need to suspend main thread again to execute some code and that will probably hit the stability and performance.

[berlinermauer]

Ok that also sounds nice, though a bit complicated.
I already did that in order to execute FrameScript, but there I just changed EIP to my Code and jumped back.

What I don't now is how to alter EndScenes Memory Page properties?
And how I can debug this using OllyDBG? Just go to the Adress of EndScene and noticeing the changed byte and then follow the jump? therefore I need to know what I'm overwriting to execute bevore jumping to "adressofjmp" + 0x4; (call original detour)
There I also need to check if the beginning is part of an 8byte instruction, in this case the last 8 bytes after the jmp have to be an "nop;" and then I have to save 8 Byte of Code

My Problem is, If i want to call a C# delegate, i'd need to compile all that Code to ByteCode first and then Inject it into my CodeCave, right?

[Empted]

You're understanding it quite right.
By altering properties i mean calling VirtualProtectEx API, if you don't do this, you'll probably fail when trying to write at the .txt section adress or you'll generate an exception when trying to change all bytes back in your codecave.

Calling C# code can be not that easy, this will require you to map CLR into WoW process. I use ASM Jit (fasm dll by Shynd) personally. So i code in ASM and then fasm compiles it and writes it into codecave. I don't know the easy way to call C# functions without CLR. Also if you code in C++ you can get pointer to your function and just map it to WoW process or just see what code compiler has generated for it and just inject that byte array. Any thing you like.

P.S. you don't need really much code in your codecave. Usually you just need to call some WoW fucntion like CTM or FrameScriptExecute. So basically my code looks like:
C# code
CallByDetour(WoWFunc, params)
C# code
P.P.S. don't really pay that much attention at starting instructions at the beginning of func being detoured. Just see them in Olly and execute them and correct return adress manually. If you want to detour several functions then you'll probably need to examine opcodes.

[berlinermauer]

I Guess I'll try Detouring it first before doing it the "hard" way.
Where can I find the declaration of EndScene and how are the three Pointers treated in order to get EndScene()?

[Empted]

Just to make a try, i recommend detour RenderWorld func (you can find it's offset in the dump thread), so it will be easier to find it in debugger.

[berlinermauer]

Well I am now about to Open a PIPE from the Hooked Context to interact this way, even though a small CLR would be pretty nice. On top of that A DLL shouldn't be such a problem since the Logitech G15 is also a dll.

Nevertheless: I am encountering Problems with RenderWorld. The given offset leads me to a .text Segment without the Execute Permission.
Also I need the prototype of EndScene and / or RenderWorld.

Another thing: This FASM thingy sounds nice, although I would neeed to align my "jump to original function" again everytime I write to the cave. What's happening if I write to the cave when it is called? Of course Problem #1 can be changed by allocating a second codecave, but the question what happens if I change "a running system" is still there. Shouldn't I always pause the MainThread?

[berlinermauer]

Ok I implemented fasm and now hooking and getting back return values works.
At least with MessageBoxA. Now I'm planning to Hook EndScene.

My Problem is: Since I am not going to use C++ but Assembler, I cannot use any kind of SDK. Is it true that for example DrawRect() has in WoW the Same Adress as LoadLibrary("d3d9.dll"), GetProcAddr()? If it is this case, it's nearly as easy as using c++

Edit: Hooking and DoString worked now... until I called GetLocalizedText wrong and WoWError appeard once.
Now it seems that everytime after the first working DoString my hook never gets called again or at least the DoString is ignored/fails.

****: after being Hooked a few minutes, it suddenly works?! Is WoW stopping this while scanning who called DoString and analyzing me, while provokating many dostrings?

Fixxed: I did not zero the memory so the old instructions destroyed the new one (maybe?) and a stack error causing to jump completely wrong