21
\$\begingroup\$

I have made a Javascript/html game. Now the problem I have is anyone can edit the client code and cheat in game for example there is a man shooting a enemy.

  • Man HP:          100
  • Enemy HP:      50
<div id ="man" hp="100" >
</div>

Now if someone changes the hp attribute to a very high value then he becomes literally immortal making the game easy. Now how can I prevent this type of thing ?

\$\endgroup\$
  • 6
    \$\begingroup\$ Phillips answer is good but I wanted to add that ALL game clients have the same issue you do. You can modify the executable of any game in an attempt to cheat. You might find some good techniques by asking about or looking into how to help thwart cheating in games in general. \$\endgroup\$ – Alan Wolfe Dec 19 '15 at 15:09
  • 1
    \$\begingroup\$ If someone changes their HP to a really high value they become FIGURATIVELY immoral. They can still be nibbled away to death by a slime if they go AFK long enough. \$\endgroup\$ – John Dvorak Dec 20 '15 at 5:40
  • 5
    \$\begingroup\$ Example: Go to orteil.dashnet.org/cookieclicker and open your console. Input: setInterval(function() { $("#bigCookie").click(); }, 10); I was the best cookie clicker of my class. \$\endgroup\$ – AmazingDreams Dec 20 '15 at 13:49
  • \$\begingroup\$ @AmazingDreams You can also do Game.cookies=999999999 :-) \$\endgroup\$ – wb9688 Dec 20 '15 at 17:58
  • \$\begingroup\$ Maybe in the future you could use WebAssembly to compile your code or obfuscate it in other ways \$\endgroup\$ – Zorgatone Dec 21 '15 at 15:00
60
\$\begingroup\$

You can't.

Javascript is executed on the users machine. Whatever is executed on the client side can be manipulated by the client. All mainstream web browsers come with powerful debugging tools out-of-the-box which allow users to influence Javascript code even more than with the console. So the user doesn't even need any special software tools like they would for cheating in games implemented as binary executables.

You could try to minify and obfuscate your code beyond recognition (there are tools for that which you can integrate into your deployment script), but a determined hacker can still find out where you are hiding the important data. So you might slow them down, but you can not stop them.

The only way to prevent cheating in a web-based game is to implement all important game mechanics on a server where it is out of reach for the user.

But keep in mind that when your game has no multiplayer component or global leaderboards, then it is questionable if any work invested in preventing cheating is really providing any benefit. Cheaters can only hurt their own game experience while the honest players who want to play the game as designed won't be affected at all. Allowing a bit of cheating can even enhance the game experience because it allows players to experience the game in a different way. There is a reason many game developers intentionally add cheat codes or developer consoles to their games.

\$\endgroup\$
  • \$\begingroup\$ But it's too much pressure on server isn't it? Real-time it's gonna be hard \$\endgroup\$ – Ohmyholy Dec 19 '15 at 15:00
  • 1
    \$\begingroup\$ @Ohmyholy That really depends on what kind of game you are talking about and how much pressure you consider "too much". I have already seen real-time multiplayer games implemented as html5+server backend. \$\endgroup\$ – Philipp Dec 19 '15 at 15:48
  • 1
    \$\begingroup\$ @Ohmyholy, one option you have is to record a log of events on the client device and upload it to the server before the server will accept a client's new save state / leaderboard entry / etc; if your game's operation is deterministic, you can actually replay the the exact inputs on the server side to validate; that way, a player can't successfully submit a score of X without a log showing how they got that score, but there's no need for the interaction to be in realtime. \$\endgroup\$ – Charles Duffy Dec 19 '15 at 16:10
  • \$\begingroup\$ Consider also that if operation is fully deterministic, you can reproduce any buggy state the application can get into using information (that action log) that you were storing regardless [for submission to the server]. \$\endgroup\$ – Charles Duffy Dec 19 '15 at 16:31
  • 1
    \$\begingroup\$ @AlanWolfe, re: fog-of-war, that can be assisted by retrieving information from the server shortly before the player would be able to be aware of it. Not perfect, but helps. And yes, the replay can be tampered with, but it still would have to be within the rules -- so a player could do the best possible thing, but couldn't do impossible things. \$\endgroup\$ – Charles Duffy Dec 19 '15 at 17:04
16
\$\begingroup\$

Put spoilers for the new star Wars movie and or other movies/books/shows in the code to deter people from looking at the code.

