C2 projects hacking prevention

One hurdle you can throw in the way is to keep secondary values. A good attacker will simply directly modify values in RAM, and there are tools/techniques to identify where in RAM something like the score is kept. So you can do something like this:

• keep both the actual score, and a second "backup" value derived from the real value. A simple example would be e.g. keep the score * 2, but you'll probably want something significantly more complicated so it's harder to guess.
• have a function to change the actual score. This will set a new score and compute a new backup value.
• whenever you access the score, check the backup value is still correct. If it's wrong, re-set the value, kill the player, end the game etc.

The idea is if the game changes the score, it's accepted, but if any other external source changes the score, it's detected because the backup value wasn't changed.

Obviously this only affects the client side and it's a whole other story if you want to do something like post a score to a server, where it's probably impossible to prevent someone tweaking the value at the network layer, but you could still apply a similar approach there to make it harder again.

Ashley The attacker can also NOP the function which compares the two values, you can easily backtrack the function that accesses the Score memory address and the one which writes to it:

I think at the end, a good server-side validation system is the only way to prevent such hacks.

tunepunk Remember that anything that is client-side can be modified, so even if you do that ( comparing amount of arrows to a max value ) , the max value can still be hacked. So there is no point in that if the hackers will set their own max allowed arrows value.

Yes that's why I'm trying to move over many the variables to be stored in photon cloud. The max arrows value is not what your client say it is. It's what photon cloud says it is. I'm trying not to store any values locally.

Photon has pretty nice features to store variables per actor or per room. If you fire one arrow you don't get minus one to your local arrowcount, you get minus one to your photon actor property.

Actions like these. Set actor 0 custom property "arrowcount" to Photon.PropertyOfActorNr(0,"arrowcount") -1

So you can set your arrow count to what other players say your arrowcount is not what your client say it is

I've not messed with it too much, I just started to move over values that way instead, but it feels a bit more safe, and a bit more hard to alter.

tunepunk +1

Some sort of obfuscation would be greatly appreciated. Its one thing to say anything can be hacked, its another to literally bundle the tool needed to do so with your game with no way to control access to it. The issue is amplified by the fact that it is a standard platform with methods that can be applied to basically all games in this category.

Other games have debug modes that can break the game sure, but at least they have some semblance of control over them - either not accessible to end users or flags to disable achievements/scores when utilized.

The other argument that games "aren't worth" cheating at or that the population of hackers is low doesn't hold much weight. The high score/leaderboard is a fabulously clear example of how it only takes one person who wants to watch the world burn with too much time on their hands (there are actually quite a lot of these people) to ruin the experience or turn off all your other legitimate users.

To add insult to the injury, it turns out the developer himself can't correct the scoreboard. Seems easier to compromise the scoreboard than to correct it! BeastCoasting you might want to email .

I did and they recommended I reset my leaderboard...

BeastCoasting I'm sorry about the inconvenience, if I had known before that there was no option to remove a score from leader-boards I wouldn't have done this.