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

Metario · December 26, 2017, 12:50:17 AM

I've spent the past few days looking over the source code and checking over a bunch of stupid steps, and I think I've found a way to detect BLHack's aimbot, automatically, from a DLL.
How?
In short, I predict where the aimbot will want to aim at, and compare against the player's ACTUAL aim, and add in a bit of variation to determine if the movement they've just done is humanly possible. Yes, there are false positives, however, I'm hoping that with several community leaders testing this DLL, and reporting feedback, that I'll be able to improve it to make it absolutely fool-proof (within reason...).

If you wish to contribute/get a copy of the DLL/have it demonstrated to you, please PM me, and I'll try to get back to you as soon as possible.
This is just a proof of concept ATM.

No, this doesn�t evaluate any code on the client-side. No, this doesn�t need to be run on a client. This is purely server-sided, and doesn�t interact with the client, merely, reading the data the client sends.

PoC (with BLHack): https://gfycat.com/VigorousDesertedIslandcanary

PoC (keyboard turning, legitimate): https://gfycat.com/MatureChiefEastsiberianlaika

Source: https://github.com/ohninedotseven/BLAC

Ad Bot · Advertisement

Metario · December 26, 2017, 01:29:40 AM

-snip-

phflack · December 26, 2017, 08:46:12 PM

why does this need to be a DLL?
just so it's faster?

Metario · December 26, 2017, 08:53:36 PM

Quote from: phflack on December 26, 2017, 08:46:12 PM

why does this need to be a DLL?
just so it's faster?

yeah- for a bit of it. since we're doing large amounts of vector math and we're scanning through the clientgroup, i found it was easiest just to do it in a dll instead of having it in torquescript- and faster, as well as i already had a dll base that had a bunch of utilities handy haha

rggbnnnnn · December 26, 2017, 09:59:50 PM

Seems promising. Excited for the future.

Gytyyhgfffff · December 27, 2017, 12:04:40 AM

https://pastebin.com/raw/mnnDdH7f

vector math isn't that slow though as is looping through at most 30 clients so why isn't this a torquescript add-on? i guess it could merit a .dll depending on how much vector math you're doing but it shouldn't be that much. if it was in ts it would be way more accessible and i think losing a few thousand nanoseconds just to make the detector more accessible would be worth it

after looking through how many calls it would take to use up 1 ms of time it is actually very low. for vectorAdd, it would take only 155 calls to take up 1 ms which is pretty forgetin autistic. it just depends on how much vector math you're doing

holy stuff after doing more benchmarks because i couldn't believe how slow of results i was getting i learned that it takes 2700 nanoseconds to parse two arguments. thank you torquescript

that being said if you do some really gimmicky solutions you could get this to run really well in torquescript but the amount of effort it would take to do something like that is probably too unreasonable

holy stuff i like how this post starts out with me saying torquescript isn't that bad and ends with me calling torquescript autistic

Metario · December 27, 2017, 01:57:59 AM

Quote from: Gytyyhgfffff on December 27, 2017, 12:04:40 AM

https://pastebin.com/raw/mnnDdH7f

vector math isn't that slow though as is looping through at most 30 clients so why isn't this a torquescript add-on? i guess it could merit a .dll depending on how much vector math you're doing but it shouldn't be that much. if it was in ts it would be way more accessible and i think losing a few thousand nanoseconds just to make the detector more accessible would be worth it

after looking through how many calls it would take to use up 1 ms of time it is actually very low. for vectorAdd, it would take only 155 calls to take up 1 ms which is pretty forgetin autistic. it just depends on how much vector math you're doing

holy stuff after doing more benchmarks because i couldn't believe how slow of results i was getting i learned that it takes 2700 nanoseconds to parse two arguments. thank you torquescript

that being said if you do some really gimmicky solutions you could get this to run really well in torquescript but the amount of effort it would take to do something like that is probably too unreasonable

holy stuff i like how this post starts out with me saying torquescript isn't that bad and ends with me calling torquescript autistic

Code: [Select]

==>dll_runBench();
% [==========] Running 3 benchmarks.
[ RUN      ] Benchmarks.VectorAdd (10 runs, 10000 iterations per run)
[     DONE ] Benchmarks.VectorAdd (0.157260 ms)
[   RUNS   ]        Average time: 15.726 us (~16.894 us)
                    Fastest time: 2.476 us (-13.250 us / -84.255 %)
                    Slowest time: 37.276 us (+21.550 us / +137.034 %)
                     Median time: 3.276 us (1st quartile: 2.476 us | 3rd quartile: 36.776 us)
                                  
             Average performance: 63588.96096 runs/s
                Best performance: 403877.22132 runs/s (+340288.26037 runs/s / +535.13732 %)
               Worst performance: 26826.91276 runs/s (-36762.04820 runs/s / -57.81200 %)
              Median performance: 305250.30525 runs/s (1st quartile: 403877.22132 | 3rd quartile: 27191.64673)
                                  
