Making a hack proof game in Javascript [closed]

Answer 1

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 2

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 3

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 4

they could write a function that autoaims at the nearest enemy sprite for example.

You can do this even for games were most processing happens server-side! You just need to analyse the display quickly enough.

You can even re-implement parts of the game AI to try to predict how bots will move. Not an easy task if you don't have access to the game's source code but if you log lots of gameplay time, you could apply machine learning techniques.

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

Don't forget that you can change the game itself, not just how it is implemented. For instance, use randomly-generated levels rather than static ones, use human players rather than bots, make your art/sprites more complex, make more use of audio, put a limit on how fast the cursor can be moved, add cooldown times to weapons, add hidden hazards, and so on.

Answer 5

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 6

Some thoughts

Server side:

• Store the games internal state sever side and check the input send by clients on the server.

• Autoaim: Create fake sprites which are invisible to normal players, if they get hit too often you have a bot. (will not always work as the bots may be updated to check for invisibility)

• check client reaction time to changes on the server, check for too many too fast reactions. (has to accept a large number of fast responses before reacting as a human could react fast and the time has to account for the network delay to catch anything). Give the player some sort of captcha, a regular player would never see it.

Client side:

• use obfuscation to make it harder to interface with your code

• check for functions defined in the hacks you know about. Has to be modified/updated often as the creators of such hacks can work around those.

• Game design: making your game less repetitive this makes it harder to write tools/bots for it.

• update the client to change parts of its structure from time to time. While this will not stop bots it will take work to keep them running. Either make it transparent to the user or disguise it with a new feature.

Important: make sure your server interface checks the user input, obfuscation and client side checks wont help against someone writing their own client.