Making memory "read only"

[Leper]

is there any way to make bits of memory "read only" and then "writeable" only for a split second? So that a hex editor or memory editor would not be able to change variables within a running application?

[Savant]

What is it that you're trying to prevent exactly?

[Leper]

I'm trying to prevent a "trainer" or a hex-editor or memory editor from being able to alter any information in my program. :)

Example: changing score data, changing lives data, health data, powerup data, on and on and on :)

[Savant]

OK, now ask yourself if you truly believe that is worth spending time doing. Are you honestly able to say that there's nothing else that would be more worthwhile to spend that development time on? :)

[Leper]

OK, now ask yourself if you truly believe that is worth spending time doing. Are you honestly able to say that there's nothing else that would be more worthwhile to spend that development time on? :)


Well, I dont plan on implimenting something like that until I'm done with everything else. but cant you make everything "read only" or something? So nobody can penetrate?

[luggage]

Then how would you change it?

[Leper]

How would you change what?

[Leper]

Since we're in discussion:

Consider great info I got from IRC:

<Shagwana> there is a way MattMcFarland
<Shagwana> but it requires lots of workage
<Shagwana> client records moves made in game by the player
<Shagwana> when score gets uploaded so does the "replay data"
<Shagwana> then server side app, validates the score
<NoodleCower> buy a tried and true network lib and you'll probably get better security and save time
<Shagwana> you cant get any better then what i propose!
<NoodleCower> getting a bit full of yourself there, shag -_-
<Shagwana> security wise, its unhackable
<NoodleCower> can you prove that?
<Shagwana> unless the server falls
<Shagwana> well its the way loads of play for gain type of web sites operate
<Panno> hi
<Shagwana> iewww.gameaccount.com www.midiaplayer.comwww.skilljam.com
<NoodleCower> i'm positive they have more robust security systems in place, shag
<Panno> scouse ?
<Shagwana> im sure its not there only method of protection
<NoodleCower> your idea is extremely prone to fault if the person finds out how to modify the replay data
<Shagwana> still needs to be validated
<NoodleCower> heck, they could write something to make an extremely awesome score, send that awesome score, then send a replay that makes it
<Shagwana> ie - only valid moves can be made
<Shagwana> well thats venturing into writing a computer app to play an app
<NoodleCower> it's been done
* Shagwana knows cause hes done it himself
<Shagwana> there are ways around protecting tho
<Shagwana> two games from human players should never be the same
<Shagwana> a cpu playing the game - will give the same resposes to the same stimulie
<Shagwana> statistical anaylist can show players that are cheating

[Shagwana]

:D its me!

[Bmc]

it's called a checksum look into CRC32 algorithm

[Nikster]

Another note is not to have your variables static, so have floating variables allocated which contains info, having a place in memory that is at a constant address makes it easy to change values, that coupled with bmc's checksum comment and if you plan on using a 3rd party tool such as software passport (armadillo) that's about as good as it gets jst for protecting your application, on the other hand, all that will be in vain if you don't secure the data you're sending over the tinternet anyway :)

[DragonsIOA]

If you don't plan on doing multiplayer, or having some form of online high score system, I'd say don't bother with it. All of the client-side tricks listed here are very easy to beat (I did trainers before I got into making games). You could in theory make a section of memory read-only, and then "unlock" it when you need to change something, but since a decent trainer will inject itself into your game (usually via a message proc hook), it can do the same thing.

Now if you are planning to do something online, I don't have any suggestions for that. All my trainers purposely left alone any online aspect :)

[Nikster]

If you don't plan on doing multiplayer, or having some form of online high score system, I'd say don't bother with it.

Goes without saying really :) hardly worth the effort for no gain.


All of the client-side tricks listed here are very easy to beat (I did trainers before I got into making games).

I worked on a game a few years back which on the original release we just had bog standard variables for high scores which were compromised in no time to hack online scores, which why a majority of games are easy to make trainers for as there's no reason to hide the stuff as with my agreement above regarding an offline score system. However, we moved to using floating variables using a few threads and it was never compromised after that, so not as easy as you may suggest.