[ITERATIONS]        Average time: 0.002 us (~0.002 us)
                    Fastest time: 0.000 us (-0.001 us / -84.255 %)
                    Slowest time: 0.004 us (+0.002 us / +137.034 %)
                     Median time: 0.000 us (1st quartile: 0.000 us | 3rd quartile: 0.004 us)
                                  
             Average performance: 635889609.56378 iterations/s
                Best performance: 4038772213.24717 iterations/s (+3402882603.68339 iterations/s / +535.13732 %)
               Worst performance: 268269127.58880 iterations/s (-367620481.97498 iterations/s / -57.81200 %)
              Median performance: 3052503052.50305 iterations/s (1st quartile: 4038772213.24717 | 3rd quartile: 271916467.26126)
[ RUN      ] Benchmarks.VectorScale (10 runs, 10000 iterations per run)
[     DONE ] Benchmarks.VectorScale (0.175160 ms)
[   RUNS   ]        Average time: 17.516 us (~16.306 us)
                    Fastest time: 2.376 us (-15.140 us / -86.435 %)
                    Slowest time: 36.776 us (+19.260 us / +109.957 %)
                     Median time: 10.176 us (1st quartile: 2.476 us | 3rd quartile: 36.676 us)
                                  
             Average performance: 57090.65997 runs/s
                Best performance: 420875.42088 runs/s (+363784.76091 runs/s / +637.20539 %)
               Worst performance: 27191.64673 runs/s (-29899.01324 runs/s / -52.37111 %)
              Median performance: 98270.44025 runs/s (1st quartile: 403877.22132 | 3rd quartile: 27265.78689)
                                  
[ITERATIONS]        Average time: 0.002 us (~0.002 us)
                    Fastest time: 0.000 us (-0.002 us / -86.435 %)
                    Slowest time: 0.004 us (+0.002 us / +109.957 %)
                     Median time: 0.001 us (1st quartile: 0.000 us | 3rd quartile: 0.004 us)
                                  
             Average performance: 570906599.68029 iterations/s
                Best performance: 4208754208.75421 iterations/s (+3637847609.07392 iterations/s / +637.20539 %)
               Worst performance: 271916467.26126 iterations/s (-298990132.41903 iterations/s / -52.37111 %)
              Median performance: 982704402.51572 iterations/s (1st quartile: 4038772213.24717 | 3rd quartile: 272657868.90610)
[ RUN      ] Benchmarks.VectorDot (10 runs, 10000 iterations per run)
[     DONE ] Benchmarks.VectorDot (0.237060 ms)
[   RUNS   ]        Average time: 23.706 us (~20.698 us)
                    Fastest time: 6.776 us (-16.930 us / -71.417 %)
                    Slowest time: 47.776 us (+24.070 us / +101.535 %)
                     Median time: 9.476 us (1st quartile: 6.876 us | 3rd quartile: 47.676 us)
                                  
             Average performance: 42183.41348 runs/s
                Best performance: 147579.69303 runs/s (+105396.27955 runs/s / +249.85242 %)
               Worst performance: 20931.01139 runs/s (-21252.40210 runs/s / -50.38094 %)
              Median performance: 105529.75939 runs/s (1st quartile: 145433.39151 | 3rd quartile: 20974.91400)
                                  
[ITERATIONS]        Average time: 0.002 us (~0.002 us)
                    Fastest time: 0.001 us (-0.002 us / -71.417 %)
                    Slowest time: 0.005 us (+0.002 us / +101.535 %)
                     Median time: 0.001 us (1st quartile: 0.001 us | 3rd quartile: 0.005 us)
                                  
             Average performance: 421834134.81819 iterations/s
                Best performance: 1475796930.34238 iterations/s (+1053962795.52420 iterations/s / +249.85242 %)
               Worst performance: 209310113.86470 iterations/s (-212524020.95349 iterations/s / -50.38094 %)
              Median performance: 1055297593.92149 iterations/s (1st quartile: 1454333915.06690 | 3rd quartile: 209749140.02853)
[==========] Ran 3 benchmarks.

it's pretty slow....
https://pastebin.com/raw/FVzcPZBm

also the reason it's slow is because it's doing this

Code: [Select]

