Client side hack prevention idea

I have been thinking about how they can fix issues with hackers. Obviously server side validation is the best option and pretty damn hard to hack, it does require quite a bit of server power.

What about client side checks then? Not just on one client, but the check is done on both parties computers. Here is how I imagine it going, with two players:

1: Player A attempts to hit Player B
2: Player A sends “hit attempt” signal to server
3: Player A client calculates if hit was successful
4: Player A client sends “hit success” to server
5: Server sends hit attempt to Player B
6: Player B client calculates if hit was successful
7: Player B client sends “hit success” to server
8: Server sends Player A and Player B “valid hit success” message
9: Player B dies

It is just an idea and testing would need to be done. There will be additional data sent over the server yes, but I think it could handle the extra data better than it would doing server side validation.

Lets imagine player A is a hacker and player B is genuine. Player A could hack step 3 so that it always says the hit was a success, but player B client would disagree, making player B seemingly invincible to the hacker.

Now switch it, player A is genuine and player B is a hacker. Player A says that the hit was valid, which it was, player B says no it wasn’t, hacker is still alive. Server picks up a disagreement and flags those two players making them unable to kill each other. Player A survives without player B being able to turn around and kill player A legitimately as they will be in close proximity.

Apply this with other checks too like shooting through walls, speed checking within proximity and other such things.

Obviously this thread is aimed at programmers with some knowledge of server coding (I have developed a TCP server for a Windows 8 app so I think I qualify).

I see a major, MAJOR flow in this algorithm.
Why not simply spam the hit attempt?
It’s a DoS for the server, and mostly client, as in the insane amount of calculations that are to be done, and an instant kill whenever a person comes within the range.
Oh well.
(yes, this is possible, since rust does RPCs to almost everything)

Because spamming the hit attempt could be caught be the server with a very simple check:

if (DateTime.Now - player.LastHitAttempt < 100) // 100 being milliseconds, 10th of a second

Don’t get me wrong, server side would be far better, but how about try and come up with a better solution than mine…

In simple words you tell 'em to do a server verification for every hit attempt.
Most games do use this technic is some variance, I kinda agree with you.

This thing would stop some of the major hacks, tho hackers will look for more exploits and flaws in the system every time.

I can still deny the hit.

Player B mods files or uses a hack to always say he was not hit. Godmode.

I don’t think you have understood it completely. Player A will say he was hit, player B (the hacker) says he wasnt. The hacker survives, but because of this disagreement, the server will not allow either player to kill each other for a period of time, meaning the genuine player, is not inconvenienced too much and not automatically killed by the hacker. All this allows is for hackers to be able to run around collecting resources without getting killed. To me, that seems a far better trade than the current state of hacks.

[editline]23rd February 2014[/editline]

See above.

I don’t think your in any position to recommend what they could do, this is method is probably already in use but like others have said it can become very easy to fake messages to the server. Heck they could probably find a way to send fake messages about other players and insta-kill everyone.

People don’t need to suggest a better idea in order to tell you that:

  1. What you’re suggesting is in no way a revolutionary approach to anything… and therefore:
  2. The devs of this game (who most likely know just a little bit more about this than you do) have either already considered it or dismissed it for whatever reason. The fact that they haven’t implemented anything fancy so far doesn’t mean that it’s not on their todo list.
  3. “Look out everyone, we’ve got a badass, this guy’s implemented a TCP server for a Windows 8 app!” Obviously, that means online FPS hit detection has no secrets for you.Thanks for your input, and don’t forget to ask for your share of the profit on the game after they improve their hit detection.

Jesus, it’s not like I am demanding they do this. I was just hoping for a few users with programming experience to suggest any problems with this, or any better options. The developers can and should carry on what they are doing, regardless of this thread.

Even if the developers would take note of this thread do you think it’s a good idea to openly talk about it on here?

  1. I never said it was revolutionary.
  2. Again, didn’t say I know better than the developers.
  3. I simply mentioned that to get across that I am aware of the process the server does with games like this. It in no means makes me a badass or entitled to their profit…

[editline]23rd February 2014[/editline]

I am not expecting the developers to read this, fuck. Why can’t I talk about it on here? If you don’t want to talk about the programming side of Rust, then read another thread. I didn’t see in the forum rules that we aren’t allowed to talk about potential hack fixes…

1: Player A attempts to hit Player B
2: Player A sends “hit attempt” signal to server
3: Player A client calculates if hit was successful
4: Player A client sends “hit success” to server
5: Server sends hit attempt to Player B
6: Player B client calculates if hit was successful
7: Player B client sends “Sends miss” to server (Since not both are hit Player B lives.)
8) Player B shoots at Player A (repeat all calculations again If player A is not hacking both with come back saying that the shot landed)
Player A dies and Player B( Hacker Lives)

Snoozey are you purposely not reading the part where I am saying that if there is a disagreement then the servers marks those two players as unable to kill each other for a set period of time.

If there is a disagreement, maybe the server should calculate and kick or ban whoever’s client was wrong.

That’s interesting… So rather than the server do all the calculations, only have it do the ones that caused a disagreement. Would save a lot of processing power.

So what happens when the client is modded to say that every hit against the player is a miss?

or vice versa, every hit dealt to other players is always a hit?

And what happens in a legitimate disagreement?

If the hacker is saying every hit against them is a miss, but the person hitting them says it is a hit, then the server knows one of them is hacking. And so flags them so that neither hacker, or legit player can kill each other. This also applies for the vice versa, if a hacker says he hit you but didnt, then your client would say otherwise, showing the server a disagreement.

This is basically to level the playing field when you do come across a hacker. See it this way, currently, if you went to kill a hacker and failed, you are most likely going to die. With my idea, you will go to kill a hacker, fail, but then become immune to the hackers response as the server knows something is not quite right.

Ok so both players are legit? Well then that would be a bug in the code, maybe caused by some time differences or lag, in which case, the server would still flag it as a disagreement and neither of you can kill each other. But this shouldn’t happen, though it probably would during its early stages, if it does then you don’t really lose out on much, not to the extent of how much you lose out on resources currently due to hackers.

This would cause to many issues with lag. A -> Server -> B all the way back to server. It’s just not a good solution. Just wait for them to move things server side, and stop playing on official servers.

Even when it is all server side in other games there are issues where you think you are behind a wall and you are not. This adds even more communication making that happen much more often. I would rather keep it as it is then your solution. More things need to go server side check, and more optimization which will come.

The solution is server-side validation, which the devs are not currently doing for two reasons, iteration speed and server performance.

Some hinky peer-to-peer hit detection diplomacy protocol is a bandaid looking for a problem to fix.