However, which brings me onto my main point and why I mentioned armadillo in a previous post, how exactly do you hook up anything without being able to walk the code to find what to hook ? which is what armadillo claims to do, I'm more interested in the fact that if it's as easy as you suggest I would have second thoughts in purchasing it (as I'm just about to do) as if it's easy to inject code it kind of defeats the "armoured shell" that armadillo claims to be :D

[DragonsIOA]

The problem with dynamic (floating) variables is that the pointer to it has to be stored somewhere. It may defeat most of the simple trainer makers kit out there, but if the hacker is determined enough, it isn't real hard to code a routine that will search out the address automatically. I haven't used a recent version of armadillo, but I can see where using something like nanites(?) or whatever it uses now would definitely make it harder, but not impossible. The bottom line is that for online play, you should always assume that the client has been compromised.

[Mike Wiering]

There are lots of ways to hide the contents of variables in memory. In my game Charlie II all important variables are XOR-ed with random numbers that change every time the varable is used. Somewhere else I keep copies of the actual values (for hackers to play with). If any of those are altered, the game halts with a "memory error".

[Savant]

I'm surprised you guys expend this much effort on this sort of thing. Why? Are you running contests related to your high score boards because, honestly, I see little reason to bother otherwise.

[Leper]

I'm surprised you guys expend this much effort on this sort of thing. Why? Are you running contests related to your high score boards because, honestly, I see little reason to bother otherwise.

Some of us really just want to see true high scores on the board, and also some of us really want to discourage hacking / cheating. Its not going out all in vain as you suggest, and I'm not really sure why you seem so passionate against putting effort into anti-hacking techniques. I for one dislike foul play and I find the effort worth-it. Even if people still find ways to cheat, atleast they earned it by cracking my system. If someone wants to crack it, they're going to have to do some labor to do so.

[Leper]

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).




Joe Bourrie - Game Designer


A very good read from gamedev.

Here's the thread:
http://www.gamedev.net/community/forums/topic.asp?topic_id=359385

[Savant]

Some of us really just want to see true high scores on the board, and also some of us really want to discourage hacking / cheating. Its not going out all in vain as you suggest, and I'm not really sure why you seem so passionate against putting effort into anti-hacking techniques. I for one dislike foul play and I find the effort worth-it. Even if people still find ways to cheat, atleast they earned it by cracking my system. If someone wants to crack it, they're going to have to do some labor to do so.
I'm a strong advocate of focusing development effort where it will do the most good. If you really feel that protecting memory and obfuscating high score data is the best use of your development time then great; have at it.

I disagree. That's all.

[Leper]

I'm a strong advocate of focusing development effort where it will do the most good.

Well, I can see why you would say "dont focus dev on deterrants" so you can get the game out quicker and better (more focus on polishing, etc) and that is very important when it comes to the development business.

I agree with you in that aspect. But I'm not making a shareware game, and I'm not pressed for time, and I dont have shareholders or investors breathing down my neck for a release date. :)

So if I want to obfuscate code, what I get in return is a great learning lesson which I think should be done by everyone. It's a great way to learn tricky stuff, and I dont think its a bad thing when you are in "student mode" as opposed to "business mode"

[DragonsIOA]

There are lots of ways to hide the contents of variables in memory. In my game Charlie II all important variables are XOR-ed with random numbers that change every time the varable is used. Somewhere else I keep copies of the actual values (for hackers to play with). If any of those are altered, the game halts with a "memory error".

A scheme like this will stop most casual gamers, but it's still a good idea to do some form of sanity check on the server side. For what it's worth, it took me about 10 minutes, and one changed byte to get unlimited lives in your game.

[Mike Wiering]

it took me about 10 minutes, and one changed byte to get unlimited lives in your game. What?! Which byte was that??? :)
Yes of course, there are still lots of ways to get around this kind of protection, but it should stop players who use those special cheat programs for games that let you look for certain values in memory and change them.

[kingaschi]

There is just no way you can prevent people from changing your code!
You can make it really hard for them but it will be hard for you as well.
Somebody will eventually find a way to access scores or other things.

The solution:
-> Don't give them the code!

My games are multiplayer, so all the game logic/core is on the server.
Unless somebody (1) hacks the server and (2) hacks the code there is
no way to mess things up. Servers nowadays are pretty secure.

The client code can be hacked, but then, all the moves are evaluated on
the server, so there is no way you can send fake moves ...