Making variables "unhackable"
Author
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.
I've heard of using two variables to store the same data...if one doesn't match the other, then make them match or something like that...don't really recall the details. It can still be worked around and edited though, as I imagine any data can be. :P
Author
I was thinking of making make 100 variables in an array where some are floats and some arent and some are multiplied to reach what the ultimate score variable is.
Then when it goes online all have to match or it doesnt work.. or something?
hmmmmm...
isnt there a way to make the data copy-protected or something? like make it so that only one thing can edit it at a time? or make it "read only" and then writeable only at a split second?
Then when it goes online all have to match or it doesnt work.. or something?
hmmmmm...
isnt there a way to make the data copy-protected or something? like make it so that only one thing can edit it at a time? or make it "read only" and then writeable only at a split second?
The bottom line is, you can't control what users do on their own machines. You can obfuscate your code, but that's only a deterrent. As you put more and more effort in, you run up against diminishing returns.
What the AP said is correct. However you could log the relevant actions in your game and send them to your server where you can use them to check if the score is possible in a safe environment. The more complex your game is the better. A game where clicking very fast is the way to earn more points is hard to validate. However (simple) cheating in a game where several actions have to be done is a special way and in an realistic timeframe is easier to detect.
I hope you understand what I'm trying to say. :-)
I hope you understand what I'm trying to say. :-)
Quote:Original post by MattMcFarland
I was thinking of making make 100 variables in an array where some are floats and some arent and some are multiplied to reach what the ultimate score variable is.
If used every cycle of your game, this will simply result in taking up more time, slowing down the app as a whole...and it could only make it more difficult to crack (not impossible by any means).
Consider that you'll also need to come up with something so they can't just write a program to sumbit a fake score to your online score system.
A pretty simple method would be to store the score in several different places in different ways (e.g. 1 version may have 1000 added to it, one version may be a float, another version xored with something) then you'd just compare all the versions when updating the score. This will probably stop someone with one of those cheat programs that lets you search for specific values in a processes memory and alter them, however it won't stop a determined hacker. In fact you're never going to stop a determined hacker, as the AP said you get diminishing returns, you can never make it totally secure, you just have to decide how secure you want it.
A pretty simple method would be to store the score in several different places in different ways (e.g. 1 version may have 1000 added to it, one version may be a float, another version xored with something) then you'd just compare all the versions when updating the score. This will probably stop someone with one of those cheat programs that lets you search for specific values in a processes memory and alter them, however it won't stop a determined hacker. In fact you're never going to stop a determined hacker, as the AP said you get diminishing returns, you can never make it totally secure, you just have to decide how secure you want it.
I am working on a game that has an online scoreboard as well. The way I protected the DWORDs is I made a class that stores the two variables as mentioned above. The trick is that the second variable is a random number. Then I either subtracted, added, or xor'd (or something) the variables current value with that second value. If they didn't match up after whatever operation was performed on it, it marks modified memory. It's had substantial success so far but I'm sure any really good hacker will be able to massage the data however they like. For example:
with subtraction:
if (m_CurrentValue != (m_StoredValue - m_CurrentValue))
return true; //memory was changed
Nothing is perfect but you can write a class with overloaded operators that will directly plug into your current code. Also in answer to one of the other posts, I encrypt the data into a small GET parameter which is sent to a php script for decrypting and parsing. I'm sure if they intercept the data at the right time they could probably adjust the string so theres a lot of redundant info in there for calculations. Once again, nothing is perfect.
Also I store the actual score information as the pieces required to calculate the score. Most hackers will check the memory and adjust the score which could set a flag to either purposely corrupt or just disallow uploading (hackable too). Either way I simply recalculate the score at the end and if it doesn't match it's yet another hurdle for the persistant hacker.
with subtraction:
if (m_CurrentValue != (m_StoredValue - m_CurrentValue))
return true; //memory was changed
Nothing is perfect but you can write a class with overloaded operators that will directly plug into your current code. Also in answer to one of the other posts, I encrypt the data into a small GET parameter which is sent to a php script for decrypting and parsing. I'm sure if they intercept the data at the right time they could probably adjust the string so theres a lot of redundant info in there for calculations. Once again, nothing is perfect.
Also I store the actual score information as the pieces required to calculate the score. Most hackers will check the memory and adjust the score which could set a flag to either purposely corrupt or just disallow uploading (hackable too). Either way I simply recalculate the score at the end and if it doesn't match it's yet another hurdle for the persistant hacker.
Heres a technique that I used in Rumble Box for the High Score Tourney. While it is very crude, it is also ridiculously effective at making a hacker's head spin. Misdirection and obfuscation is the key.
Note that this technique was used for scores that were written out to a file. You wouldn't want to do these calculations for every access of the variable in game, but it could be used to periodically update another variable, and if they ever go out of sync it has been hacked. That has the added bonus of the hacker finding the unobfuscated variable and not necessarily realizing that it is not the true storage place of the value they are looking for.
--------------
If you XOR a variable with a number, you get an obfuscated number. If you XOR it again, you get the original number back.
So you hash your score into a series of N numbers. Each of these numbers is then XOR'd with a different number (so a pattern cannot be seen easily). Then, you rearrange them, and add in N other numbers which are "test values", which is the original number XOR'd by a different number. Now test both values, and if they are equal then it hasn't been tampered with.
To go even further, the test values could be pulled from another table, or randomly chosen between two numbers (if either one works, the value is assumed ok) just to throw off most determined hackers.
The more obfuscated you make the number, the harder it is to figure out what the heck is going on. The fun part about this crude setup is that the element of randomness that you can add in. For instance, certain special numbers can say "don't hash me", and the test variables can duplicate themselves or in some instances (like when index % 42 == 0) they can just leave themselves out altogether. As long as what you do is reversible, you can obfuscate it all to hell. Misdirection is fun! Why not make it so that a set of the XOR values spell out a word in ASCII, so that a determined hacker might find that pattern, but then misspell it slightly... they may assume the misspelling is their algorithm's fault (compbter) or they may start thinking that the words are a pattern throughout the code and start looking for more words, when they really don't even exist. And so on, and so forth... it's not perfect, but it works pretty well.
Even more fun (though I've never done it myself) is the technique used with success by Chris Crawford in his "Patton" games : self-modifying code, so when a hacker tries to step through they find that a single address may do many different things. This is almost impossible to track, but it's also very hard to write (and in Windows it may be impossible, I'm not sure).
Note that this technique was used for scores that were written out to a file. You wouldn't want to do these calculations for every access of the variable in game, but it could be used to periodically update another variable, and if they ever go out of sync it has been hacked. That has the added bonus of the hacker finding the unobfuscated variable and not necessarily realizing that it is not the true storage place of the value they are looking for.
--------------
If you XOR a variable with a number, you get an obfuscated number. If you XOR it again, you get the original number back.
So you hash your score into a series of N numbers. Each of these numbers is then XOR'd with a different number (so a pattern cannot be seen easily). Then, you rearrange them, and add in N other numbers which are "test values", which is the original number XOR'd by a different number. Now test both values, and if they are equal then it hasn't been tampered with.
To go even further, the test values could be pulled from another table, or randomly chosen between two numbers (if either one works, the value is assumed ok) just to throw off most determined hackers.
The more obfuscated you make the number, the harder it is to figure out what the heck is going on. The fun part about this crude setup is that the element of randomness that you can add in. For instance, certain special numbers can say "don't hash me", and the test variables can duplicate themselves or in some instances (like when index % 42 == 0) they can just leave themselves out altogether. As long as what you do is reversible, you can obfuscate it all to hell. Misdirection is fun! Why not make it so that a set of the XOR values spell out a word in ASCII, so that a determined hacker might find that pattern, but then misspell it slightly... they may assume the misspelling is their algorithm's fault (compbter) or they may start thinking that the words are a pattern throughout the code and start looking for more words, when they really don't even exist. And so on, and so forth... it's not perfect, but it works pretty well.
Even more fun (though I've never done it myself) is the technique used with success by Chris Crawford in his "Patton" games : self-modifying code, so when a hacker tries to step through they find that a single address may do many different things. This is almost impossible to track, but it's also very hard to write (and in Windows it may be impossible, I'm not sure).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
