Making a hack proof game in Javascript [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 3 years ago.

Suppose you created an online game in HTML5/JavaScript. All the code would be downloaded into the user's browser, and they would run the game.

How do you stop someone from copying the game onto their computer, and injecting functions and modules to cheat? For example, they could write a function that auto-aims at the nearest enemy sprite for example.

Is there any fundamental way to protect people from doing this sort of thing by designing your game code in a certain way?

Answer 1

travian(http://www.travian.us/) is a good example of a larger scale game that runs in DHTML and it has a ton of issues with client side abuse. Just installing grease monkey in firefox opens a rather large door to all kinds of exploitative behavior. That said, they seem to keep the game somewhat functional since most of the exploits seem to revolve around automation of common in-game tasks and not direct violations of the internal domain logic of the game. Keep in mind that this example is far from being run with only JS and relies largely on server side controls.

Answer 2

In short, no. However, you can obfuscate Javascript to make it much more difficult.

For things like scores, a user could in theory POST any score to your handler script. In this case you could use a session and regularly post back to the server through AJAX.

Answer 3

I like the question, and while there are probably better answers, here are a few off the top of my head that may (or may not) work:

• Obfuscation. Yea, it's not guaranteed and someone can eventually get to it, but it's a pain in the butt to deal with sometimes.
• Generate the JS with a new temporary token each time. You may be able to templatize the .js running the code and insert a server generated token that differs per each instance. The token could be temporary and it could be one way to validate the authenticity of the code
• There's probably some way to determine the proper location of the script being run - but this could probably be faked

In general, its hard, and all of the suggestions above can be worked around. I guess the key is to make it hard for them to cheat, but given that there are cheaters for even secure online mode games, it's going to be hard to prevent JS games from being susceptible to that as well.

Answer 4

I think the way to go would be to write the client in a way such that you dynamically alter the client code and verify the use of thusly created code on the server.

E.g. have a namespace like this

window.mynamespace = {

    foo : function(){
        // some stuff here
    },

    bar : function(){
        // some more stuff here
    } 
}

which contains all your client code and make all your server methods require a token that is the result of a previous dynamic evaluation of the code base. make this harder by redefining methods and changing method names. Here are a few sample challenges (this only makes sense if challenges are created dynamically and not predictable). All contain a task first and then a challenge that will be used to create the authorization token for the next request. (These are response objects from the ajax calls). Basically the task will be eval'd and the result of the eval'd challenge will be the next token.

{
    task: "mynamespace.baz=mynamespace.foo;mynamespace.foo=undefined;",
    challenge: "mynamespace[11].toString().substr(10,22)"
            // get part of a well-known functions source code
}

{
    task: "mynamespace.bar=function(){ /* new code here */ }",
    challenge: "var xy=0;mynamespace.each(function(item){xy+=item.toString().lastIndexOf(';')}); xy"
            // accumulate the last index of a semicolon in all elements
            // of the namespace
}

To beat that and still get valid authorization tokens, the client would have to write an entire javascript emulation layer. Although that can be done, I would try to make the server code change in fundamental ways very often to make this technique almost impossible (so the emulation layer won't know what to emulate).

Answer 5

In theory you are playing a game against hackers. You can't win this game but you make it challenging.

My suggestion would be to use as much server side logic as you can possibly use and use Javascript Obfuscation.

Javascript obfuscation will make it extremely hard to understand the code, but even better it will make it possible for you to release several thousand versions of your code while maintaining the same code base.

I have used JScrambler to do this on one occasion. Instead of having to hack the code of 1 game, hackers will have to hack several thousand versions of the code! :)

Answer 6

You're attempting to do the impossible. The best advice I can give you is that if you are plan on persisting any data like coins/money/gold, levels, whatnot you make sure you never trust the client and make as much logic server sided as a possible.