Preventing cheating in network games written in Java

In this thread I thought we could share some ways of preventing cheating in online java games (for example of many human players are trying to kill each others, how can you prevent one of them from seeing through walls/invisible objects or having zero reload time etc).

I’m new at this so I don’t really have any tips to give, other than the “keep all logic on the server” (like the server receives a click event from a player and then generates a fire event which is sent to all connected clients). This puts a lot of work on the server’s shoulders however and will still not protect from cheats that changes visibility of things (if a player is supposed to have 10% visibility the cheat could make it display at 100% regardless of what the server is saying since it’s client-wise).

I saw a good anti-cheat checklist which I will now quote:

[quote]1) Open all other processes, and hook their WriteProcessMemory functions so that they can’t write to the memory in your game’s process. Done right this one step will block 90% of all cheats and cheat engines.

  1. Do the same thing, hooking the various mouse and keyboard emulation functions. This will prevent a lot of aimbots and other types of automation bots.

  2. Hook into the VirtualProtectEx/VirtualAllocEx/etc functions in your game’s own process and monitor which modules are changing protection levels or allocating new memory chunks. You have to be crafty with this in order to prevent it from being too CPU intensive when your game does a lot of allocations, but it can be done.

  3. Hook into the LoadLibrary functions and monitor any DLLs that are being loaded dynamically, to prevent DLL injection.

  4. Use some lightweight polymorphic encoding on your game connections.

  5. Use some anti-debugging techniques to prevent debuggers from attaching to your processes. Google anti-debugging and you should be able to find lots of stuff.

  6. Use a custom proprietary PE packer to prevent useful disassembly of your game.

  7. Hook into your OpenGL or Direct3D functions and methods that deal with transparency and alpha blending.

  8. If using shaders, checksum your shaders and the shader constant values.

  9. Use additional occlusion culling techniques on player characters to prevent them from being rendered at all when the line of sight to them is blocked by other geometry. It may or may not help with your performance also, but it will prevent many wallhacks.
    [/quote]
    Source: http://stackoverflow.com/questions/960499/how-to-prevent-cheating-in-our-multiplayer-games

This is a good list IF you are skilled enough to implement it by yourself, which I am not. Also, this list is more for languages like C and not Java. Maybe one can use a Java Native Interface to implement the anti-cheat part of the game, however I’m again not good enough of a programmer to be able to do that.

Java Native Interface is from what I understand making a EXE in for example C and then have C call Java mehods. More information about it can be found here for those interested: http://en.wikipedia.org/wiki/Java_Native_Interface (A side track of this thread I suppose, but maybe one of you can use it to prevent cheating in Java games?)

So, anybody with experience willing to share their knowledge? I bet this is something a lot of people on this section of the forum would like to know better. I know some may think they should post “you can’t prevent all cheating” and think they’re being smart, but if we could at least make it impossible to use the most common cheat engines we would get rid of a lot script kiddies (I’d guess 99.9% of all cheaters are just using a general-purpose tool someone else made).

For good measure I will make what I wrote above into a question:

How do I prevent cheating in multiplayer Java games?

[quote=“M2009,post:1,topic:33704”]

[quote=“M2009,post:1,topic:33704”]
There you go.

Making a game with players is hard enough. Don’t waste time on cheaters, until it happens! It’s just a big time waster, like, you’re wasting time, which you could spend on creating a game, and not waste on cheaters, don’t waste your precious time on cheaters, it’s such a waste - I think I made my point.

and cheaters have more time to figure out things anyway.

If you want to ‘secure’ some global variables, which are very easy to lookup (and thus manipulate), build some SecureInteger class, and fiddle with the bits, a bit. This is what was done in Age of Empires 2.

You think you’re so smart…

Seriously though, I want to know if there is some way to prevent cheating in games built in Java. Obviously you’re not an expert but there may be people that actually knows about this stuff, since it is very important.

I know there are MMO games in Java (at least one, don’t remember the name but it is many years old and still running), how is cheating prevented there? What prevents the user from, say, removing all ground textures and thus being able to see through mountains? I’d like to believe no company will make a serious game in Java unless there is a way to prevent at least common ways of cheating, especially if there is money involved somehow. And if many people cheats in a game a lot of real players might quit out of frustration, if the game is one of the pay-to-play brands that means lost revenue for the company and/or less motivation to develop the game further due to the drop in players.

