Fairness Check

[Monolith]

There seem to be an increasing number of utilities that allow users peek further into and tweak with the game. This has caused me to think how can we keep things fair between players, for those who wish to keep things fair. Surely new utilities enhance innovation among the community, and can bring out great new ideas, but there are still cases where people would probably like to keep things as reasonably fair as possible. Think of JDC, duels in general, tournaments, or players who just want a fair game. Imagine a utility (if it doesn't exist already) that allows a player to know exactly when and where a carrot or powerup respawns, or a utility that shows the positions of all other players in the level. How could other players or a server detect the use of utilities such as these? Or how could servers choose to limit the abilities of these utilities among players?

[Birdie]

I don't really think this is possible to make sure no one has these ability's, and even if you found a way someone could just make a new program for the same function and it would work.

[EvilMike]

There's essencially no way to prevent cheating like that. I am a strong supporter of people continuing to make increasingly useful programs, and if cheats are a side effect of that, so be it. There are already enough cheats which cannot be easily detected (such as hacking the amount of coins you have, or the amount of ammo you have). It *might* be possible for servers to prevent that, though I HIGHLY doubt it.

As a JDC admin, I pay somewhat close attention to cheats like this, and know how to detect them by watching for certain behaviour. I believe in most cases it still slips by (it's not easy to spot these things), but the problem has never been THAT bad. I find general dishonesty (uploading fake duels, etc) is a much worse problem than in-game cheating is, and will ever be.

Don't worry about the potential for your work being twisted into something unscrupulous. Don't let the fear of that happening keep research and findings into the workings of jj2 a secret. Remember that in the long run, more good than harm will come out of this. Besides, by and large, all of the available cheat programs are already out there, and easy to find. Things can't get much "worse", but they can get better, with useful utilities like what you and neobeo are making.

Still, I can offer some simple pointers on how to detect two of the less obvious forms of cheating.

<b>Ammo hacking</b>: Look for things like people having a seemingly limitless supply of seekers, espically in levels or areas where they are not particularly abundant. People using powerups that aren't in the level is a dead giveaway, though most people aren't that stupid. Many are stupid enough, however, to spawn with full ammo. If you see someone firing a barrage of seekers the second after they spawn, you know something's up.

<b>Coin hacking</b>: This is a huge problem for gametypes which require coins as part of the objective. Really all you can look for is certain players having an unseemingly large amount of skill and quickness, scoring more points than anyone else, and so on, when they aren't nearly that good at conventional gametypes. It's difficult to prove this though, which means you can easily turn this into a witch hunt.

Other forms of cheating are typically very obvious.

I'd love to have an easy way to detect cheaters, but it's very hard to ever verify 100% someone is cheating in-game. Most JDC bans are handed out for fake duel submissions and the like, for that reason (since in comparison, that's very easy to detect). Usually I just pay close attention, listen to player reports, and keep an eye on certain people who seem less trustworthy and fit the profile for someone who would cheat.

That's another thing I should mention. Cheaters typically do fit a "profile" from what I find. Someone with a level-headed attitude, who isn't super-concerned with winning or fame or anything like that, is less likely to cheat for example.

Also the more someone says "lol", the more they cheat.

[Grytolle]

<b>Ammo hacking</b>: Look for things like people having a seemingly limitless supply of seekers, espically in levels or areas where they are not particularly abundant. People using powerups that aren't in the level is a dead giveaway, though most people aren't that stupid. Many are stupid enough, however, to spawn with full ammo. If you see someone firing a barrage of seekers the second after they spawn, you know something's up. Except on bblair, where there is a carrot you can die on very close to the spawnplace.

[Stijn]

I've been thinking recently that something like an OpenJazz2 is perhaps our only solution to the mass-hacking that is taking place. Jazz2 is vulnerable to memory and packet editing, which allows for some pretty cool tweaks, but also to a lot of cheating. The problem is, ofcourse, that an OpenJazz2 would need a large amount of time and a few programmers who know what they're doing. And I doubt anyone would be willing to invest so much time in it.

[Grytolle]

True, I guess we will just have to trust our opponents. The good thing is that the community grows older and so does its members. This could possibly decrease the cheating.

[Vegito]

haha, mono, I excactly thought about the same thing :)

[Cpp]

This is exactly why I make (or at least try to make) my new programs work for the server and the server only. This way clients cannot use certain features, but should the server use them it would give all the client players in the server an equal (dis)advantage.

[Monolith]

For detecting cheats such as those EvilMike mentioned, my thought is to get the server to keep track of more things, and make sure what the client is doing matches with what the server knows. So long as the server keeps track of such as ammo and coins for each of the clients, we could possibly check for things like if the client is shooting a lot more ammo than the server knows they have, or if the client goes through a coin warp even when they haven't collected so many coins. I'm thinking we could also check for illegal warping by seeing if a player jumps by more than a few tiles when they're not near a warp.

Another idea that I had which would be even more complicated could be to not send information to the clients unless it is something that is within the client's possible view area. This way they wouldn't be able to know where people are on the other side of the level, or if certain items have respawned.

[Cpp]

Mono, if you are talking seriously about making a decent cheat protection for jj2 then I suggest you take a look at how the CSHP (client side hack protection) from UT99 works and then make something that works in a similar way. You can never get as much information from your own server by observing memory/packets as you can from doing the same thing on a client's PC. CSHP really runs a script on the client side and checks for any hacks that might be messing up with the game. This way you'd know for sure if someone is warping (eliminates the false positives that lag can cause). You could also search the processes to find if any match those of jj2 cheating tools, etc. The choices are endless. This approach should be more efficient, but also more difficult to create and manage.

[Grytolle]

Overlord is right. That is about the only sure way.

[Birdie]

You could also search the processes to find if any match those of jj2 cheating tools
This one I would prefer, mainly because I always run programs with jj2, like autorun and ect.

[Monolith]

I haven't taken a look at how any CSHP works before. It could work better than trying to detect things from the server, but still how would you detect things on the client's side? Just looking at the running processes wouldn't be any good because they could just rename the program.

[Cpp]

I haven't taken a look at how any CSHP works before. It could work better than trying to detect things from the server, but still how would you detect things on the client's side?The same way you do it on server.Just looking at the running processes wouldn't be any good because they could just rename the program.
There should be a blacklist for the cheating tools containing unique signatures so that the client scanner can recognise these right away.

Here are some methods I had in mind:
- Size and MD5/CRC32 of the exe or some internal parts of it
- Window captions and class names
- Search for certain text strings within the process
- Spy the APIs to see if any program is using an API to memory edit Jazz 2

[jam]

How will the server make sure the client is running the program?

[Grytolle]

Some kind of ping or whatever

[Torkell]

How will the server make sure that the client isn't running a program pretending to be an anti-cheat one?

[Grytolle]

Don't know :(

[Cpp]

How will the server make sure that the client isn't running a program pretending to be an anti-cheat one?Because it will download it from the server itself before the game begins.

[Cpp]

Consider it like this: Client wants to join the protected server. So he runs a reqired executable on his PC after running jj2 (if he doesn't do so, server will block him). While connecting to the server, the software will make jj2 download a fresh and working component of the anti-cheating software from the server itself and then execute it on the client's PC. There will be a unique algorithm in the downloaded component each time it is downloaded and this algorithm will be used to process some data received from the server and return the result back to the server. Sort of like a challenge-response approach. This way the server will know for sure that the software has not been modified if the returned result matches the one produced on the server.

[Birdie]

Consider it like this: Client wants to join the protected server. So he runs a reqired executable on his PC after running jj2 (if he doesn't do so, server will block him). While connecting to the server, the software will make jj2 download a fresh and working component of the anti-cheating software from the server itself and then execute it on the client's PC. There will be a unique algorithm in the downloaded component each time it is downloaded and this algorithm will be used to process some data received from the server and return the result back to the server. Sort of like a challenge-response approach. This way the server will know for sure that the software has not been modified if the returned result matches the one produced on the server.
:) This would work very well, so then you can get rid of cheaters but still host "test" type servers without kick/banning anyone.

[jam]

I could put a trojan in the file and tell someone to join my server =(

[Trafton]

I could put a trojan in the file and tell someone to join my server =(

Trojan in what file?

I am assuming the program file in question would be standardised and mandated (tertiary programs would be a horrible idea!). If you mean a trojan transferred by the server somehow, that is impossible without a receiver program unless Jazz 2 has a rather severe bug of which we are not aware (possible, but unlikely).

[Grytolle]

Trafton, pay attention... Overlord's idea was to force the player to download a program form the server in order to join... That could be a trojan.

[Cpp]

I could put a trojan in the file and tell someone to join my server =(No, you couldn't do that for the file that clients need to download would be generated automatically by the server software each time a new client joins. And the software that clients need would be available for everyone on a trusted website with a MD5 signature.

Edit: Also the file clients must download doesn't neccessarily have to contain executable code. I do admit that there are some things that I haven't given much thought, but this suggestion of mine is still on a drawing board. Thanks for pointing them out.

[DaPete10]

Hello again, you suxfoos.


Here are some methods I had in mind:
- Size and MD5/CRC32 of the exe or some internal parts of it
- Window captions and class names
- Search for certain text strings within the process
- Spy the APIs to see if any program is using an API to memory edit Jazz 2


Yeah, but this also poses a security risk, people hosting servers could find people's credit card numbers and stuff.


I've been thinking recently that something like an OpenJazz2 is perhaps our only solution to the mass-hacking that is taking place. Jazz2 is vulnerable to memory and packet editing, which allows for some pretty cool tweaks, but also to a lot of cheating. The problem is, ofcourse, that an OpenJazz2 would need a large amount of time and a few programmers who know what they're doing. And I doubt anyone would be willing to invest so much time in it.


You mean me? Well, I have some spare time that I could work on it. However, since the list servers are run by (-)s, then nah, forget it.

Now to answer more stuff before I go back to lurking.

[Neobeo]

For some reason I somewhat agree with Pete. ;o. In all fairness, I would like to see some kind of security measure, but I am completely against the idea of using a clientside program to search for background processes.

Well, ok, so I may have had childhood traumas with certain anti-hacking tools used in multiplayer games. Sure, it may not be anywhere near malicious as nProtect GameGuard (http://en.wikipedia.org/wiki/GameGuard), PunkBuster (http://en.wikipedia.org/wiki/PunkBuster) or The Warden (http://en.wikipedia.org/wiki/The_Warden_%28software%29), but I plain don't like the idea of a background process invading your (my) privacy, even if it's for the better good.

I don't claim to be an expert on security measures, but from my experience with dozens of online multiplayer games, anti-hacking tools can only go so far. These sneaky processes either totally invade your privacy or can be easily bypassed anyway, sometimes both. In fact, the only way to make a completely secure game would be to make everything server-side (aka. a telnet game).

Of course, I have also seen plenty of self-sufficient anti-hacking techniques in my day. In JJ2's context, this would translate to the server keeping track of what the player does (eg. adding 3 ammo to the player when collects one, or zeroing the ammo when he dies), which is prone to lag anyway.

To conclude, I do not approve of any of the counter-hacking measures I have ever experienced. Not to be a spoilsport, I think JJ2 could use one of its own, but I don't think it will benefit that much anyway. As it stands, the best solution would be some sort of OpenJazz2. There is just way too much lag in online JJ2 to be overly dependent on any anti-cheating measures.

[NovaStar]

I don't really mind unless it's cheating or hacking.

[R3ptile]

(edit: forget what i said)

Well, as Mike said, ammo hacking is very easy to notice and I haven't seen any major problem regarding it.

[Stijn]

You mean me?
No, I meant people that care about the game.

[Cpp]

In fact, the only way to make a completely secure game would be to make everything server-side (aka. a telnet game).True. It's how UT2004 works. I suggested the CSHP method for jj2 since the "everything server-side" is an impossible task for jj2 itself. If we were to obtain the source code then this anti-cheating approach would be the first thing to pop into my mind.