[C++] VEH performance

[z0m]

I was testing this in a different game than WoW, but under the assumption that it's the same I decided to post my question here.

Is VEH just really slow? I counted in some performance loss, but the FPS loss is immense (at times I'm keeping less than 5% of the original FPS, average seems to be 15%). I was messing around with a few alternatives to standard mid-function hooks and after reading some posts at a few common websites I looked at the MSDN docs for the information to create a simple implementation. I already compared my code to some quick sample codes that I found during my search and there is nothing worth noting in those that could cause this.
The method is mentioned fairly often, which is why I got curious on checking it out. It's also easy to check against from an anti-cheat pov (not counting in how easy most anticheats are when it comes to bypassing them) so I'm just not really able to think of any situations where this method would beat the alternatives. What do you guys use it for?

[Jadd]

How often are your breakpoints hit by the rendering thread? It just sounds to me like your code is too intensive and is being executed more often than you think.

[Cypher]

Sounds to me like he's using VEH for his EndScene hook.

[z0m]

Somewhat close to it. It's actually an older game (still played quite a fair bit, FPS to be exact) that originally came with DX8 and has a wrapper for DX9 support. I used it to hook SetProjectionMatrix (in the wrapper class), but it's going (in the menu) from 800 to ~90 fps, even when I don't execute any code on it. I could see this being useful for some quick solutions on code that is only ran rarely (say to clean a screenshot) as it takes less effort than a mid-function hook, but since chain hooking takes merely seconds of looking at the assembly, I doubt it's much of a timesaver.

Like I said, I'm merely wondering what a good usecase is, as it seems to just be an alternative that can be stopped easily and doesn't carry all that many benefits. Was hoping someone could give a sample (not code, but a situation) of it's use. There is absolutely 0 info about this game, so it's a nice playground and I was merely giving it a go as I had a project to actually try it out with now. With a normal midfunction hook there is (obviously) no performance loss, and I really can't see the implementation I made draining that many resources compared to a c&p-version (which do the exact same anyway).

(FYI: the hack (common ESP, aimbot, network exploits to buttrape people as admin etc) is working fine as it is, that's not an issue)

[zys924]

If you are using VEH via INT3, why bother that since the memory writing is unavoidable? Simply can use JMP or RETN hook without VEH to increase performance.

[Master674]

If you are using VEH via INT3, why bother that since the memory writing is unavoidable? Simply can use JMP or RETN hook without VEH to increase performance.

SuspendThread(hThread);
CONTEXT ctx = {0};
GetThreadContext(hThread, &ctx);
ctx.EFlags |= 0x100;
SetThreadContext(hThread, &ctx);
ResumeThread(hThread);

DWORD dwOldProtect = 0;
// Will always protect a whole page ofcourse...
VirtualProtect(lpAddress, 0x1, PAGE_NOACCESS, &dwOldProtect);

[zys924]

SuspendThread(hThread);
CONTEXT ctx = {0};
GetThreadContext(hThread, &ctx);
ctx.EFlags |= 0x100;
SetThreadContext(hThread, &ctx);
ResumeThread(hThread);

DWORD dwOldProtect = 0;
// Will always protect a whole page ofcourse...
VirtualProtect(lpAddress, 0x1, PAGE_NOACCESS, &dwOldProtect);

Yes, indeed.

The second approach always triggers unwanted exceptions which seems to me a foul choice.

The first DR hook is sth I have never tried. But seems to be the most secure one.

[suicidity]

Setting an entire page to NOACCESS will definitely slow things to a crawl, and setting the ThreadContext is NOT safe if the game has a respectable anti-cheat.. but you did say it's really old.


The slow down is going to be caused by:
1. How you're breakpointing.
2. How many times it breakpoints.

By the sounds of it SetProjectionMatrix is being called A LOT.

[z0m]

You kind of summarizes what I already figured myself, the question was what a possible usecase could be .

[sitnspinlock]

[QUOTE=Master674;2632879]

SuspendThread(hThread);
CONTEXT ctx = {0};
GetThreadContext(hThread, &ctx);
ctx.EFlags |= 0x100;
SetThreadContext(hThread, &ctx);
ResumeThread(hThread);

wutisthisidonteven :confused:

[Master674]

[QUOTE=everdox;2635361]

SuspendThread(hThread);
CONTEXT ctx = {0};
GetThreadContext(hThread, &ctx);
ctx.EFlags |= 0x100;
SetThreadContext(hThread, &ctx);
ResumeThread(hThread);

wutisthisidonteven :confused:

Singlestepping through the whole code. You still wont get more than like 1-5% of original performance since it will raise an exception on every instruction. In handler you always reset the trap flag.

[DrakeFish]

You kind of summarizes what I already figured myself, the question was what a possible usecase could be .

Well of course as you already know using a simple branch will be a lot faster than using a VEH hook because of the exception, but using VEH would be a useful alternative if what you are looking for is to handle the access to some parts of memory, may it be by using hardware breakpoints or by changing a page's protection. I've been hooking dx9 EndScene function (which is called once every frame) with one before, and didn't see any performance issue.

Some debuggers (like CE) offer VEH debuggers, which are in fact an injected DLL that communicates with the debugger, making you able to handle breakpoints without attaching a debugger to the application you are debugging. This is a working alternative for some games that detect debuggers but won't detect the breakpoints.

[sitnspinlock]

[QUOTE=Master674;2635953]

Singlestepping through the whole code. You still wont get more than like 1-5% of original performance since it will raise an exception on every instruction. In handler you always reset the trap flag.

i know son. i'm pondering why oh why it's in this thread though. i didn't know the OP wanted to run a trace with veh ;p