For multiplayer (competitive) games, there is often the issue of needing to detect illegitimate players so they can be denied service. On the other hand, legitimate players should of course be permitted access to service.

These illegitimate players are simulated by one means or another, but I would like to focus on when simulated through the use of 3rd-party software which uses 1st-party API's to query or send information to a central server.

I would like to understand how this API must be designed so that a fraudulent (3rd-party) software cannot pretend it is the legitimate (1st-party) software that is already deployed to the end-user.

Client-Server Interactions

To be clear, 3rd party software is obtained by a malicious user, in which the 3rd party software has been compiled with the API that communicates to the server. Since the API is deployed to a legitimate user, the developers of the malicious software simply need to reverse-engineer (perhaps via de-obfuscation) that API and use it.

Is there a way that this API can implement some security protocol so that the illegitimate users cannot access the server at all?

I have thought about requiring some password which is sent to the server to verify the caller, but I cannot see how we can distinguish between genuine users and false users.


Basically, you can't...

Anything on the client side needs to be considered as public. Sure, you can try to obfuscate the API with various technique but there is always a way to reverse engineer it and build your own botting API. You need to consider that a hacker can control everything on the client side.

What can you protect?

The only thing that you can protect is your server. Hence, if you want to control what your players can or cannot do, you have to validate their every action on the server side. The server must be the source of truth. At this point, if the server can detect any invalid action, an attacker could still build an "invalid" client but the only things this client could do are valid actions. So, it's easy right?

Well, not that much. Trying to validate everything on the server side create many problems. Many related to how smooth the game will run but also, you have to figure out how to include network problems, like a user lagging. For example, if you go to the extreme in terms of protection, it will go like this :

  • The client send action command to the server
  • The server execute the action (if valid) and sends the result to the client
  • The client simply displays the result that the server told them to display.

It's super simple to do and defeat any invalid action, BUT it totally destroys the user experience for anyone with a bad network. When a user press a key to move forward, he expects to move forward right away. Since every action do a round trip to the server side, the users that lag will experience slow action at every turn.

What can you do?

The best idea is to have a mix system. You do the validation on the server side BUT you still "execute" the action on the client side as soon as they happen. That way the user think their action happen at the moment they do them, while in fact they might be done a few milliseconds or seconds later. You are basically doing a simulation on the client side, and if the server confirms to you that everything was ok, that simulation is kept. In the case that the simulation was deemed wrong by the server, these actions are "reversed".

It's kind of a pain to get that sort of system right but it's the only thing that provide good user experience while also completely defeating invalid action.

An easier approach : logging

Since, really controlling everything on the server side can be a pain as it's hard to decide what to do when history needs to be rewritten, an easier approach is to do logging. You let the client do nearly whatever he wants, he is the source of truth, but then, on the server side, you log every action and detect every single invalid action. The invalid actions will still happen but if a client does too many of them, you can safely assume that he is not a valid client and -ultimately- ban him.

About obfuscating : Effort VS Gain

Obfuscating stuff on the client side make it much harder for an attacker to create a botting program so it will discourage many wannabe attackers so you will have to deal with a smaller subset of problematic players.

I'm not an expert in such techniques but it's something similar to:

  • changing all variable/method names
  • inserting useless code to confuse the reverse engineer
  • encrypting the code (but the password is still hidden somewhere in the code...)

It's really just stuff to make it more painful to try to reverse engineer the game client...


This is one of the largest problems online competitive games have to face. Unfortunately, there's no simple solution. The most effective way of detecting bots or malicious users is via behavioral analysis.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.