How to make my game safe when all logic is in client!
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.
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.
@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!
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
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.