How to make my game safe when all logic is in client!

Started by
6 comments, last by laiyierjiangsu 6 years, 11 months ago
Hi, all.
The game I currently develop is a cooperative project , and it's an mutiplayer game. In the game session ,the relay sever only transmits the input from client, the logic sever processess the game logic. The AI and collision logic is running in client, and the client sends some key events to logic sever, the logic server uses all these events from different client for checking . If there is a NVN battle (N > 1), this mechnism doesn't have any problem, because if someone modify the game data ,we will compare it with other clents in the same date, we can find if he is cheating. but if it's an 1v1 battle ,we can do nothing. We hope the partner to give us more state ,not just this key event, the suggesting has been denied. The partner doesn't want us to know more detail about the kernel logic.
I have analized the plugins of our game , they just modify some data in battle to make thegame mismatch. First open our game exe ,then modify some memory. So I have an idea ,if I can hook the windows api openprocess when our game been started, I can find who want to open it ,if it's some process we do not permitted ,we send it to sever, so if divegence happened in 1v1 battle,
we can know who is the bad guy.
I do not know whether this way could work ,can someone give me some advice? I really appreciated!

Stay hungry, stay foolish!

Advertisement

If the way I metioned can work, I have some other questions:

In the ring3 of windows, could I know who or how many process using openprocess opened our exe? Hooking openprocess which is been expert in kernal32.dll in ring0 may works here ,but it cannot be released withe my game.

Stay hungry, stay foolish!

I have analized the plugins of our game , they just modify some data in battle to make thegame mismatch. First open our game exe ,then modify some memory. So I have an idea ,if I can hook the windows api openprocess when our game been started, I can find who want to open it ,if it's some process we do not permitted ,we send it to sever, so if divegence happened in 1v1 battle,
we can know who is the bad guy.

This probably isn't going to work, your still in client space, so they can figure out how to bypass this overall.

I use a similar setup for my game(gameservers do little work other than keeping inputs in sync, and some minor game logic). I also implemented a shared client check for detecting if a single user is out of sync, and as you say the core problem with this setup is that when dealing with only 2 clients, neither is capable of being trusted. Ideally if this is a problem to worry about(my game is intended to be played by 4 players generally) you should implement recording player playback, and a report system. if the other player suspects cheating then give them the ability to report the offending user. the only other alternative is to make your server do more work to verify inputs are valid, but depending on how deep into development you are, this could be considerable work.

At the end of the day, if someone with the skills really wants to crack your game, they probably well do so if your leave it upto the clients to decide what to do.

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

@slicer4ever,Thanks for your replay

Ideally if this is a problem to worry about(my game is intended to be played by 4 players generally) you should implement recording player playback, and a report system.

1v1 is our main mode , this cann't be changed now. A report system is already upder development, but in the situation I mentioned above, recording player playback may not work。 Our recording system only save the player's input, and the use the same config to start the battle. If the cheater modifys the battle time , we can not find it through recording system, because the data which has been modified is in memory,we can not dump all them ,so we also can not playback it.If our partner do not give us more details about how they check the data and What data they will check , we can do nothing in this circumstance.

This is a tragedy!

Stay hungry, stay foolish!

In the 1:1 case, you can flag both clients as potential cheaters, and see which of them ends up being flagged more and more over time.
A non-cheater will be flagged less often than a cheater.

Cheaters will also get caught in the N:N case eventually. At this point, you could go back through their history of 1:1 "potential cheat" reports and clear the other player in the report as being innocent.

One other thing to be aware of is coordinated cheaters, e.g. in 2 vs 1, if the 2 are both cheating and working together, they can report that each other's actions are allowed, and spuriously report the other 1 player as being a cheater!
i.e. a hacked client can ignore real cheaters and accuse innocent players from cheating...
This means you need to treat all client-side cheat reports as only being potentially correct.

In the 1:1 case, you can flag both clients as potential cheaters, and see which of them ends up being flagged more and more over time. A non-cheater will be flagged less often than a cheater. Cheaters will also get caught in the N:N case eventually. At this point, you could go back through their history of 1:1 "potential cheat" reports and clear the other player in the report as being innocent.

Thank you , Hodgman! This gives me some inspiration!

I can say this is a delay punishment system.

As I mentioned above, most plugins I have found ,they do not hack our client exe ,it just modify the memory of our client instance, I still want find out who want to modify the memory of our client. Are there some easy way I can find out this? I found hookint the window api may not easily realize

Stay hungry, stay foolish!

In the 1:1 case, you can flag both clients as potential cheaters, and see which of them ends up being flagged more and more over time.
A non-cheater will be flagged less often than a cheater.

Cheaters will also get caught in the N:N case eventually. At this point, you could go back through their history of 1:1 "potential cheat" reports and clear the other player in the report as being innocent.

One other thing to be aware of is coordinated cheaters, e.g. in 2 vs 1, if the 2 are both cheating and working together, they can report that each other's actions are allowed, and spuriously report the other 1 player as being a cheater!
i.e. a hacked client can ignore real cheaters and accuse innocent players from cheating...
This means you need to treat all client-side cheat reports as only being potentially correct.

Agree that this is your only option. Another thing to bear in mind is that if you have a desync bug in your client code that only affects certain clients (e.g. maybe it affects users with certain hardware, or users with certain options set) then you're in real danger of flagging them as a cheat (a false positive) so you must be careful in your punishment strategy.

In terms of spotting the specific cheat you've identified, I don't really know, but if you're on Steam, then perhaps Valve-anti-cheat could help. If you block this one particular cheat implementation, then another will pop up in its place.

@[member='C0lumbo'],

Thanks for your advice!

In the 1:1 case, you can flag both clients as potential cheaters, and see which of them ends up being flagged more and more over time.
A non-cheater will be flagged less often than a cheater.

Cheaters will also get caught in the N:N case eventually. At this point, you could go back through their history of 1:1 "potential cheat" reports and clear the other player in the report as being innocent.

One other thing to be aware of is coordinated cheaters, e.g. in 2 vs 1, if the 2 are both cheating and working together, they can report that each other's actions are allowed, and spuriously report the other 1 player as being a cheater!
i.e. a hacked client can ignore real cheaters and accuse innocent players from cheating...
This means you need to treat all client-side cheat reports as only being potentially correct.

Agree that this is your only option. Another thing to bear in mind is that if you have a desync bug in your client code that only affects certain clients (e.g. maybe it affects users with certain hardware, or users with certain options set) then you're in real danger of flagging them as a cheat (a false positive) so you must be careful in your punishment strategy.

In terms of spotting the specific cheat you've identified, I don't really know, but if you're on Steam, then perhaps Valve-anti-cheat could help. If you block this one particular cheat implementation, then another will pop up in its place.

Stay hungry, stay foolish!

This topic is closed to new replies.

Advertisement