how to Protect application process from ReadProcessMemory and WriteProcessMemory

Hi,

I wrote a game using vc++.
I want to protect my application from hackers.


My intenction is dont want to allow other persons to access my process and dont want to allow
ReadProcessMemory and WriteProcessMemory Functions .



Please help me soon, its urgent.

My knee-jerk response to your problem is that it's their computer and they get to do what they want with it. You can confuse and obfuscate things if you want to make it hard for them to crack or cheat on your game, but when you get right down to it I don't think you can prevent it.

Remember that the kind of person who's going to be poking around in your game's memory is also likely to be the kind of person who won't be put off by simple tricks, either. The people who know what they're doing will crack your game and then tell their buddies (who don't know what they're doing) how to do it.

One thing you might want to avoid is storing your data in (just) simple variables. For example, if you have:
int score = 3000;
then they can look at the score on the screen, see it's 3000, then find a 3000 in your memory... and change it. Instead think about storing your score as at least two variables, one (or more) would represent the score, and the last would act as a checksum. Then when he changes the 3000 to 1000000 your program checks the checksum, sees that it doesn't agree with the score, and the program exits with an error.

Doing stuff like that can help, but if someone bothers to disassemble your program they can figure out how to get around that too. It really just comes down to you setting the bar high enough that people don't want to bother.

Hope that helps.

Safety doesn't exist. The only thing you can do is make it as hard as possible to crack. This will always a be a cat and mouse game. If there where some simple functions you could call or block to completely protect your application, then why has MS such a hard time of protecting their OS against hackers ;)

Well there are several ways you can attempt to go about this. First you need to make sure you have some sort of software protection. (Themida is easily broken now so I suggest looking into something like VMProtect, or you actually could just use CodeVirtualizer). That will help prevent them from finding what needs to be patched in the game. However, this alone is very weak in all honesty.

Using something like CodeVirtualizer and deploying a new update to the game every 5-10 days will totally ruin them and eventually just make them quit. Each time an update comes out, they have to reverse engineer the game again and refind the structs and what not that they manipulate. So if you deploy new updates that frequently they will eventually just say the game is too much of a hassle and then quit trying.

Then there is always the choice of making drivers run from ring 0 and protect the game from there, from any sort of memory manipulations (such as some antiviruses do), and/or you could even make a driver that monitors the SSDT and then catches when WriteProcessMemory or ReadProcessMemory is executed and you can squash those calls if they're pointed at the game. Obviously this is getting a bit more complex. But if you protected your game from ring 0 and caught those function calls, hackers would most likely come out with a driver with their own code for WriteProcessMemory and ReadProcessMemory (difficult, but definitely possible for experienced hackers), then you would need to do things like monitor certain Control Registers with other key things going on in the system to see if there is any memory manipulation going on (the key of that would be finding the area in memory your game is running and making sure nothing even attempts to get to that area, but then you have to make sure you don't interfere with the actual operating system, and of course this will cause issues with anti-viruses).

So in all honesty a good software protection and a frequent updates will definitely be the best way to go about this.

Quote:

---

My intenction is dont want to allow other persons to access my process and dont want to allow ReadProcessMemory and WriteProcessMemory Functions .

---

Hint: As long as this is OS that provides those functions, you definitely have to fix the OS. Or stop writing games maybe...

Quote:

---

Please help me soon, its urgent.

---

I could understand when it to be urgent in case of life and death matter. But how that could be urgent with a game??? :sick:

Please give me suggestions. Your suggestion will save my lifes.

Didn't you read the answers from Igor Vartanov, Rehorav, Skizmo, Ankheg? :confused:

Quote:

---

Please give me suggestions.

---

I give you a suggestion: Google for code protection solutions. And... something makes me believe you should prepare your money for having any. :) By the way, I doubt that those solutions will mess with denying for Read/WriteProcessMemory. As I already said the functions are provided by OS and appear available always as long as you have privilege enough for running those.

Quote:

---

Your suggestion will save my lifes.

---

This trick hardly works here. :)

As MS couldn't save its products from crackers to patch it how can you ?

1) If this is a stand alone one-player game. I honestly wouldn't put too much effort in it. In the end, if they want to cheat, they're only hurting themselves.
If this is a multiplayer game, then the key issue is that you make the client responsible for storing the least amount of data possible. Especially in regards to other players information.

I remember a case where a game (I believe it was one of the age of empires) stored/synced data of the opponents, and basically you could read out the resource values of your opponents. By knowing those and looking at distinct changes, you could even extrapolate which buildings/units your opponent was making. In a case like that you're really entering a case where one player's cheats are going to have a serious effect on opponents.
So in some cases, just being able to READ data can give you a serious advantage. Typically you don't want to send data to the clients about stuff they can't/shouldn't know about. The bad part about that of course is that you're going to put a lot more coordinating/calculation on your server, which will impact how many games can be hosted per server.

Similarly in one of the FPS games (doom/halo ?) there were cheats that would autoaim onto opponents effectively taking a large amount of the skill out of the picture as well.

2) You CANNOT prevent process memory being read or written.
It's technically possible (but requires a lot of effort) to detect someone's reading your process memory, but this can be worked around with a rootkit.
It's a lot easier to detect someone has written into your process memory, and particularly in your data sections.
Basically, make a storage class/object that has all the data you want and make the data private. Then make accessors to read/write the data. When a variable is changed, you also calculate a checksum/crc. When the checksum mismatches, someone's been cheating.
Of course, it's still possible the hacker figures this out and changes the checksum himself also (or even ends up using your write functions). What you do when you detect a change is up to you of course.

3) Most hacks/cheats are done by scanning process memory looking for known variables. If a score on screen is shown as '3000', then it's likely there's an integer or float value holding the value 3000. When the score changes, you do another scan and check which memory had 3000 before and now has the new score.
You can stop/block those off by storing data in weird formats. An easy way out if using a scaling factor. Multiply everything by 173 (or whatever), this'll make it a lot harder to actually find data. A really dedicated hacker won't be stopped by this, but it'll typically block off the 99.999% of the "script kiddies" that don't know how to program and just use generic cheat tools.

4) Server side syncing.
You can also protect yourself against writes by calculating all data server side as well. This works well for RTS/sim type games that revolve around accumulation and expending resources (gold, wood, ore, stone...). If the client is doing something that it can't technically do. Say build a certain building which it allows because the cheated client thinks it has enough resources, then your server side detects it can't possibly build it, you can take action also.

5) There's a lot you can do to make it hard(er) for a hacker/cheater to abuse your game. But it will all take effort, and possibly take more effort on your part than on your users. All I can say is that it's not going to be easy. Hackers/cheaters tend to be VERY creative and very tenacious and will often go to extreme lengths to get an advantage over someone else.

6) The best way to make a multi user game hack proof is essentially to have all the calculation/scoring/storing happen on the server. With the clients only ending up taking care of displaying the data the server is sending them. But this puts a lot of strain on the server AND on your connection, and it may also mean that people with a higher latency to your server end up being severely impacted. It depends on the type of game you're making, but the typical answer remains to have the clients be responsible for as little as possible/feasible and especially prevent clients to have copies of opponent key data. (although that's not always possible).