Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Preventing cheating in network games written in Java  (Read 12838 times)
0 Members and 1 Guest are viewing this topic.
Offline M2009

Junior Devvie





« Posted 2009-06-14 22:00:55 »

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.

2) 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.

3) 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.

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

5) Use some lightweight polymorphic encoding on your game connections.

6) 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.

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

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

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

10) 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.

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?

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 845
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2009-06-14 22:17:33 »

"keep all logic on the server"

"you can't prevent all cheating" and think they're being smart,


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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline M2009

Junior Devvie





« Reply #2 - Posted 2009-06-15 01:45:16 »

"keep all logic on the server"
"you can't prevent all cheating" and think they're being smart,

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #3 - Posted 2009-06-15 06:18:09 »

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

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #4 - Posted 2009-06-15 06:33:59 »

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.

Offline pjt33
« Reply #5 - Posted 2009-06-15 08:51:11 »

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?
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.
Offline cylab

JGO Ninja


Medals: 55



« Reply #6 - Posted 2009-06-15 09:27:13 »

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.

Riven is so much of an expert of so many things here, you should be glad he answers you Shocked 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!)

Mathias - I Know What [you] Did Last Summer!
Offline princec

« JGO Spiffy Duke »


Medals: 436
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2009-06-15 10:28:32 »

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 Smiley

Offline zammbi

JGO Coder


Medals: 4



« Reply #8 - Posted 2009-06-15 11:17:15 »

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

I have seen business starting to that...

Current project - Rename and Sort
Offline DzzD
« Reply #9 - Posted 2009-06-15 11:31:03 »

What about the client just sends the controls and server just sending pixel information, that solves everything  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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 845
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #10 - Posted 2009-06-15 12:37:33 »

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.

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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
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;
   }
}

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Tobiking

Senior Newbie





« Reply #11 - Posted 2009-06-15 13:04:19 »

http://en.wikipedia.org/wiki/GameGuard is similar to SecuRom and they continue to use it. The "Known blocked applications" make me laugh.
Offline DzzD
« Reply #12 - Posted 2009-06-15 13:29:17 »

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.

Offline zammbi

JGO Coder


Medals: 4



« Reply #13 - Posted 2009-06-15 13:47:20 »

Quote
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).

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.

Current project - Rename and Sort
Offline M2009

Junior Devvie





« Reply #14 - Posted 2009-06-15 17:39:29 »

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

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

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".

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.

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.

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.

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.

Riven is so much of an expert of so many things here, you should be glad he answers you Shocked 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!)

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.

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 Smiley

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).

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

I have seen business starting to that...

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. Smiley

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.

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. Tongue Guess we can always add encryption to the traffic if we want to make it even harder.

Offline M2009

Junior Devvie





« Reply #15 - Posted 2009-06-15 17:39:56 »

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

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

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.

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

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. Cheesy 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.

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.

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. Smiley Btw, if you had to name three (or more) of your other biggest problem, what would they be? It's interesting.

Offline Mr. Gol

Senior Devvie


Medals: 1



« Reply #16 - Posted 2009-06-15 18:05:04 »

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%.
Offline teletubo
« League of Dukes »

JGO Ninja


Medals: 48
Projects: 4
Exp: 8 years



« Reply #17 - Posted 2009-06-15 18:23:41 »

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 )

Offline ewjordan

Junior Devvie





« Reply #18 - Posted 2009-06-15 18:32:20 »

Though for your example, no idea why they would do that for a card game, they should be easy prevent cheating in them.
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. Smiley

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.
Offline DzzD
« Reply #19 - Posted 2009-06-15 18:35:41 »

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 )


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....

Offline teletubo
« League of Dukes »

JGO Ninja


Medals: 48
Projects: 4
Exp: 8 years



« Reply #20 - Posted 2009-06-15 18:43:20 »

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....

I don't disagree with you, but since most of the people here are just hobbists (hobbyists ? hobbysts ? (not hobbits, I'm sure)) and are looking forward to learning new stuff, I think we should just welcome interest and information in all areas, not the ones that are interesting for non-commercial game developers . I don't expect to earn money with my game, but I do expect to learn a lot Wink

anyway,  it's also interesting to know the efforts to do such stuff, but let's just not let it obfuscate the main question of the topic

cheers

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 845
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #21 - Posted 2009-06-15 19:24:32 »

Listen, I'm sorry for hurting your feelings.
Not so easy to hurt my feelings.


Anyway, ontopic: I read an article on Gamasutra.com about anti-cracking - I know that's totally different than cheating, but the strategy they used was amazing.

Most hackers/cheaters will hack stuff, and if it works, they'll release it. Nothing easier than programming a game to crash on a failed SHA1 hash of some resource - or even the binaries. Well. That's where you get to nerf your game instead. In the article, they had this arcade game that required collecting gems in a 3D world. You'd spend hours exploring, and to finish the level, you needed 'super gems' hidden around the level.

When certain hashes failed, one or two 'super gems' disappeared from the game.