This is not about me wasting time making the game cheatproof, it’s about not wasting time making a game in Java that later will be completely raped by cheaters so no-one will play it.

Edit: Inserted your two quotes of me inside my quote of you.

On the visibility side, if a client shouldn’t be able to see something, then don’t tell them about it. Looking through a wall won’t help them if what is on the other side they know nothing about.

This is a topic that has come up here before, and the general conclusion (from memory) has been that you can’t reliably prevent it. All you can do is protect information they shouldn’t have, and try to detect anomalous behaviour. ie, aim bots will probably be rotating the player faster than a player should. so if your server spots a player that moves too quick, it’s an indication that something might be up. You have to be careful though, they may just be good. You will need to base your cheat detection rules on your own game rules.

Endolf

What Riven is telling you is the truth. You cannot avoid cheating. End of Discussion.

Therefore focus on giving the players that don’t cheat a good time - and finish the game. Make it worthwhile not to cheat. Then implement mechanisms that make it harder to cheat and implement mechanisms for detecting cheating.

RuneScape? I don’t think removing textures etc would prevent cheating - the main issues with cheating are bots and real-world trading (gold farming). However, they do have frequent client updates which reobfuscate the code and the client-server protocol, so you can’t use old clients and have to re-deobfuscate each time. It’s not completely effective, but it raises the bar in comparison with one-off obfuscation.

Riven is so much of an expert of so many things here, you should be glad he answers you :o Your reaction is inapropriate!

Furthermore he is right: you can’t prevent cheating!

First make a game that attracts players. If someone really is cheating, you have to find out what hole or game mechanics he is abusing and try to make it harder to do so. You can’t secure your code before this is happening. It’s more like in virus/malware protection - you can only fight it once you know it. This is a day to day job and will never end (if you manage to get a game out, that people consider worth of cheating - which might be the hardest part overall!)

Design the game both technically and mechanistically so that there is no such thing as “cheating” or “cheating” confers almost no benefits. Then use heuristics to detect any edge cases and flag them.

Technically, that’s having all logic serverside, and treating the client like an untrustworthy mushroom, kept in the dark and fed on shit. Or specifically, only information that the client should know. The client should be able to make no decisions that affect the game.

Mechanistically, make the client capable of doing anything that a cheater might want to do anyway with the limited information available. A trickier and more esoteric side to it.

Heuristically, if someone’s performance falls outside 99% of the expected range of performance persistently then have the server flag them as a possible cheat and call on the other players to vote them off. This works on various levels - firstly it’s not automatic: if none of the other players cares, neither should you. Secondly if they actually aren’t cheating but are simply so bloody good they’re pwning all the other players, they can boot the smartass out anyway and enjoy themselves more. Thirdly they might all just be a bunch of friends all running the same cheats for kicks on that server, so let them have their fun, they won’t vote each other out. (And the heuristic will change over time of course).

You’ve probably figured now that FPSes are therefore almost entirely impossible to secure because of the technical requirements (ie. you need to send data about entities an client can’t see a few millis before they pop into view to prevent, well, popping, which means a transparent wall hack will confer cheaters a tiny, tiny advantage), and the only mechanical solution is to actually not have any walls which would be a bit pants, so you’re left with heuristics.

Cas :slight_smile:

What about the client just sends the controls and server just sending pixel information, that solves everything :stuck_out_tongue:

I have seen business starting to that…

you cannot alway do that, the base problem is network latency (but yes this is done in turn based game as network cards game and can prevent 100% cheating).

IMO, as already mentionned the only good way to avoid cheating is to perform logic server side.

so, I would recommend to perform game logic/rules server side aswell as a subset of them clientside (to avoid problem on network latency) and send “correction packet” to client when player movment/action is not acceptable. this is as far as I know what is done in network game.

All of that is not related to Java itself but rather to the fact that the client is God for all things that are client side, you wont get much more problem to secure a java softwer than you will get to secure a C++ one.

EDIT :
about your checklist… it will increase hugelly your game cost and will bring new bugs, also one usefull attack is to use a proxy and monitor packets and then to make the difference between packet sent to locate where “active information” is transmitted, there is nothing against net sniffing in your list… so you are using a metal door with paper wall.

Thanks for your honest response. I deeply appreciate it. You are so right: I’m not an expert, and I think I am smart. Way to make friends, too.

