External aim assists

[Baker]

I stumbled upon a very active place on the internet that does nothing but make cheats for games. Sigh.

Most of them were OpenGL and DirectX cheats, with some other category of cheats that I guess somehow hooks into games and other weirdness.

Quake isn't exactly a popular game anymore, so I imagine most of these cheats are rotting on vine and the slightest twist would make them useless.

My guess is that these OpenGL cheats generally work like this:

1. The cheat gets called at rendering time via the OpenGL api calls that aren't exactly the real ones.
2. The cheat dll determines where a model or enemy is nearest the crosshair.
3. Makes a calculation of the correct angle/roll/pitch for that position to be dead-center.

Now here is where I am lost ...

How are these cheats writing the angle?

Do they have to be pre-programmed with the memory address offset to overwrite the existing angle and alter the game's memory?
Or ... are they overriding outbound network data? (The latter seems like too much work).

I'm assuming this is where the client's memory is being altered, right? If so, wouldn't the slightest difference in version or the mildest change in the data structure or network protocol disable existing cheats?

Or am I wrong?

[r00k]

Could it be the dll is mimicing a clc_move to the server?
this reads input (movement and aim) from the client.

[Spike]

QuakeWorld/Quake2 have checksum bytes in the protocol in an attempt to prevent proxies.

Of course, this is completely moot when you remember the engine is open source now.

Here's the fun thing, movement directions are based on the direction you are facing. That is, if you have an aimbot that is adjusting the angles, it has to adjust movement too, or prediction will break horribly.
Quite frankly, its so much easier to just change the angle in the engine, but then your player has to move relative to the angle the aimbot wants them to face.
So you can generally tell which one it is easily enough.
If its rewriting network packets, its easier to insert a large chunk of code as and when the engine would normally send them.
Its quite a lot of maths for a properly usable aimbot. Its actually a good one to learn practical 3d maths, especially when you consider prediction too. :)

OpenGL hacks are easy to make to get wallhacks working. Extreemly easy in Quake, where there is a clear distinction between models and world.

Finding out the offsets of the view angles isn't really all that hard. Just search for the number 508 in the code and you're in the right sort of area. I won't say more than that though. :)

If the aimbot is using hard-coded offsets to adjust the angles, then yes, just compile the engine yourself with different optimisations and it'll break the aimbot.
If the aimbot is playing with network code, then you would need to change the protocol somehow, which is of course a pain. Otherwise there is nothing you can do to actually detect it programatically.
There's not much you can do about wallhacks short of rewriting the entire renderer with a single wallhack in mind.

You can just change the protocol if you really want, but many of the aimbots on the 'net are distributed as diffs to the engine.

[Baker]

Thanks for the info Spike.

/Many of the ProQuake servers have been running the anti-wallhack stuff from FTE for a while (I couldn't quite get a handle on the DarkPlaces method). The rest of the ones running anti-wallhack use a method Rook wrote where he managed to get it down to a single function.

[r00k]

mostly that single function loops a trace against SV_ClipMoveToEntity before any entities are sent to the client. Costly in cpu but i didnt have to work much against existing code..
MH has written a nifty z-buffer method that works client-side to boot.

[mh]

I'd guess these cheats are looking out for a pointer being used somewhere, and intercepting & overwriting that. Difficult to see why anyone would pass a live aim vector pointer to a rendering API, but I suppose there have been enough bad coding practices in the past, and I can't really see any other way.

It would be interesting to see if changing the render to always send a copy of data (rather than actual live data) to the API would break the cheats, but I for one would be terrified of what other filth I might install on my PC if I was to test it out.

Oddly, I didn't find r00k's anti-wallhack to be CPU expensive at all; in a reasonably well-balanced system (which I figure I must have ) what you lose in CPU you tend to gain back from not having to render the extra ents (if you're GPU bound the gain will be even more).