Protection against automation

前端 未结 7 1513
轻奢々
轻奢々 2020-12-31 19:35

One of our next projects is supposed to be a MS Windows based game (written in C#, with a winform GUI and an integrated DirectX display-control) for a customer who wants to

7条回答
  •  鱼传尺愫
    2020-12-31 20:17

    I don't know the technical details, but Intenet Chess Club's BlitzIn program seems to have integrated program switching detection. That's of course for detecting people running a chess engine on the side and not directly applicable to your case, but you may be able to extrapolate the apporach to something like if process X takes more than Z% CPU time the next Y cycles, it's probably a bot running.

    That in addition to a "you must not run anything else while playing the game to be eligible for prizes" as part of the contest rules might work.

    Also, a draconian "we might decide in any time for any reason that you have been using a bot and disqualify you" rule also helps with the heuristic approach above (used in prized ICC chess tournaments).

    All these questions are easily solved by the rule 1 above:

    * how to detect if another application makes periodical screenshots?
    * how to detect if another application scans our process memory?
    * what are good ways to determine whether user input (mouse movement, keyboard input) is human-generated and not automated?
    * is it possible to detect if another application requests informations about controls in our application (position of controls etc)?
    

    I think a good way to make harder the problem to the crackers is to have the only authoritative copies of the game state in your servers, only sending to and receiving updates from the clients, that way you can embed in the communication protocol itself client validation (that it hasn't been cracked and thus the detection rules are still in place). That, and actively monitoring for new weird behavior found might get you close to where you want to be.

提交回复
热议问题