I wonder what you thought of encrypting variables, as this raises the bar quite a bit against the ‘find this value in RAM and modify it’ attack - the fact that AoE AoK 2 used it, which can’t be ignored, might change your mind, and accept this little bit of information from a clueless person like me. It’s way better than making your app behave like a rootkit, poking in the sys internals to somehow make it secure. We all witnessed how SecuROM was loved by the community, and how effective it was - then everybody was scratching their heads when EA decided to dump it.

Clientside security: less is more

Just in case you haven’t changed your mind: I added some sample code, so you can mess around with it:


import java.util.Arrays;

public class EncryptedInt
{
   private final Arcfour encoder;
   private Arcfour       decoder;
   private byte[]        data;

   public EncryptedInt()
   {
      this(0);
   }

   public EncryptedInt(int val)
   {
      this.encoder = new Arcfour();
      this.data = new byte[2 * 4];
      this.set(val);
   }

   //

   public final void set(int val)
   {
      this.decoder = this.encoder.copy();
      data[0] = (byte) (val >> 24);
      data[1] = (byte) (val >> 16);
      data[2] = (byte) (val >> 8);
      data[3] = (byte) (val >> 0);
      this.encoder.crypt(data, 0, 4);
   }

   public final int get()
   {
      System.arraycopy(data, 0, data, 4, 4);
      this.decoder.copy().crypt(data, 4, 4);
      int val = 0;
      val |= (data[4] & 0xFF) << 24;
      val |= (data[5] & 0xFF) << 16;
      val |= (data[6] & 0xFF) << 8;
      val |= (data[7] & 0xFF) << 0;
      Arrays.fill(data, 4, 8, (byte) 0);
      return val;
   }

   public final void renew()
   {
      this.set(this.get());
   }
}

RC4 implementation:


import java.util.Random;

public class Arcfour
{
   private final byte[] seq;

   public Arcfour()
   {
      this(256);
   }

   public Arcfour(int bytes)
   {
      this(Arcfour.createRandomKey(bytes));
   }

   public Arcfour(byte[] key)
   {
      this.seq = new byte[256];

      // initiate
      for (int i = 0; i < seq.length; i++)
         seq[i] = (byte) i;

      if (key != null && key.length != 0)
         this.shuffle(key);
   }

   public final void crypt(byte[] buf, int off, int len)
   {
      int end = off + len;
      for (int i = off; i < end; i++)
         buf[i] = (byte) (buf[i] ^ this.next());
   }

   public Arcfour copy()
   {
      Arcfour copy = new Arcfour(null);
      copy.i = this.i;
      copy.j = this.j;
      for (int i = 0; i < 256; i++)
         copy.seq[i] = this.seq[i];
      return copy;
   }

   private void shuffle(byte[] key)
   {
      int j = 0;
      for (int i = 0; i < 256; i++)
      {
         j = (j + seq[i] + (key[i % key.length] & 0xFF)) & 0xFF;

         seq[i] = (byte) (seq[i] ^ seq[j]);
         seq[j] = (byte) (seq[i] ^ seq[j]);
         seq[i] = (byte) (seq[i] ^ seq[j]);
      }
   }

   private int i, j;

   private final byte next()
   {
      i = (i + 1) & 0xFF;
      j = (j + seq[i]) & 0xFF;

      seq[i] = (byte) (seq[i] ^ seq[j]);
      seq[j] = (byte) (seq[i] ^ seq[j]);
      seq[i] = (byte) (seq[i] ^ seq[j]);

      return seq[(seq[i] + seq[j]) & 0xFF];
   }

   private static final byte[] createRandomKey(int bytes)
   {
      Random r = new Random();

      for (int i = 0; i < 64; i++)
         for (int k = 0; k < r.nextInt(64); k++)
            r.nextInt();

      byte[] key = new byte[bytes];
      r.nextBytes(key);

      return key;
   }
}

http://en.wikipedia.org/wiki/GameGuard is similar to SecuRom and they continue to use it. The “Known blocked applications” make me laugh.

about blocked application this really can become a big issue that game editor should take care of :
for example BF2 does not allow CloneCD to run (to avoid using a dvd images) while playing ( you even have to uninstall it !! ) but it allow Alchool !!, so at the end it block some nice software but does not avoid to play with a non-official DVD… wich is stupid… and also it is not really fair for those others software editor.

