1

I am wondering how easy it is for a user/browser to manipulate or execute Javascript code manually.

The reason I ask is that I am planning on making a browser-based game. I am using Javascript instead of Java because I want to make it accessible to as many platforms as possible.

Here is a general example of what I mean: the user might go to a game page. Several variables would be stored in JS such as, say, the player's health and strength values. The player might choose to attack a monster and the outcome is determined from several stored variables and a couple which were generated during the battle.

So would a player be able to manipulate the stored variables or call one of my JS functions (such as one which leads to an AJAX call being made)?

If so then how could I guard against it? I could verify each action with the server but that is bandwidth-intensive.

Chro
  • 1,003
  • 2
  • 15
  • 27
  • 2
    It's trivial, and you cannot guard against it. Since it's all running on the user's browser, far far away from your server, you can't do anything to prevent them from meddling with your game's inner state, since it's running on THEIR computer, not yours. – Marc B Apr 05 '12 at 21:07
  • Type this in your address bar (in chrome) `javascript:alert("hi");` – Gazler Apr 05 '12 at 21:09
  • 1
    Please elaborate on "I could verify each action with the server". How would you do that? (Also, Java? When is this, 1998?) – bzlm Apr 05 '12 at 21:18
  • @bzlm: haha "What is this, 1998"? ...I have it on good authority that, apparently, Java isn't quite dead yet. #wishjavawouldjustdietoo – Gerrat Apr 05 '12 at 21:25
  • bzlm, I would have the state of the game on the server. If the player wanted to buy an item then a check would be made to the server to make sure they hadn't changed their gold level before letting them purchase the item. – Chro Apr 05 '12 at 21:30

4 Answers4

3

Hit F12, open the Console, hack away.

Anything in the global scope is vulnerable to modification.

However, by enclosing your game logic in a closure it becomes a LOT harder to access.

So:

(function() {
    // all your game code here
})();

This will prevent access to local variables. Just make sure you declare them all properly with var.

Also, make sure you obfuscate the code to make it harder to modify, and take special care when accepting communications such as highscore submissions. I like to encrypt mine with a made-up-on-the-spot method (such as converting from base 10 to base 42).

As much as possible, send the player's actions to the server and make sure they are valid. If you can, keep a state of the game on the server side - partly to check if the player is playing by the rules, but also as a side-effect you can resume the game if the user reloads the page.

All in all, you can't stop cheaters, but you can make it really hard for them.

Neysor
  • 3,893
  • 11
  • 34
  • 66
Niet the Dark Absol
  • 320,036
  • 81
  • 464
  • 592
  • F12 is IE only :). It's (cmd/ctrl)+(option/alt)+j in chrome, and (cmd/ctrl)+(option/alt)+j in safari and something in Firefox (but something different if you're using Firebug), etc. etc. Also minimizing does little since it can be easily expanded using JSBeautiful. It'll munge the variable names, but it's not going to make it horribly difficult. – tkone Apr 05 '12 at 21:12
  • But that's not to say you're not spot on with your answer :) – tkone Apr 05 '12 at 21:13
  • F12 works in Chrome for me (Windows). Kolink, thanks for your advice! Can you expand on your "made-up-on-the-spot method" idea? – Chro Apr 05 '12 at 21:16
  • Well, basic XOR encryption can work quite well as long as the key is obfuscated well enough. As for base converting, you can convert to any base up to 36 with `score.toString(base)`. Beyond that you have to manually program base conversion. – Niet the Dark Absol Apr 05 '12 at 21:20
0

Have you ever opened your developer console? You have access to all the scripts running in the page. Anything loaded can be manipulated.

You can made it harder by running your code in a specific closure. This S.O. answer about closures might help clarify things: How do JavaScript closures work?

But since it's all client-side nothing is impossible if someone REALLY wants to get in there and change things to benefit themselves since JavaScript allows for runtime introspection.

Community
  • 1
  • 1
tkone
  • 22,092
  • 5
  • 54
  • 78
0

The only way to prevent cheating in this manner is to verify all actions with the server. Even if the players couldn't access all the javascript with the proper tools (which they can), they could just attack the system at the network level.

The only alternative is if javascript somehow acquired a trusted platform module API.

ninjagecko
  • 88,546
  • 24
  • 137
  • 145
0

You might not protect against manipulating the real values, but you may make it a bit more complicated, by verification.

Here's what I mean. Let's say you're protecting the health value, and let's say it's named "helath". You declare another health value, let's say we name it "hcheck", but you do not make it equal the health value. You give it an offset value of -52 or +786 or whatever... You might also store xor-ed value or... be creative. Later, you simply check if the health value corresponds the hcheck value, and if not, you decode the real value back into health.

Of course, you might salt it even more if you want it, with a third value that will be some kind of calculation between the health and hchek values.

Let's be clear. This doesn't guarantee it will be 100% protected, but it will it complicate the thing for novices, and more experienced ones will simply not want to waste their time when they see it's salted even with a third protection value (you may never know how many protection values/layers are there) :)

Oh, and if someone has the time and nerves to follow your lead and fix the values in every single variable, then they deserve to cheat ;)

sashozs
  • 23
  • 2