Obfuscate in game data?

Monkey Forums/Monkey Beginners/Obfuscate in game data?

Xyle(Posted 2015) [#1]
Well now that I'm somewhat happy about encrypting my server communication, as TeaBoy has brought up in a separate thread, what good is encrypting the data sent or received from the server if a user can alter the in game data by poking with the memory?

There are a few options that I've seen so far

Diddys Base64 can be used to Obfuscate text within the game, a simple approach

AES Module can do the same thing, it also uses encryption methods with password keys to make it even harder to poke around with.

Now my questions is, like with Diddys Base64, what exactly do you obfuscate?
The variable name? So that anyone with a memory reader can't easily find your health variables?
The actual variable data? If health = 90, the user can look at the memory for either health or 90 and alter it accordingly?

Can anyone give some examples of proper use for this soft of thing?

I am very new to this, but after some not so very nice guy hacked one of my scoreboards, I am a bit more paranoid!

Thank you very much!


TeaBoy(Posted 2015) [#2]
Base64 isn't really a method of encryption, you encode to Base64 to send binary data via protocols that are not 8 bit clean.

Apart from some clever behavioural / genetic algorithms I think you may be fighting a losing battle.

[edit] What about coding your game in C++ then use http://kripken.github.io/emscripten-site/ perhaps this will deter those that are not truely hardcore lol, I don't know, is it really worth consuming your dev life?


muddy_shoes(Posted 2015) [#3]
While putting some simple obstacles like obfuscating javascript to stop mildly motivated 8-year-olds from "hacking" your game is reasonable there is no way to get around the basic problem that you can't trust the client. Pretty much the best you can do is to try to ensure that you can verify that a score is reasonable and that you have some way of responding to suspicious scores.

So, you need some form of account/id/product key system that allows you identify the source of score submissions. Score checking depends on the design of your game but essentially it's about trying to judge if a submission actually resulted from someone playing the game. You can track time played, score over time, test against known possible score limits for particular levels etc. The gold standard is getting the client to send a full replay which the server can then check by playing it back, but this requires that your game is deterministic.*

Once you've determined that a player is likely spoofing you can then ban them or, maybe better, shadow-ban them or just cull the scores or whatever you like.

*Note that this still doesn't stop cheating via things like botting or slowing the game down.


Xyle(Posted 2015) [#4]
Thanks for the info,

according to the diddy docs...
"Base64 can also be used as a cheap way to obfuscate text. Although it can be decoded easily, it's useful
for hiding text from the casual user (for example, to prevent the player from accidentally reading spoilers)."

And I can see how it can be used as described, with a random function Base64 decoder, variables could be hidden and they would get hidden in random places depending on how you used it. I was just looking to see what anyone else is using or if they have other methods for obbfuscating in game data.

I'm not looking to make a Fort Knox code base or game here, just looking to deter the casual kiddies.

Coding in C++? Eeeeck, why would I do that? I love my MonkeyX! Plus I've never used C++! :)


Gerry Quinn(Posted 2015) [#5]
If the desktop is your target, you can use protection systems such as Execrypter, at least with C++. I'm not up to date with the latest tools but they have various key generation and anti-cracking tools.

Whether it's worth it is another matter.

You could also make internal validation checks for in-game data. That should be a reasonable deterrent to non-coders equipped with hex editors at least.


ImmutableOctet(SKNG)(Posted 2015) [#6]
As someone who started by hacking and modifying games, you really shouldn't bother with a lot. A leader-board (Or a similar setup) is a different beast than simply encrypting your data. If people are hacking your game, and being destructive by doing that, then you should be taking action. But if they're simply modifying the game, or messing with memory, you should just let them.

If they start affecting other people or systems, that's when you should step in. If someone wants to modify your game, they'll do it. And I don't see any reason to stop them. It's when it gets out of hand that you should be concerned about. And because you want to create a stable ecosystem (Like most developer's would), you should be working on the anti-cheat/anti-hack techniques that make your normal users immune to anomalies. You shouldn't bother stopping people who are going to break your code, anyway. Anything you do from the client can be hacked (Unless you're doing something very advanced with several clients), but the closed environment of a server is different. Take for example, most online multiplayer games. They're supposed to have several layers of security for stopping cheating and hacking. And though this work should be done, you should only do it in order to make the experiences of the normal users stable. If someone's cheating, you should not only have code in place to stop them, but also do the work to ban them (Or a similar system) when needed.

Obfuscation is done on some targets, anyway, but it doesn't do much but potentially slow people down. But no matter the target, you shouldn't be modifying your existing code to have weird names, or to constantly check variables. Because, as someone who started by hacking, I can tell you that anything you do in your code can either be switched for something else, or studied enough to be modified. Names aren't needed, and using base64 for normal text can be a serious waste of time. And trust me, obfuscating everything never works. You can even look at games which use Game Guard, for example. They use really low level techniques, sometimes even dirty hacks, and they can be compromised with a simple DLL injection. And there's a ton of horrible things Game Guard does to users' systems, like stopping them from running their own media players and muting the game. Or making programs outright crash if they're started after the game. Or even making it so users can't alt-tab out of fullscreen, or even windowed mode.

The point I'm trying to make is that you're looking at this wrong. Your games shouldn't focus on keeping hackers and modders out, but instead keeping things stable for normal users. Sure, security should always be a priority, but obfuscating your memory isn't the way to go. That effort should be put into security that really matters. Companies like Valve have already shown that rewarding modders and hackers is a good thing. And when people have a platform for their mods, they don't need to do any work hacking through other means.

This is why games like Doom and Quake became as open as they did. It's better to let people modify and hack the game within reason. Doom even had a level editor, for crying out loud. Not to mention that the source code for the first three Doom games has already been released.

Personally, I like the Doom approach. Games I release will likely have most (If not all) of their source code provided as public domain after a while. I think modding should be a big part of a game, so I may very well put in work to get more advanced modding working, without editing the game's memory or executable. For example, some games use Lua, Squirrel, or even Python for further modding potential. As far as Monkey goes, MiniC and MiniC N. Edition are options, as well as several external routes.

I wrote a similar post about this a month or so back, if you're interested.

The moral of the story is: Put the work in for what actually matters, don't put significant work into security that's meaningless. And if it's a matter of security that can be handled on a server (Like with a leader-board), work on that. It's better to keep security essential things away from the client when possible; well, unless you're writing a node-based security system, but that's another discussion.


Xyle(Posted 2015) [#7]
Thanks for the information,
A very well worded write up and a point well made.

In my situation here though, I am just looking for a good way to keep people from cheating on the score board. I understand that I wouldn't be able to completely stop from doing it, but making it a bit more difficult than someone taking over the scoreboard with a few clicks seems like a reasonable thing to protect. If the goal of your game is a high score board, the minute someone injects their name with 9billion scores, no one would play it anymore.

Of course I am not any kind of hacker, in the classic sense, but I would like to protect the scores for users who enjoy playing games just to compete for the high scores.

I am really interested to hear how some people approached this. One of the methods that I believe would be required is encrypting the data sent to and from the server. I am not sure of the best method for doing this, but so far, using SSL seems to be a good route.

As for obfuscating in game data, the purpose of this wouldn't be to hide code but to keep people from altering the scores artificially. What good would playing any game for hours be if when you submit the score, you see someone named "Poop" has all the high scores and they are unrealistic? No one would ever play the game.

I totally agree with the ability to modify games. That is a beautiful model for any game and one that has led to some of the best games out there. Counterstrike is one of the best examples of this. I can only dream of creating something as awesome as that someday!

As of now, each of the games I wrote have been stepping stones for learning certain things and trying out different languages. Some day, I hope to create a tutorial section on my site which will give out all the code of my games. It may be a bit embarrassing and people will definitely laugh at how I coded certain things, but in the end I would learn a lot from that experience too.

I really appreciate the information and the time you took writing that! Thank you!