I know that, my suggestion was more of a joke. BUT I have seen full 3d games work fine. Some cloud based server gaming company.
Though for your example, no idea why they would do that for a card game, they should be easy prevent cheating in them.

In the MMORPG I’m in charge of we do have some cheating problems, but only minor things like bug abusing. Everything is controlled by the server, so we don’t have any real problems.
Afk macroing would be our biggest problem if I had to name one, which we hope to solve with random events.

Thank you very much for all your replies! …Nuclear launch detected:

[quote=“endolf,post:4,topic:33704”]
I’ve thought about that, but it doesn’t work for things that should be barely visible (like if someone is 50% transparent). Also it will only work for servers that constantly pushes the location of stuff to everybody, not if the server want to save bandwidth by only telling the clients stuff like “spawn a bullet at X/Y with this direction and this speed”.

[quote=“Matzon,post:5,topic:33704”]
Well, I said that myself so I know it’s the truth. But there are still means of preventing cheating, not all cheating, but a lot - so there’s always room for discussion. And making cheating harder is always a plus. And yes, even if you focus on making the game fun first and worry about the cheating later, it’s always a good idea to know that you CAN prevent cheating later. Knowing about how cheating can be prevented later will make it possible to avoid programming in a way that will force you to rewrite code later.

[quote=“pjt33,post:6,topic:33704”]
Ah, here we go - that’s one way to prevent cheating. It’ll increase the workload alot, but it will render all not constantly updated cheatengines useless after a period of time. Good idea.

I know I sounded a bit rude and that was the point since I warned people from just saying “you can’t do it”. No disrespect, I just wanted to discourage more posters from just saying “you can’t” (it’s obvious I failed to do so). Concerning your last paragraph, yes I know this but you’re missing the point - I want to know if there are ways of preventing cheating in Java just like there are many ways to do so in C.

[quote=“princec,post:8,topic:33704”]
Games shouldn’t be designed with “is this exploitable by cheaters”, just imagine how much good stuff would have to be cut away. Some games can be designed so that cheating would give no benifit, but others just can’t. The vote idea is one way to prevent cheating, however there should be better options since what if 5 cheater friends joins a server with 4 non-cheaters? The cheaters won’t vote each other off. And if the server suggests that you are cheating when you are just being skilled you might get voted off unfairly, which will cause frustration in someone that otherwise loves the game and might be a strong supporter that will try to make others start playing the game (I’ve been voted off just because I’m deemed too good several times in one game, it’s not that fun but there’s not much to do about it unless kick vote should be disabled).

[quote=“zammbi,post:9,topic:33704”]
Sounds like that would demand a lot of processing power from the server and it will increase the bandwidth requirements through the roof. But it’s a sure way to prevent cheating. :slight_smile:

Interesting addition to the “keep logic on the server” argument, it would keep the bandwidth down but require a bit more calculation on the server to see if the players are kinda in the right place. Also the players need to send his position now and then to the server so the server has something to compare against, unless of course the server just sends a “sync” package now and then which probably would be best. This is not something that can be done when precise things are required though (such as fiering a bullet through a small hole in a wall). Concerning the checklist, let’s pretend that I am a big company and want to do UT2010 in Java, adding extra cost for anti-cheating system won’t be a problem. I just want it to be doable. And about the net sniffing, sure it can be done but it isn’t very realistic since you need to catch the correct packages sent to other players. As we know not all cheating can be prevented, but we want to make it as hard to do as possible, and doing what you say is already pretty hard as it is. :stuck_out_tongue: Guess we can always add encryption to the traffic if we want to make it even harder.

Continued post (“The message exceeds the maximum allowed length (10000 characters).”):

Listen, I’m sorry for hurting your feelings. I was just disappointed that the first reply I got in my thread was something that I had asked not to recieve, no disrespect meant. About your encryption idea it slipped my mind, it was a great idea. It will surely make it harder to use cheat tools, although it will also surely require more work from the programmer and it’ll slow down the application some (I guess). Thanks for the code, that’s something I’d like to see more of in this thread.

