How does one deal with cheating while using Realtime?

As I understand it, Realtime allows us to connect to Photon cloud using messages from each client in a match. In this situation, the server acts only as a messaging system and won't validate any input the players give to it, only sends the messages to the relevant players in the match. Naturally, I may have misunderstood the way the system works so feel free to educate me! ;)

In light of that, how do we deal with cheating in competitive games using this service? I am working on a fast paced competitive VR game and this is something that has come up while I was testing the demo for Unreal Engine 4, as I noticed for the first time that there is no server code necessary in the demo.

cheers!

Best Answer

  • KaiserludiKaiserludi admin
    Accepted Answer
    Hi @CASBraga.

    On Photon Public Cloud we can't allow custom server side code for security reasons, as the same servers may are shared with the games of other developers (it would be practically impossible to make sure that no one (accidentally or purposely) deploys custom code that affects the games of other developers, for example by causing server crashes or extremely slowing down server performance).

    So, while with Photon Enterprise Cloud and Photon Server you can add server side code that understands you game-logic and verifies the input from clients for plausibility, you can't do that with Photon Public Cloud. You might want to consider using either the Enterprise Cloud, if your budget allows this or using Photon Server if you are OK with hosting the servers yourself.

    So what can you actually do against cheaters on Photon Public Cloud?
    well, there are a number of options that you have without custom server side code:
    - You can turn on CRC checks in the Client (simply call Client.setCRCEnabled(true)). This makes the client add a checksum to each message, which the server checks to ensure that non one changed the message while it was on its way between the client and the server. For a small overhead this protects you from cheater who observer and modify the network traffic after the message has left the application on the client.
    - You can calculate a checksum on your client, which depends on every file that would never get modified during normal usage. So if a user modifies the executable itself or some resource file from which that executable reads out game parameters like for example balancing-related information (i.e. the fire rate of a certain weapon), then the calculated checksum would no longer match the value that your code expects for that version of the game and you would deny that client access to the multiplayer mode of the game.
    - A user might modify the RAM. You can find suggestions on how to make this a LOT (especially if you implement all of the suggestions) harder for him at http://gamedev.stackexchange.com/questions/9832/strategies-to-defeat-memory-editors-for-cheating-desktop-games, at http://gamedev.stackexchange.com/a/9842/35681 and at http://gamedev.stackexchange.com/a/23802/35681
    - Let each client verify the messages of each other client it currently is in a game with: when your client receives a message, that the player of remote client X claims that it just moved to position Y or that it killed player Z, then let your local player check if that is even possible at all with your game mechanics and the last known information about that player. You can't be to strict and must, when in doubt that there may even be a slight possibility that the claim by client X is valid, assume that he did not cheat, as otherwise you may get lots of false positives. If a client got reported b others more than U times over the time of W games, then mark it as a cheater
    - Give users a UI element to report other users as cheaters and let your client send replay data with those reports. If a user got reported more than X times over time of Y games, let someone from your company look at the replays to check, if the claims are correct, then mark him as cheater.

    You should set up a custom auth provider for your game (see https://doc.photonengine.com/en-us/realtime/current/reference/custom-authentication). That way on custom authentication you can prevent clients, that you have deemed as cheaters, from successfully connecting. You may first send a warning to a client, that gets shown to the user, then block him from connecting for a day, then for a week, and if he still cheats afterwards, for lifetime.
    You could also include the checksum for the client version (see the second '-' to your auth service with the auth request, so that the auth service can verify it against the expected value and someone who modifies the client could not pass the check against modifications by simply figuring out what the client checks against and modifying that value, too).

Answers

  • KaiserludiKaiserludi admin
    Accepted Answer
    Hi @CASBraga.

    On Photon Public Cloud we can't allow custom server side code for security reasons, as the same servers may are shared with the games of other developers (it would be practically impossible to make sure that no one (accidentally or purposely) deploys custom code that affects the games of other developers, for example by causing server crashes or extremely slowing down server performance).

    So, while with Photon Enterprise Cloud and Photon Server you can add server side code that understands you game-logic and verifies the input from clients for plausibility, you can't do that with Photon Public Cloud. You might want to consider using either the Enterprise Cloud, if your budget allows this or using Photon Server if you are OK with hosting the servers yourself.

    So what can you actually do against cheaters on Photon Public Cloud?
    well, there are a number of options that you have without custom server side code:
    - You can turn on CRC checks in the Client (simply call Client.setCRCEnabled(true)). This makes the client add a checksum to each message, which the server checks to ensure that non one changed the message while it was on its way between the client and the server. For a small overhead this protects you from cheater who observer and modify the network traffic after the message has left the application on the client.
    - You can calculate a checksum on your client, which depends on every file that would never get modified during normal usage. So if a user modifies the executable itself or some resource file from which that executable reads out game parameters like for example balancing-related information (i.e. the fire rate of a certain weapon), then the calculated checksum would no longer match the value that your code expects for that version of the game and you would deny that client access to the multiplayer mode of the game.
    - A user might modify the RAM. You can find suggestions on how to make this a LOT (especially if you implement all of the suggestions) harder for him at http://gamedev.stackexchange.com/questions/9832/strategies-to-defeat-memory-editors-for-cheating-desktop-games, at http://gamedev.stackexchange.com/a/9842/35681 and at http://gamedev.stackexchange.com/a/23802/35681
    - Let each client verify the messages of each other client it currently is in a game with: when your client receives a message, that the player of remote client X claims that it just moved to position Y or that it killed player Z, then let your local player check if that is even possible at all with your game mechanics and the last known information about that player. You can't be to strict and must, when in doubt that there may even be a slight possibility that the claim by client X is valid, assume that he did not cheat, as otherwise you may get lots of false positives. If a client got reported b others more than U times over the time of W games, then mark it as a cheater
    - Give users a UI element to report other users as cheaters and let your client send replay data with those reports. If a user got reported more than X times over time of Y games, let someone from your company look at the replays to check, if the claims are correct, then mark him as cheater.

    You should set up a custom auth provider for your game (see https://doc.photonengine.com/en-us/realtime/current/reference/custom-authentication). That way on custom authentication you can prevent clients, that you have deemed as cheaters, from successfully connecting. You may first send a warning to a client, that gets shown to the user, then block him from connecting for a day, then for a week, and if he still cheats afterwards, for lifetime.
    You could also include the checksum for the client version (see the second '-' to your auth service with the auth request, so that the auth service can verify it against the expected value and someone who modifies the client could not pass the check against modifications by simply figuring out what the client checks against and modifying that value, too).
  • JohnTubeJohnTube mod
    edited February 23
    Thanks @Kaiserludi for your valuable contribution as always.
  • CASBragaCASBraga
    edited February 23
    Thank you @Kaiserludi! This was exactly what I had thought and dismissed as not possible. There are other things that Photon Cloud won't allow me to do (bots to substitute disconnected players, for instance), but this makes using the cloud still viable, as it would be the most finnacially and logistically better solution.
  • Hi @CASBraga,
    I really like this thread. There was a similar question (http://forum.photonengine.com/discussion/comment/32939) where I awaited an answer and Kaiserludi just forwarded me here.

    I'm interested in your note in the last comment about "bots to substitute disconnected players". Did you find a solution for this or is there a thread in the forum where this topic is discussed?
    I'm prototyping an 1 vs 1 game where I wanted to have that functionality.
    Thanks
  • Hi @CASBraga, hi @rlonau.

    An option for Remote Bots would be to run them on a separate server that is hosted by you and to let them connect like normal clients. Keep in mind however that that way they count against your CCU.


    I'm prototyping an 1 vs 1 game where I wanted to have that functionality.

    When you want do substitute disconnected players in a 1vs1, I don't see anything speaking against just running them locally on the client of the remaining player. At that point it's practically a singleplayer game against the AI.
  • CASBragaCASBraga
    edited March 2
    @Kaiserludi Thanks again! I was thinking of a different way to have bots, but only in 2v2 and up games. Your solution seems better for that.

    @rlonau You could also just let the disconnecting player lose the match and the match ends.
  • Hi @CASBraga.


    @rlonau You could also just let the disconnecting player lose the match and the match ends.

    Oh yes. Absolutely!

    @rlonau:
    If player A disconnects, we can't really let him win or give him a tie, otherwise loosing players would just disconnect to avoid a loose. So in a 1v1 player B can't loose the game against player A anyway anymore at this point, even if the AI that replaced player A beats him. So whats the point for player B in continuing to play against the AI instead of just starting a new game against another human opponent? If he wanted to play against AI instead of a human, then he would not have chosen multiplayer mode in the first place.

    If you want a player to be able to reconnect after he got disconnected, I would strongly recommend against replacing him by a bot while he is gone. As a player it would be an absolute no go for me, if a bot takes over for me and does any moved that I absolutely never want to happen. I would strongly prefer if just no moves at all happen from on my behalf, while I am gone.
  • Thanks for your feedback guys.

    Since it'll be a mobile game I'm mostly thinking about connection related disconnects. Meaning also the player who's winning could have a disconnect. So a bot replacing him could still manage to win that game or at least handle some decissions until the player is reconnected.

    I guess for the prototype I'll skip this tricky topic for now. I should focus on the gameplay at first.
Sign In or Register to comment.