Programmer’s Weekly: Shadow variables against hackers

Written by: Mark Bouwman

Hacking. It happens. A lot.

I don’t think I have ever played a game that people did not want to hack. Even for the smallest flash games you can find some sort of way to hack them. In (offline) single player games it’s not all that bad though, there’s not really all that much for a developer to worry about. However, when there are highscores or even actual rewards linked to the performance of a player, hacking suddenly gets a pretty important thing.


It sucks.

There’s only little ways to completely protect your game against hackers. It’s a pity, but you can at least try to demotivate hackers by making it harder for people without a lot of knowledge to hack your game. This week, I wanted to take some time for the very first line of defence. Something I like to call: shadow variables.


So we use shadow variables?

Indeed. And in case you’re wondering what a shadow variable really is: a shadow variable is a variable that lies parallel to the actual variable you use for stuff like keeping track of scores. It might sound vague, but allow me to explain.

Let’s say you have a variable called ‘score’, in which the player’s score is represented. Every time the player picks up an item: score++. When someone uses something simple as Cheat Engine, they can easily track a score that’s visually represented in their own interface. They know the value of their score, so they scan the flash memory for that value. Within a few scans, they got access to the memory and are free to change that variable to something way off the charts.

This is where shadow variables come in.

Other than the variable ‘score’, we also have a variable named ‘sv1’. The name doesn’t mean anything but it’s good practise not to name the variable anything score related, just in case the hacker can see variable names. When score gets increased, we also increase the shadow variable. But not by one, no, we increase it with a set random number, which we generated at the start.

Every time you change score, check it against sv1. If score isn’t sv1 divided by the random number, it means someone tinkered with the score! Then you can either kick them, nullify their score, or just allow them to continue with their actual score.

This way of protecting important variables (life, score, time, bullets… anything gameplay changing really) isn’t all that complicated, but it definitely works as an efficient first barrier!

2,787 total views, 1 views today

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>