[quote=“Tobiking,post:12,topic:33704”]
Ah, external anti-cheat software. That’s one way of preventing cheating, although it feels a bit bad to rely on other people’s work (at least for me since you lose control), and it might require the user to run two applications instead of just one. GameGuard is a typical Asian MMORPG anti-cheat in my book. :smiley: There is also BattlEye (http://www.battleye.com/) which is the same kind of application, I don’t know if it’s better or not but it is free (I’m assuming GameGuard costs money?). I have thought a lot whether or not I should go with BattlEye, then I started this thread in high hopes of someone to tell me how anti-cheating can be done in Java.

Joke or not, it was still a good idea. Not scalable perhaps but if someone wants to do a very small game, like 50x50 pixels, they can now get a solid anti-cheat tip from this thread. :slight_smile: Btw, if you had to name three (or more) of your other biggest problem, what would they be? It’s interesting.

Your knowledge of anti-cheating measures is impressive, but like a few others in this thread I’m thinking you’re focusing on solutions looking for a problem. The only reasonable ground, in my opinion, for focusing on anti-cheat measures is because you have a number of cheaters playing your game and it gets too much work to get rid of them manually. It’s the same with building large websites and worrying how your architecture can handle one million visitors - try to get 10 first.

Anecdote for ‘evidence’ of my claims: I’ve created a simple racing game in Java which has been played by about 2200 people. Because I was following a university course on game development at the time, and I needed to post in forums to learn some things, quite a number of those (I guess 30% or more) are tech-savvy. My high scores system is ridiculously simple, yet I haven’t had a single cheater. So I have to agree with the rest, every minute you’re spending on security measures you’re not spending on making the game more fun for the other 99.99%.

I think you guys should just quit saying “you should not worry about cheating”, and simply answer his question if you have something to add up .

This seems like those threads “How can I do this stuff in JME ?” and a guy answers “You should stop using JME and go for LWJGL !” .

His question was not whether he should worry about cheating or not.

Anyway, I am following this thread very thrilled since I am planning to implement some kind of encryption/security to my game . (and I would hate to see this thread bloated with “you should not !” stuff )

On real money poker sites, the issue is not so much cheating (as you’d imagine, there’s no information presented to the client that he doesn’t absolutely need access to, so only people at the company could cheat - which has happened before, of course) as it is botting. And the thing poker bots need more than anything else is information about the game, so I could see why you would not want to have an array of integers tracking card types sitting around in memory for any bot to easily take a peek at. At least if you make getting the current game state a bit more difficult you reduce the potential list of bot-makers to “people that have the energy to write a screen scraper,” which probably narrows the field to about 5% of its original size immediately. Add in a few tricks like slightly altering the rotations/sizes/graphics of the cards, etc., and it cuts that down even more (most poker sites don’t bother, FWIW, as they have other heuristics anyways that are very good at catching bots, though for obvious reasons they aren’t very forthcoming with the specifics).

Re: whether it’s worth the effort, one thing I’d suggest is that if you have a high score system which passes scores through some URL, it’s usually worth the effort to at least add a little security-through-obscurity there, because you will get a few people figuring out what the score submission URL is. If you “encrypt” the scores before you send them through and validate them with some sort of checksum and then ban IPs that send invalid checksums that will take care of almost all cheating there, even though anyone here (given the desire) could figure out how to get around that. Add a sanity check (it should take at least T seconds to get P points, where P is a decent amount above what you’d expect the best player to possibly get) and you’ll stop almost all of it. Storing game replays and saving them to the server can take care of pretty much all of the rest if you’ve got the energy to implement it, and it also lets you play things back to the user - this is the approach that games like XMoto take, and the best you could do to “cheat” there is to script the run, which is sort of a great enough achievement in itself that the person probably deserves the score. :slight_smile:

Keep in mind that securing an FPS is a lot harder than an MMO, because in an MMO things go slow enough that you can afford to have literally everything except graphics done on the server (ever played WoW and had your connection crap out? All you can do is move around, pretty much no other actions work…) and visibility is almost never an advantage, whereas in an FPS being able to see through that corridor wall can be a game changer. There’s not going to be any easy way to prevent someone from messing with the graphical output, hence all the manual Windows hooking and process spying that happens in those solutions; I don’t think there’s any way to do this from within Java, you really have to make it platform specific.

I understand your point and usually dislike such answer “why do you want to ?”, but this is an advice related to the question, this is not totally out of the thread topic, security have a (huge/exponential) cost in any kind of software/system and this is a common answer to say “dont waste too much time on it”. the problem is that : if you make a popular software and if only one people succed in hacking it, all the world will succed a cupple of hours after by downloading/reading its hack. but yes… you are right… lets go back to the question…