C2 projects hacking prevention

Discussion and feedback on Construct 2

Post » Thu Apr 20, 2017 7:44 am

Hmmmm.... sounds pretty bad, especially if you're planning to do any type of competitive multiplayer if values can be altered like that.

I would like to know:
Can this be done to mobile games also?,
Does all html5 games have this issue, or is construct games more vulnerable ?
Can you do this to basically any game on other arcades like kongregate or newgrounds?

I guess cheaters will always find a way to cheat, but at least you shouldn't make it easy for them to do so.
Follow my progress on Twitter
or in this thread Archer Devlog
B
40
S
17
G
17
Posts: 980
Reputation: 12,632

Post » Thu Apr 20, 2017 8:34 am

I worked on a multiplayer game before but sadly hacking and cheating isn't isolated to a few users anymore. A very large portion of any online mutliplayer games users are willing to cheat which ruins the game for everyone else.

I saw a talk about the cheating problem on steam and that counterfighting it took so much time that they didn't have time to work on the game and just had to focus on the anti cheat system.

After this I realized that online multiplayer in C2 is just too complicated to protect so I lost the motivation to continue and kept focusing on local multiplayer instead. Because I don't care if people cheat in those kind of games. If people want to cheat they can as long as others doesn't suffer.

Same goes for mobile games, just open it with your text editor of choice and change the variables and boom you have all content unlocked, no ads and can crush all your opponents online in seconds ;)

And btw, where did my avatar go??
B
55
S
24
G
13
Posts: 765
Reputation: 12,571

Post » Thu Apr 20, 2017 8:52 am

I wonder if policing variables in events would help?

Clamping certain values i.e health and ammo; running checks on others like score such as monitoring the difference/jump in score from one second to the next, and resetting it if it's too big a jump to have happened naturally.
B
59
S
21
G
10
Posts: 643
Reputation: 10,293

Post » Thu Apr 20, 2017 9:45 am

Elliott wrote:I wonder if policing variables in events would help?

Clamping certain values i.e health and ammo; running checks on others like score such as monitoring the difference/jump in score from one second to the next, and resetting it if it's too big a jump to have happened naturally.


I've tried some counter measures like that. For example:

The game only allows maximum 5 arrows per player in the game. If the total game arrows are is more than what's actually allowed. (Number of players x 5) you're your actual arrow count is reset, to how much you should be allowed to have.

Player 1 has 7 arrows.
Player 2 has 1 arrow.
YOU have 0 arrows.
On the ground is 7 arrows.
= 15.

You won't be able to have more arrows than is allowed in the game (3x5=15), so you need to destroy one ground arrow before you can increase your arrow count.

Works pretty well, but I probably have to spend more time on things like this to make it even more secure later. I'm probably going to move a lot of variables to be stored in the game room / photon cloud instead of locally as I'm doing now, to prevent it even further.
Follow my progress on Twitter
or in this thread Archer Devlog
B
40
S
17
G
17
Posts: 980
Reputation: 12,632

Post » Thu Apr 20, 2017 10:14 am

@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.
Banned User
B
17
S
7
G
23
Posts: 388
Reputation: 13,994

Post » Thu Apr 20, 2017 10:40 am

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.
Scirra Founder
B
397
S
236
G
88
Posts: 24,422
Reputation: 194,553

Post » Thu Apr 20, 2017 10:54 am

@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:
Image


I think at the end, a good server-side validation system is the only way to prevent such hacks.
Banned User
B
17
S
7
G
23
Posts: 388
Reputation: 13,994

Post » Thu Apr 20, 2017 11:25 am

X3M wrote:@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.
Follow my progress on Twitter
or in this thread Archer Devlog
B
40
S
17
G
17
Posts: 980
Reputation: 12,632

Post » Thu Apr 20, 2017 1:27 pm

@tunepunk +1
Banned User
B
17
S
7
G
23
Posts: 388
Reputation: 13,994

Post » Thu Apr 20, 2017 5:27 pm

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 [email protected].
Mistakes were made.
B
52
S
26
G
109
Posts: 1,606
Reputation: 61,633

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 10 guests