Link to home
Start Free TrialLog in
Avatar of Valleriani
VallerianiFlag for Sweden

asked on

Protecting values from being memory hacked in C++?

I have C++ application/game. Right now there are long/short values that represent shields, power capasity, and so forth.

I found out you can actually use a memory hacker (Like Cheat Engine) and freeze these values or change them to be higher for unlimited power. Which is pretty much an issue.

I wanted to know what I can do, if there is any coding to prevent memory hacking (For example steam has punkbuster or whatever).

I was also thinking if this is not the case, then I can modify the values to have a random seed each game added on in the value, then remove the seed when there used, and readd it when there stored again. Kinda like so theres a random value.. For example

Shields are 3000
Random value is 302
VAlue stored is 3302, when called it will remove the 302 to use, and then readd.

The issue with this is the games pretty big and would require a pretty big add to many values, and I'd have to find areas, so first I was wondering if there is any way I can stop memory hacking via coding or something like that.. Any suggestions?
Avatar of Zoppo
Zoppo
Flag of Germany image

Hi Valleriani,

just an idea: maybe you could implement a fast method to calculate some kind of checksum over all values you want to protect. Then whenever you need to change a value you can first calculate the checksum anew and check if it equals the checksum calculated before, then change the value and recalculate the checksum. To hack this a hacker would have to determine the algorithm you use to calculate the checksum. You could add a random generated seed value to the checksum calculation which is initialized when the application starts. With this you can avoid that a hacker can just remember which checksum fits to which situation.

Of course this is not a real secure solution, but it will make it more difficult for hackers ...

ZOPPO
If the server keeps track of the valid values, then a client can tamper with them as much as he likes ... The server's values are the correct ones, and the cheat attempt will soon be noticed/rectified.
Or put differently : don't trust anything the client claims about those values. The values kept in the server are the authoritative values, and the only ones that are ever used. Sure, the user will be able to "cheat" and make the client display a different value (for the health level for example), but the server will still be using the correct (unmodified) value (and if the health level drops to 0 on the server side, the player dies, no matter what health level the client shows).
Hm - is it a client/server game? Or a standalone game?

BTW, I don't know about tools like 'Cheat Engine', but if your application uses .net and those tools run as a different process it may be you could use protected memory to protect these values (see class ProtectedMemory).

ZOPPO
If its a local standalone game, I think checksum is a good way to go, but I would go one step further. If performance is not an issue, and you don't have to access the values many thousands of times per second, then you can use a fast encryption mechanism to make sure the memory is not cleartext readable. In the end, for standalone games, I would just let the cheat cheat, he is only cheating himself.

If client/server, then I agree with Inifity's statement, tampering should not be possible, by design.
>> In the end, for standalone games, I would just let the cheat cheat, he is only cheating himself.

Which is why I assumed it was a client/server game. If the user gets his fun from cheating, then why not let him ? As long as the cheating doesn't impact anyone else's game experience (which is true for a single player standalone game), there's no problem, is there ?
>> if there is any way I can stop memory hacking via coding or something like that
Package up yor game in a packer/protector. These provide a secure runtme enviroment that is resistant to hacking.

Examples; http://www.fileheap.com/software/protector_packer.html
>>I wanted to know what I can do, if there is any coding to prevent memory
>>hacking

If you are on Windows, set up a memory page that has the 'PAGE_GUARD' attribute set, so that an exception is thrown when that page is accessed and you then in turn can validate if that acess is legitimate. See also http://msdn.microsoft.com/en-us/library/aa366898(VS.85).aspx ("VirtualProtect")
Avatar of Valleriani

ASKER

I am thinking about going through the checksum way, just a bit more hassly because I have to recode a good portion of it then, theres more then just shields, for example.

It is server/client yes.

The server does everything but player, the player is client side, much like Continuum, or Counter-Strike, which I believe just get inital values from the server and when changing stuff, but not during the main battle/fight, same for my game right now.

Also, how would I use page_guard/virtualprotect. Is there any examples around on how to use it? It seems like a great idea.

A Packer/Protecter would of worked -- If I could find any that actually worked and are free or are cheap.. Any suggestions to one that works good and is remotly cheap if thats the case?

The server will ventually do everything, client and server, however, if tis a couple day fix I will do it for now. I am currently working on adding a new game engine and throwing in DirectX, and upgrading the network coding, but that won't be done for a bit, and there are a few people who do abuse it once and awhile online, which is a shame.
^^ And rather, I will be going through the checksum way if other ways don't work. ;)
ASKER CERTIFIED SOLUTION
Avatar of jkr
jkr
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hey jkr, I am trying it out now, a few things I noticed.

It stops 'debuggers/disassemblers' from working good, but the ones where you can change memory instantly (Like cheat engine) still seems to go through, is there anything here I s hould be specifically looking at/ I've tried a few here so far but might be doing something wrong..

Thanks!
You mean the part with 'MemoryBreakpointDebuggerCheck()'?
Yes, my bad.

It seems to work well against WinDBG and other actual debugging processes, but against Cheat Engine or programs that just directly edit memory values/address it doesn't detect at all and the values can still be changed/
You should change to code not to explicitly check for a debugger, since these cheads might not act as such (i.e. use 'DebugActiveProcess()' to attach to your program).
Thanks, I'll go play around with this and see what I can do.. Any suggestions on what a program like that could be using?
Well, basically 'ReadProcessMemory()' and 'WriteProcessMemory()' to alter the values - but these will trigger teh exception when using a guard page.
>> The server will ventually do everything, client and server, however, if tis a couple day fix I will do it for now.

>> and there are a few people who do abuse it once and awhile online, which is a shame.

These two are cause and effect. As long as you don't fix the first, the second will keep occurring.
Using memory guards, checksums, etc. will only slow the cheaters down slightly. It's not fixing the problem though. The only secure model, is to not allow the client to make any meaningful decisions (other than the normal game mechanics obviously), but let the server track and decide all important values.
>>but let the server track and decide all important values.

That would be the ideal solution, but for action-driven online games, it bears a big risk: The infamous lag, which can render these games unplayable if not all players have a higher-than-highspeed connection. If you are interested in that issue, take a look at the docs and discussions at www.sauerbraten.org (a Cube engine based game)
>> That would be the ideal solution, but for action-driven online games, it bears a big risk:

Just to clarify. The client would still be computing, and using its own values (which avoids the lag issue). They would just regularly get synchronized with the server's reference values. And a few important things, like player death, would trigger the server to immediately "end" the play session (or otherwise handle the death appropriately).

So, if the client cheats, he'll only be cheating on his own screen. None of the other players will be impacted by his cheating (ie. if the user uses an invincibility cheat, he'll appear to be invincible only to himself, but all other players and the server will still see his health go down until he's killed), and the cheater will gain no advantage from his cheating - in fact he'll get a disadvantage, since he'll think he's doing fine ("I'm invincible"), while in fact he's not.