As should be clear by now, there are a million things to hack in a million different ways.

By just guessing what his situation is we can give advice all day long and never provide what he needs.

3TATUK2, you should be reading all replies and thinking about what information you wish to share. Is it offline or online? What kind of data do you wish to protect? Do you wish to prevent certain kinds of behavior?

Another over-generalized piece of advice I can give you: Never use globals/statics/singletons/etc. Not only is it a sign that your code is bad, it is a hacker’s dream-come-true. Anything that never changes addresses in the final .EXE (or changes predictably, such as global data inside DLL’s) makes a hacker’s job 10 times easier.

L. Spiro

It’s very easy to exploit.

The game itself has to know which value is the correct one. That means it has a pointer to it or an index or some flag that indicates which one it is.

In MHS it is trivial to use the Expression Lock to use the same method the game uses to figure which is the correct address to lock.

L. Spiro

Interesting topic, how does this work with games developed in Mono/.NET? Are these as simple to cheat?

I haven’t tried those, but interpreted languages such as Java are extremely difficult to hack. The health value (or any value) moves around in RAM and the only way to keep track of it is to follow a crap-load of pointers through the Java run-time, and offsets will be different for every version of Java, meaning you can’t distribute anything you make.

Ultimately, cheat protection boils down to reducing how much spread a given cheat has, not the actual prevention of the cheat itself, because that is impossible. Cheats will invariably be made for any major game, but if they only work for a handful of people then it isn’t a major deal.

For any interpreted language, you can often find a value only once, change it, and then you have to find it again. Making a stand-alone cheat is usually not practical.

L. Spiro

One thing i'm specifically interested in is... say the address of the variable *does* change - but changes predictably... for example, only between one of two addresses... Is something like CheatEngine able to exploit this? I've tested with a friend of mine and he couldn't quite figure it out... If he locked both addresses, for example, then the game would crash

Cheat Engine and several other memory scanners allows you to track down where a variable is being stored. So, once you find this, what'll probably be a function, you'll have the variable under control. By this, I mean you can even keep track of variables that change address even if they always change to a newly allocated block.

Download Cheat Engine, try to go over their beginners Tutorial (under the Help menu). You'll understand a lot better how these work when you've successfully finished it.

Interesting topic, how does this work with games developed in Mono/.NET? Are these as simple to cheat?

I do not know Mono, but if it is an interpreted technology it is harder to hack with memory scanners. Still, some may be susceptible to direct file editing, making it easier to create hacked/cracked versions of the application.

Wat?


Using "fewer registers" doesn't make any sense. First of all, that means more stuff will be spilled to stack memory, where it's actually easier to find and modify. Secondly, it's going to be transiently limited to the runtime of a single function at most, so those values still have to go back to stack or free-store memory at some point. Finally, on platforms like x86-32, there's already so few registers available that this is just... not smart to try.

And for all that, it wouldn't stop a determined reverser for more than about 5 seconds, and then they'd laugh at how silly your "protection" is and trivially crack it anyways.

Yep. I'm no expert, and I don't mean to be. I just thought the notion was amusing at best. In the end, trying to protect a locally-controlled (to the user) game is foolhardy and not worth pursuing.

If I saw that happening (and it would be a little hard to notice, though it wouldn't slow down a disassembler for one second) I'd rejoice because it would mean that it would be easier for me to write assembly hacks. Registers reserved for hacking! Yay!

I do not know Mono, but if it is an interpreted technology it is harder to hack with memory scanners.

Just to clarify: While the JVM may interpret the byte code for some time before translating it to machine code, the CLR (and I believe Mono as well) will never interpret anything.

Like L. Spiro said, what makes memory scanning in managed languages somewhat harder (or rather, more tedious) is the ability of the VM to move around objects in memory at will. This will most commonly happen when the garbage collector compacts the heap after a successful collection.

The thing that makes interpreted languages hard to hack is their complexity, not just the fact that they move things around.

Any compiled language can emulate that level of complexity, but if it were that simple tons of games would be doing it.

In fact, that level of complexity requires generating a whole new language and optimizing it enough to be of use during run-time. The only reason Java and C# can get away with being “unhackable” (not to be taken literally) is because they had huge teams and millions in investments backing them.

This is obviously not plausible for any game team, and especially not for a single person.

If it was that simple, nothing would be hackable, as all game teams would jump onto the bandwagon.

Reiterating the point, if you try to emulate this with a compiled language by moving around variables, it will require more time and money than any hacker is worth, and it will cost you in performance as your game constantly looks up the value each time it is accessed.

L. Spiro