ConsoleFunction( VectorAdd, const char*, 3, 3, "(Vector3F a, Vector3F b) Returns a+b.")
{
   VectorF v1(0.0f,0.0f,0.0f),v2(0.0f,0.0f,0.0f);
   dSscanf(argv[1],"%g %g %g",&v1.x,&v1.y,&v1.z);
   dSscanf(argv[2],"%g %g %g",&v2.x,&v2.y,&v2.z);
   VectorF v;
   v = v1 + v2;
   char* returnBuffer = Con::getReturnBuffer(256);
   dSprintf(returnBuffer,256,"%g %g %g",v.x,v.y,v.z);
   return returnBuffer;
}

ConsoleFunction( VectorScale, const char*, 3, 3, "(Vector3F a, float scalar) Returns a scaled by scalar (ie, a*scalar).")
{
   VectorF v(0.0f,0.0f,0.0f);
   dSscanf(argv[1],"%g %g %g",&v.x,&v.y,&v.z);
   v *= dAtof(argv[2]);
   char* returnBuffer = Con::getReturnBuffer(256);
   dSprintf(returnBuffer,256,"%g %g %g",v.x,v.y,v.z);
   return returnBuffer;
}

ConsoleFunction( VectorDot, F32, 3, 3, "(Vector3F a, Vector3F b) Calculate the dot product of a and b.")
{
   VectorF v1(0.0f,0.0f,0.0f),v2(0.0f,0.0f,0.0f);
   dSscanf(argv[1],"%g %g %g",&v1.x,&v1.y,&v1.z);
   dSscanf(argv[2],"%g %g %g",&v2.x,&v2.y,&v2.z);
   return mDot(v1,v2);
}

since torque passes vector3fs around as strings and not just having a class with tostring, it has to parse them from the arguments and that's the main thing slowing it down lol
wish it didnt do it like this

Kyuande · December 27, 2017, 06:23:18 PM

Those console functions hurt my brain

Ibaminus · December 27, 2017, 06:25:29 PM

Quote from: Kyuande on December 27, 2017, 06:23:18 PM

Those console functions hurt my brain

Metario · December 27, 2017, 11:26:57 PM

Quote from: Kyuande on December 27, 2017, 06:23:18 PM

Those console functions hurt my brain

Welcome to my life for the past few days

Update: finished working on velocity stuffs, integrated into the DLL.. added server package. There is also now a user-definable callback.. Arguments/fields are as follows:

Code: [Select]

function onPlayerSuspMove(%player, %move){
%realX = getWord(%move, 0); //The real yaw of the player..
%realY = getWord(%move, 1); //The real pitch of the player..
%predX = getWord(%move, 2); //The predicted yaw of the player
%predY = getWord(%move, 3); //The predicted pitch of the player
%diffX = getWord(%move, 4); //The difference between the predicted yaw and the real yaw
%diffY = getWord(%move, 5); //The difference between the predicted pitch and the real pitch
}

I�m still trying to constantly improve this, as well as integrate some statistical brown townysis (later on..), so, the more testers I get, the faster I can get this up and working. Currently, the DLL takes advantage of SSE4.1, and SIMD to increase the performance of the vector operations, so, at the very least, one core is recommended (dedicated to BL lol). I have no clue on the performance hit with 10+ players- and, if someone is willing to test drive it on such a server, I�d be happy.

Conan · December 27, 2017, 11:56:16 PM

you can get the engine to do simd parallelization?? wtf?? i thought bl was forced single thread

if it really is simd u should see practically no performance hit

Metario · December 28, 2017, 03:15:31 AM

Quote from: Conan on December 27, 2017, 11:56:16 PM

you can get the engine to do simd parallelization?? wtf?? i thought bl was forced single thread

if it really is simd u should see practically no performance hit

no lol all my vector math is through a dll
the dll is compiled with sse support and the math lib that i use takes advantage of simd parallization, it�s the only way i can get >1ms times for our benchmarks

FelipeO_O_ · December 28, 2017, 06:32:59 AM

Quote from: Conan on December 27, 2017, 11:56:16 PM

you can get the engine to do simd parallelization?? wtf?? i thought bl was forced single thread

if it really is simd u should see practically no performance hit

Well

You know Simd instructions arent really parallel but rather operates over an array with a single instruction thus giving a sense of parallelism.

Conan · December 28, 2017, 11:39:30 AM

Quote from: FelipeO_O_ on December 28, 2017, 06:32:59 AM

Well

You know Simd instructions arent really parallel but rather operates over an array with a single instruction thus giving a sense of parallelism.

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???

Gytyyhgfffff · December 28, 2017, 08:42:58 PM

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