Making variables "un-hackable"

Maybe "unhackable" is over-zealous..............BUT!!!

My game in development is going to have an online score system. I know that you can use programs that allow you to find the variables via hex editing. I used to use hex editors in the dos days, and I'm sure the ones out now I by far more powerful. Its how people make "trainers" etc. They find out what things need changed, etc..

Ok so I'm a bit afraid someone will find the lives variable, the score variable, and maybe other variables that will allow them to obtain a high score and cheat the online scoreteable.

I was wondering what logical methods are used to prevent this, or atleast make it so friggen hard that it would take hours to crack.

If you're doing this, you're just going to cause yourself a lot of problems and no-one is going to care about cracking an executable to upload a higher score.

They are far more likely to sniff the packet you send and upload a score they invent instead.

So for verification, build a number of rules into your scoring so that you know what the maximum score is on a given level and so on so you can just reject bogus scores.

Also if you need to try and stop people using memory editors to hack the score, try keeping various copies of the number (as globals) .. and also use a known offset.

For example

global score1
global score2' = score1 -7000
global score3' = score2 + score1

This will make it very hard for the user to search for the given value in all locations. Then you can test that these 3 values all result in the expected value before allowing the submit.

Aswell if you use multiple function calls or conditions to alternative which function submits what, you can prevent somone bypassing with a JUMP.

Ontop of that if as rob says, use keywords or numbers to encrypt your data, then you should have a pretty safe system.

I would like to make memory editors, etc not able to sniff out "lives" and power up data, as well as other things that would make acheiving a high score easy too! A simple way would be to make the memory read only and writeable only at certain times.. That would be the easiest way, could that be done?

What Rob said.

Hi,

a) You can do the scoring with a mathematical function which only after transformation offers the value you want. -> This would force the attacker to break the function instead of just looking up the value.

b) Use a graphical representation instead of showing just scorenumbers. -> The sniffer doesn't known exactly what to look after.

c) Cipher the data you want to transmit from the client to the server. You can also add control and junk data to it. -> Makes intercepting the transmission harder and gives you afterwards the possibility to check if the score could realistically be achieved.

d) Do not just use a hobby self made eor or something like that.

e) Do the decoding of the ciphered or transformed data only on the server-side and configure your server well.

f) Add automatic control mechanisms according to the control data on the server-side. Which when interpreting the scorelist filters those out which do not make sense or seem to be suspicious. You can delete those or keep them stored in a second list to know who tried to just in case you wanna exclude them for future projects.

My experience for online-games is that the criminal energy is there to an astounding amount as soon as there is something to win...


Greetings,

taumel

One way to circumvent those memory editors to some extend, is to use more obscure ways of counting:

Although the screen shows 0,1,2,3 lives, your program could internally use -13,-16,-19,-22: count in increments of minus three, and consider '-13' to be a game over. A quick scan for 'obvious' numbers 0,1,2 or 3 won't return any relevant information in a case like that, and they would actually need to find and decompile your logic routines to see what you're doing.

While something like this certainly won't make your program bullet proof, it can make things a bit trickier to figure out by someone who doesn't know what you're doing, without breaking anything.

You can also complicate things further by using cross-referencing certain things in less obvious places. e.g. the same routine that drops a bonus extra on the screen could have a couple of extra checks that sees if certain 'impossible' conditions have occured since the last time it was counted. (e.g. you have more than -x- lives now without receiving any 'new life' opportunities, which could indicate that you may have cheated.

Rather than your program complaining about that immediately at that point, you could set another variable to indicate that the person is likely cheating, and could possibly check for that at a later point in a different function before taking action... For example by letting things continue just fine, but disallowing the submitting of a high score after the game finishes.

Anyway, it is very easy to lose track of what you're doing yourself, and end up with an unmaintanable piece of code yourself, so you need to be -very- careful, document -everything- you're doing for later reference yourself, and ask yourself whether or not it's a good idea to try to even go that route... But if you do, the above might be helpful.

Do realize that you can only make it a little trickier to prevent people from messing with it, never impossible. You might weed out some of the wanna-be crackers though.