Is code injection possible through packet modification?

For example, if a game sent a packet declaring score=99 could I then modify the packet to score=*code* or something similar?

I guess a similar question would be, is it also possible to execute non-API code in an API environment?

  • From the client-side perspective, you can cook up almost anything locally and try to send it to the server. But if the server is serious about security, it should have rigorous validations over everything it receives. It can't control everything it receives from you, but at least it can detect if it's a manipulated packet that doesn't fit the normal pattern.
    – Gabriel S.
    Apr 2, 2016 at 22:50

2 Answers 2


Yes, in the sense that you can forge and send such a packet.

First hurdle: is it still a valid packet? This depends on the packet structure. Many games leverage existing libraries that will use standard formats such as JSON or XML, so it will not be easy to forge a packet that contains the desired code and still be syntactically correct for the involved data format.

Then, will the server accept the packet? Most game developers are wont to wonder what would happen if someone modified

"score": 999


"score": 999999999

While I suspect, from some leaderboards I see in Google Play, that not all developers gave this possibility enough consideration, the usual low level, low security, but fast method to stop 99% of wannabe "winnerz" would be to also include the hash of the value and of a client (== unsafe) secret:

"score": 99,
"hash": "ff24e8a1f3fddb010095102bce5a013c"

A member of the remaining 1% of gamers could easily override this by digging out the secret from the game binary, or even trying to bruteforce it out of same binary: most of the time the hash for such a simplistic scheme will be something like MD5("SECRET" + SCORE) or maybe MD5(SCORE + "SECRET"), and SECRET will be one of the entries in the binary string table, in clear.

So you send along the modified code with the appropriate hash, and it will pass muster.

If the defense is still tighter, its stage will be almost impossible to overcome, though: the game contains the server's public key and uses it to RSA-encrypt the score, not even bothering to send it in the clear.

You can ignore this difficulty if you know that the buffer overflow server side is in the code reading the variable itself, whether it is RSA encrypted or not (i.e., before it is even decrypted).

At this point you've managed to send a string to the server in the hope that it will do something with it.

If the server foolishly makes some hardcoded assumptions on the string length, that could be enough for a buffer overflow. You may have to whip up some ad hoc substitutions to avoid sending a code payload with binary zeroes, which are likely to disrupt the string copy operation, but it's doable (and has been done).

But now another difficulty arises. You have injected something somewhere in the process space of the server. How do you manage this to result in something "useful" (from an attacker's point of view)? It might very well be that all of the above only results in the server hiccuping, or malfunctioning for longer periods.


For example, if a game sent a packet declaring score=99 could I then modify the packet to score=code or something similar?

It all depends on how it is interpreted at the server-side end. If score is interpreted as an identifier, = as a delimiter and 99 as a numeric value, then code execution would only be possible via an overflow, should such a vulnerability exist. If however, whatever is sent is actually interpreted as executable code, then yes this would be possible.

I guess a similar question would be, is it also possible to execute non-API code in an API environment?

I'm not sure what you mean by this. The environment where you execute code has to be able to understand it for it to run. If the API is sufficiently sandboxed, then executing arbitrary code may be difficult.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .