🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Verify the EXE file

Started by
14 comments, last by Antheus 16 years, 10 months ago
Here's the thing: I have a little P2P online FPS. I have one main server that does basic authentication and NAT introducing. Cheating is not really an issue now, but when the game will have more players, i have to handle it. First of all, I have to check if the EXE file is hacked or not (because if I'M pretty sure it isn't, I can check the data files, network hooks, etc.). I know I can never be 100% sure about the exe file, so I want two things: 1. Be 99.5% sure that it's not hacked 2. It has to take time to hack the EXE... At least 2 weeks, because I'll make an update every 2 weeks and the hackers can start again. So what to do?
-----------------------------------"After you finish the first 90% of a project, you have to finish the other 90%." - Michael Abrashstickman.hu <=my game (please tell me your opinion about it)
Advertisement
Can't be done.

The reason for this is quite simple - you rely on client to tell you that client is valid. You never can trust the client. Hence - you cannot trust client to tell you that client hasn't been modified.

You're trusting a crook to tell you they are honest.

Quote: 1. Be 99.5% sure that it's not hacked


There are two levels of security:
- 100% security
- no security

And 100% security doesn't exist. CS, UT and Quake have long capitulated in this battle, and rather than checking for clients, they check for hacking behavior and ban offending clients.

There are intermediate levels of complications you can add, but unless you change the complete method every two weeks, automated hacks will appear. Guild Wars is a nice example - they have incredibly secure and completely anonymous file system, and they publish new client executables at 1-2 week intervals on average.

Despite that, client-side bots do exist - game logic doesn't change, so the only problem is finding new offsets for a small number of variables, something which takes a few minutes after a new patch.

You better start working on algorithms that test for impossible actions, so that you at least have a low level of legitimacy. For example, if a player kills 3 others within 14ms, and relative angles between targets are 234, 173 and 99 degrees, you can be pretty sure something fishy is going on - it'll be almost (almost) impossible for a human to have such reaction time and such accuracy.

To be more clear: Read the article on that 10,000 archers RTS. The protocol there enforced clients to be in consistent state. If they weren't, peer no longer wanted to talk to them.

In FPS, this is much harder, but this is how you determine the dumbest hacks (wall-hacking, teleporting, and similar), but it's considerably harder to deal with input based actions (aiming). The logic is simple, rather than trusting the peer, you trust yourself. If you no longer like what other player is doing, you disconnect them. And if majority of clients in a game are legit, they will all autonomously kick the offending player.

The cheater can than hack to their heart's content, but they'll find themselves with getting disconnected. And it's always the remote who initiates that. And if someone makes a griefing hack to initiate the /kick, then you won't want to play with them in the first place - it should be obvious to you what happened.
I've gotta agree, at least partially, with Antheus.

If you have to rely on anything from the client, then you might as well not even bother checking. It is trivial to submit a fake checksum in place of the actual checksum to fool a server into thinking your exe/dll is legit.

For P2P (and even servers), your best option is to give the players themselves the option to kick people out. You may get a few false positives/abuse, but I'm sure they will be minor.

I am curious about the efficiency of a P2P fps, though. It seems that it would put a lot of load on each of the clients and severely hamper ping rates.
I managed to reduce the bandwidth consumption to the minimum, so thats not a problem.

So you say i cannot determine whether one has a hacked client. What a pity. (and how naive was i)
I guess i put in votekicking AND employ some GMs. Awww, verifying the client would have been so much easier.
-----------------------------------"After you finish the first 90% of a project, you have to finish the other 90%." - Michael Abrashstickman.hu <=my game (please tell me your opinion about it)
Quote: Original post by Gagyi
I managed to reduce the bandwidth consumption to the minimum, so thats not a problem.

So you say i cannot determine whether one has a hacked client. What a pity. (and how naive was i)
I guess i put in votekicking AND employ some GMs. Awww, verifying the client would have been so much easier.


Nope - you're once again trusting the client (players).

System is automatic and built into the game logic. This is crucial. Then, when an inconsistency is detected, all non-hacked applications act alike, and disconnect the offending client.

If a player jumps by 15 meters in 10 ms, they are speed-hacking, or something similar. All peers will detect that, and act on their own, to result in collective action.

You cannot have GM powers in P2P, since you're once again relying on trusting a client - what's to stop me from hacking myself into GM status? How will my client know, that remote is a GM and not an impostor?

This is what makes P2P so problematic, and completely unsuitable for MMOs. You cannot trust a single remote entity. Even with trusted peers (in server cluster) there's an incredible amount of state synchronization problems to deal with - and you can trust those.

This is akin to control systems that run crucial operations (space shuttle, aircrafts...). You have multiple peers. Each runs on different hardware, running different software, all provided by different manufacturers and developers. All decisions made are voted upon by all units. If one unit disagrees with majority vote, the other units assume it's malfunctioning, and disconnect it.

You need similar system here. All peers periodically vote over validity of individual actions. If they determine that one or more clients disagrees with the decision, they vote to disconnect the client (this updates the game state by performing local disconnect, and removes offending client from the network).

This still leaves you in a vulnerable position if malicious clients alter the voting process, and they are in majority - but such situations require majority of players in game to use such clients - something that player will detect.
A GM kick would be a simple kick message to the server. (and server handles disconnecting and stuff)
And if only trusted people have the GM client, noone will know, how to do the GM authentication. (without hacking into MY computer of course)


P.S.: Let's just hope that the ,maority of the clients are clean :)
-----------------------------------"After you finish the first 90% of a project, you have to finish the other 90%." - Michael Abrashstickman.hu <=my game (please tell me your opinion about it)
Quote: Original post by Gagyi
A GM kick would be a simple kick message to the server. (and server handles disconnecting and stuff)


You said it was P2P, which means that if the server sends a kick request, the clients are free to disagree and ignore it if they are hacked.

Quote: Original post by Gagyi
And if only trusted people have the GM client, noone will know, how to do the GM authentication. (without hacking into MY computer of course)


What? Ever heard of packet-sniffing? By doing that, they can replicate it on their own, modified, client.
Quote: Original post by Gagyi
A GM kick would be a simple kick message to the server. (and server handles disconnecting and stuff)
And if only trusted people have the GM client, noone will know, how to do the GM authentication. (without hacking into MY computer of course)


Of course they will know. One solution would be to find a vulnerable router between the server and the GM client and listen to the traffic. Or simply to put one's NIC in promiscuous mode on a shared network (eg cable). Cryptography can help with that.

Honestly though, listen to the previous posters.
Quote: Original post by Gagyi
...Awww, verifying the client would have been so much easier.


Even if you could validate an exe you could not be sure that the client is not cheating. For example there are applications called “Aimbot” they run parallel to a game, read the framebuffer and scan specific regions for special colors, (for example the red text above your enemy showing his name) move the mouse cursor there (with some offset) and shoot automatically.

">-> youtube video


Some other ideas (just tossing them out there). If a person is walking and someone is tracking them fairly accurately (using CS as examples here) the server should detect this and boot (if there's walls between them) this is likely wall hacking. Or if the distance is too great for them to hear sound, kick also (if line of sight is blocked). Also to discourage aimbot randomly disable and enable the name of people showing up. If you're getting 60fps and 10 frames drop the text I doubt it would be noticed. Would have to test it though...

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

This topic is closed to new replies.

Advertisement