The hackers had no way to figure this out in a timely manner. They thought they got the game running, and released the crack on internet. Needless to say quite some 'casual leechers' got fed up with the impossible gameplay, visited some forums, and found out what was happening. Seriously: they bought the game instead.


So what can we learn? It is actually quite easy to figure out whether a wallhack is active. I mean, you have access to the framebuffer. You can use OpenGL Occlusion Queries if you're really lazy. And if you determine somebody is cheating, don't crash the game, don't show them a warning. No! Instead nerf their game. Make them randomly die, once every 10 minutes. Occasionally do not render an enemy. Give them half the healthpoints of a healthpack, slightly darken their screen, reduce the framerate at totally random moments, preferably when it hurts them most.

The possibilities are endless. Besides that, it is fun to code.

Just be very subtile, so they won't track it down to they own cheating.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #22 - Posted 2009-06-15 19:58:08 »

Anyway, ontopic: I read an article on Gamasutra.com about anti-cracking - I know that's totally different than cheating, but the strategy they used was amazing.
Was it this one? http://www.gamasutra.com/features/20011017/dodd_01.htm

It's a facinating article/approach, but I can't help but think they gloss over the disadvantages a bit - namely the time to implement, the (tedious) time to test and the inevitable pain and confusion caused when the system goes wrong. As a solo/bedroom programmer I don't think the loss in productivity is worth it, but YMMV.

Of course if you're writing an online pc game rather than a single player console game you've got the advantage of being able to patch easily and often. You can take advantage of that by doing "reactive" cheat prevention by releasing new versions which counter cheats as they appear - believe me it's much, much easier to write a simple counter to a well-known cheat than it is to try and build in all sorts of elaborate tricks that cover every eventuality. And because you're countering a specific hack you can get creative - like draing false players behind walls to confuse players using wall hacks.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline cylab

JGO Ninja


Medals: 55



« Reply #23 - Posted 2009-06-15 20:31:57 »

When certain hashes failed, one or two 'super gems' disappeared from the game.

Imho this is the worst idea I can think of. Chances are people will just say "This game is buggy as hell, so lucky I didn't buy that crap". Frankly I am one of the guys that occasonally gets his hands on a - erm - decentralized backup copy - erm - of a game and I usually buy it if I like it, otherwise I don't play it at all. So you would loose me as a customer. In fact most PC players I know do the same...

Mathias - I Know What [you] Did Last Summer!
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 845
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #24 - Posted 2009-06-15 20:35:11 »

That's why the idea is from countering cracking, and in this case applied to cheaters.

You only get nerfed if your cheat, that's not an honest player! You probably don't even want him to buy your game.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline princec

« JGO Spiffy Duke »


Medals: 436
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2009-06-15 20:37:22 »

I wouldn't be so dismissive of my suggestions, either. I'm being deadly serious. Consider gameplay that is not cheatable by design, and technology that is likewise not cheatable. Failing that, truly attempt to grasp what I've said about heuristics and voting systems. It is a serious solution.

Cas Smiley

Offline cylab

JGO Ninja


Medals: 55



« Reply #26 - Posted 2009-06-15 20:54:47 »

That's why the idea is from countering cracking, and in this case applied to cheaters.

You only get nerfed if your cheat, that's not an honest player! You probably don't even want him to buy your game.

Sorry - I wasn't clear. I was just refering to cracking. If this can be pulled of against cheaters it might be a good idea, but I am afraid this could really be difficult and cumbersome to implement.

Mathias - I Know What [you] Did Last Summer!
Offline PeterB

Junior Devvie





« Reply #27 - Posted 2009-06-15 23:33:10 »


I'd say apply the rule of diminishing returns: if there's some easy protection you can put in that costs  you little time and effort, while demotivating some script-kiddies, then do it.

But don't sacrifice your game/marriage/life coding away just to stop the 1% of cheaters.

That (like others have said here) are what patches and updates are for, if your game takes off.


Vault101 / Mace The Game
There are 10 kinds of people in the world. Those who understand binary and those who don't.
Offline ewjordan

Junior Devvie





« Reply #28 - Posted 2009-06-17 06:45:47 »

Well, I never expected this to be even possible, but looks like there are people out there working on the video streaming approach to games: http://www.techcrunch.com/2009/06/16/videos-otoy-in-action-you-have-to-see-this/

They claim it works quite well, I imagine the server load is incredible, though...
Offline DzzD
« Reply #29 - Posted 2009-06-17 08:44:48 »

Well, I never expected this to be even possible, but looks like there are people out there working on the video streaming approach to games: http://www.techcrunch.com/2009/06/16/videos-otoy-in-action-you-have-to-see-this/

They claim it works quite well, I imagine the server load is incredible, though...

streaming video work with anything including game as the first video... but they seems to forget the most important.... that will maybe never be removed wich is network latency and then game will be unplayable (especially when you look around)

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (5 views)
2014-12-23 03:34:11

rwatson462 (38 views)
2014-12-15 09:26:44

Mr.CodeIt (31 views)
2014-12-14 19:50:38

BurntPizza (62 views)
2014-12-09 22:41:13

BurntPizza (99 views)
2014-12-08 04:46:31

JscottyBieshaar (60 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!