Cheat prevention: How are NoSpread hacks working?
by Kyrah Abattoir · in Game Design and Creative Issues · 09/06/2010 (2:34 am) · 7 replies
There are hacks for fps games that "cancel" the spread of a weapon (when a weapon has a spread, the shots tend to scatter around the point the player is aiming.
How do they cancel something that is essentially computed server side? (i am not talking about clientside weapon climb, where the sight will shake left and right when shooting)
Hypothesis 1: The server and client use a synchronized algorythm for computing where the next spread will go so the clientside tracers can be displayed before the server actually received the confirmation of the shot. The hack knows the formula and apply aiming correction so the adjusted shot land on target instead of off target.
Hypothesis 2: The server is not handling the spread, only the client does and it accept whatever aiming vector the client sends back as the actual bullet tracer.
In case 1, one possible fix is to make the server apply an extra, small, completely random rotation to the tracer so the client cannot accurately predict where the spread will land.
In case 2, the fix is to move away the decision from the client to the server and chose instead something like Hypothesis 1.
I think those solve ~80% of the problem where a high spread weapon could be used as a sniper rifle, it doesn't prevent someone to cheat, but it covers, i believe, the issue of NoSpread hacks.
Now i'm not an expert, is there something else i might be missing on this type of hacks?
How do they cancel something that is essentially computed server side? (i am not talking about clientside weapon climb, where the sight will shake left and right when shooting)
Hypothesis 1: The server and client use a synchronized algorythm for computing where the next spread will go so the clientside tracers can be displayed before the server actually received the confirmation of the shot. The hack knows the formula and apply aiming correction so the adjusted shot land on target instead of off target.
Hypothesis 2: The server is not handling the spread, only the client does and it accept whatever aiming vector the client sends back as the actual bullet tracer.
In case 1, one possible fix is to make the server apply an extra, small, completely random rotation to the tracer so the client cannot accurately predict where the spread will land.
In case 2, the fix is to move away the decision from the client to the server and chose instead something like Hypothesis 1.
I think those solve ~80% of the problem where a high spread weapon could be used as a sniper rifle, it doesn't prevent someone to cheat, but it covers, i believe, the issue of NoSpread hacks.
Now i'm not an expert, is there something else i might be missing on this type of hacks?
About the author
3D artist, programmer, game designer, jack of all trades, master of none.
#2
09/06/2010 (7:11 am)
It's because the spread isn't computed server side. It's all based on client hit detection. Kyrah, you're a PlanetSide player right? The big hacks for planetside were available because it's all client side computing.
#3
Okay so nospreads in Planetside are because the spread is calculated by the client...
@Daniel: Yes the would be, but if the clientside computation used to compute the spread is not random, but using a predictable algorythm so the client's prediction match the server's final decision (like basing the spread on a reference frame or something), knowing said algorythm can enable a hack to predict where the next shot will land.
Anyway it was just a shot in the dark, i guess i give too much credit to cheaters :D
You can still compute a lot of things client side without compromising the server security.
09/07/2010 (2:19 am)
Yes i am, but it's not the only game that has nospreads.Okay so nospreads in Planetside are because the spread is calculated by the client...
@Daniel: Yes the would be, but if the clientside computation used to compute the spread is not random, but using a predictable algorythm so the client's prediction match the server's final decision (like basing the spread on a reference frame or something), knowing said algorythm can enable a hack to predict where the next shot will land.
Anyway it was just a shot in the dark, i guess i give too much credit to cheaters :D
You can still compute a lot of things client side without compromising the server security.
#4
09/07/2010 (3:31 am)
Quote:knowing said algorythm can enable a hack to predict where the next shot will land.True, but ideally this won't affect the server's processing. Jeremy's hit on the real problem - the server isn't authoritative. Presumably, this sacrifice was made so that the act of shooting a weapon could be made more satisfyingly instantaneous, rather than the effect being delayed by network transmission. Or to save server processing costs. Or something.
#5
09/07/2010 (10:21 am)
*Nod* My question wasn't specifically geared to planetside, but to FPS games in a more general way. 
#6
I'm thinking of it for my game but for the moment the solution I found are a bit costly on server side.
If you implement something like that or design a solution I will really appreciate if you can share it.
I would like to find a way to manage the spread on client and have a possibility to check on server side the value send by the client.
By doing that, you avoid realtime calculation on the server to keep the spread updated.
09/09/2010 (6:29 am)
I think it's clearly as Jeramy said, the spread is not calculated on server side.I'm thinking of it for my game but for the moment the solution I found are a bit costly on server side.
If you implement something like that or design a solution I will really appreciate if you can share it.
I would like to find a way to manage the spread on client and have a possibility to check on server side the value send by the client.
By doing that, you avoid realtime calculation on the server to keep the spread updated.
#7
10/09/2010 (11:41 pm)
I haven't played with this yet but I'm destined to in the next couple of months. You have to assume anything and everything done on the client will be hacked. Competitive gaming is very difficult to manage for that reason. A common effort being made is that companies have a second program that operates at a very low level and tries to identify anything suspicious with the code. From a security point of view, you definitely want the server doing the hit detection. The client can deal with all the visuals itself. If you run into bandwidth issues, another tactic used is to have clients do the hit detection but corroborate results with one another. This isn't as insecure, but it's not going to stop hacking, just make it more difficult. All they have to do is make the client think they received the green light from the other clients. 
Torque Owner Daniel Buckmaster
T3D Steering Committee