Author Topic: [WIP] Autodetecting BLHack's aimbot.  (Read 4586 times)

tell me if i have the wrong idea here: couldn't you get what the aim vector would be if you had an aimbot (vector sub between say the target's eyepoint and the player's eyepoint) and vectorDot that with the player's current aim vector and ban them if the returned dot is consistently like 0.97 or above? or is it more complex than that
Isn't that roughly what he's doing?

tell me if i have the wrong idea here: couldn't you get what the aim vector would be if you had an aimbot (vector sub between say the target's eyepoint and the player's eyepoint) and vectorDot that with the player's current aim vector and ban them if the returned dot is consistently like 0.97 or above? or is it more complex than that
Isn't that roughly what he's doing?
with added statistical brown townysis (wip)
sadly it’s the most effective way to detect it beyond human brown townysis (and we all know how effective that is :eyes:)

yes but the very nature of simd means that you can have a computer execute all of those in parallel...? and discussion of simd/mimd/misd/sisd is only ever in the context of parallelization???

That has nothing to do with threads, it's about using the same instructions on 4 (sometimes more) values simultaneously.

Instead of loading two floats from registers and adding them, you load 2 blocks of 4 floats from special simd registers and add those, resulting in a new block of 4 floats. Since that takes about the same time as a normal add, you can massively speed up some math code that needs to do the exact same instruction on different data, like adding 2 vectors or multiplying them.

Btw, this only works on 128-bit blocks, so compiling a normal vector math library that uses 3 floats (96 bits) with sse support actually changes mostly nothing.

and i though you vanished from here(forums) ^^

Update- added source code (thusfar) to the OP.
(my code is super sloppy but i don't have time to rework it.. school's starting again :()
« Last Edit: January 03, 2018, 01:53:45 AM by Metario »


Are you taking ping into account? Players with say, 100 ping may be aiming perfectly aimbot-like but since your server is 100ms in the "future," you're seeing them aim at something that doesn't look like it's the centre of the player.

How about the precision of aiming in general? Do you know how that works from the networking side, and with how much precision your angles are given to the server?

And if you need help with the statistical brown townysis I can help you out. I've taken basic statistics and can probably implement it.
« Last Edit: January 04, 2018, 11:43:30 PM by Ipquarx »

Are you taking ping into account? Players with say, 100 ping may be aiming perfectly aimbot-like but since your server is 100ms in the "future," you're seeing them aim at something that doesn't look like it's the centre of the player.

How about the precision of aiming in general? Do you know how that works from the networking side, and with how much precision your angles are given to the server?

And if you need help with the statistical brown townysis I can help you out. I've taken basic statistics and can probably implement it.
I was looking at interpolation/extrapolation for this purpose, actually, haha. I haven’t gotten around to that (sadly, I don’t have any motivation right now), but, I was looking to add it in. Part of the reason I store velocities in a std::map :P

Precision of aiming- my tolerances for those are around 2/100th of a degree of what the server aimbot gets from the data that should be available to the user- minus the spazzing out. (That was actually related to the tick count of the aimbot being 0, lmao). I haven’t added in lag prediction but from the few people I’ve had test it for false positives, I’ve mostly gotten rid of the majority of them. This isn’t, exactly, well, perfect, or even a product. I know how to implement the lag time stuff, just, no real motivation to keep going at this point. I appreciate the offer of help, but, we’ll see.