\$\endgroup\$
  • 2
    \$\begingroup\$ Lol, this answer is hilarious. \$\endgroup\$ – S. Tarık Çetin Dec 21 '15 at 2:07
  • 4
    \$\begingroup\$ I love the smell of sweet revenge in the morning. \$\endgroup\$ – meneldal Dec 21 '15 at 2:19
  • \$\begingroup\$ Brilliant, I might actually use this! \$\endgroup\$ – Tobsta Dec 21 '15 at 21:35
  • 4
    \$\begingroup\$ >implying hackers haven't already watched production copies of blockbuster movies. >implying dated topical spoilers are at all a deterrent. \$\endgroup\$ – return true Dec 22 '15 at 0:09
  • 1
    \$\begingroup\$ I see this answer is getting flagged from time to time over the past few years as "not an answer," but I don't think it requires moderator intervention. The post presents an approach to solve the problem. The approach might not be practical or highly effective, but I wouldn't say there's a lack of an answer here. And it seems to be valued by the community for its lateral thinking and entertainment value, judging by the number of upvotes. If you disagree with an answer, please feel free to use the vote buttons & comments to say so, and save flags for cases that require moderators to intervene. \$\endgroup\$ – DMGregory May 24 '18 at 14:54
10
\$\begingroup\$

Well, for me personally it depends fully on what type of javascript game that it is:

In the case of a single player game...

let them cheat! Lets say you rewrite the wheel, and put as many roadblocks in the way of a determined hacker as you want, at the end of the day, the player will only undermine the fun of the game for themselves if they cheat. If anything, the more in the way of trying to 'protect' your game, that much more of a challenge it is to hackers who will find your feeble attempts entertaining. In the end, players that don't want to cheat, wont. I personally would even add a console command or a cheat menu, to make double sure that there is no challenge here for hackers. Think of any single player game with a console (skyrim, fallout 3/4, etc...) --- at a certain point, it really doesn't matter if someone cheats or not. I personally would say the same thing for lan games as well (depending on the game).

Otherwise, when it actually matters...

In games where cheating not only ruins the fun for the player, but for potentially all players (including those that don't want to cheat), then you really have absolutely no choice but to run anything of importance on a server. You most likely will be doing this already for any game that has a great deal of players in it that must all communicate with each other. Connections to the server, and communications to and from the server can/should all be logged and reviewed to make sure no funny business is going on. It is important that you never trust any communication that is directed towards your server. For the same reason as the single player game, you can do nearly nothing in the way of 'preventing cheating' on your players computer and any local security measures are little in the way of challenge; Because of this sent messages that 'look legit' can easily be far from it --- it is your job to check everything and trust nothing. If something does not match up exactly with what you would expect, log it and toss it.

Why does javascript suck?!

Javascript is easy to screw with in a web browser. Firstly, it's all in plain text english, and most browsers these days pride themselves on showing you everything they can about what is on a web page on the nuts and bolts level. This means, with nothing more than a few mouse clicks later, boom, any javascript game can be viewed and easily changed. Whereas Javascript might be the easiest in these regards to 'figure out', there is not a programming language or environment known to man, that someone can't figure out. The problem is always the same: If a CPU is expected to know what to do with something, a human can figure it out too (even though it can be an absolute pain, to the point that most would rather give up than continue trying--- but not all do).

The same holds true for packets. Not only can the codes that run on your computer be completely broken apart and added to, but the communications coming from your computer to a server can be altered, resent, and forged altogether. For instance, if in a game, your computer sends to a game server out there 'hey, I just got 1 point', you can watch that communication and send it again and again... so instead of just having the one point that the game generated, you now have just as many as you want to request- or if you can figure out the communication and edit it yourself, you could easily send over 'hey, I just got 9999 points'.

Things not to do

If you have a multiplayer game, DON'T just obfuscate it and call it a day, that stops absolutely nobody and most likely just as easy as it was for you to obfuscate, hackers have already written a tool to reverse it (or if not already most likely momentarily)... Not only can whatever mess you made can be cleaned up, but most of the time whatever you had can be entirely recreated like nothing ever happened (MCP comes to mind). All this could ever serve to do is slow someone down, but not for long. Again, you could obfuscate your code for a single player game, but what would even be the point of that other than to give hackers reason to release all manner of trainers to try and enable cheating --- you should just beat them to the punch and be done with it, rather than invite hackers to think too much about your game in particular.

tl;dr

Because of limitations of programs and packets, for single player games there is absolutely nothing you can do to stop someone from cheating, so don't bother and rather embrace that fact. For multiplayer games, the only thing you can do is to treat all communications from a player as hostile until you can definitively prove otherwise.

\$\endgroup\$
3
\$\begingroup\$

One of the things you can do is work with it.

Really, this depends on what you want to do, but Orteil made Cookie Clicker. The game is clear javascript/html.

He took into account that the game was really open source and he added a "cheat" mode. The cheat mode allows you to cheat, but it also "records" it in your stats.

This is not available to any kind of game, but you could try and sneak it into your game and make it a feature. It's harder to do with multiplayer games, but if you make some features server computed only, and let the users "cheat" for trivial thing, this could make an interesting feature :)

\$\endgroup\$
-2
\$\begingroup\$

Usually i would say if its singleplayer,let them cheat!

But you can do more than that.

For example: You could create a boolean that turns to true when your health is being edited (like for example being attacked) and false once its done,and additionally create a loop that checks the previous value of your health every loop and if its different and the boolean isnt set to true,youve got a cheater.

Keep in mind,this would be bad practice,and could be reverse engineered in seconds making it useless. But get creative!

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.