Various cheat methods and workarounds

[»Ceiu]

This is a conversation between D1st0rt, Arnk Dylie, and myself regarding various cheating issues that arise with an open source client and possible ways to defeat them.

 

It kinda died off abruptly, but take what you will out of it:

 

	Cerium> question
Cerium> how much work is it for the server to do collision detection?
Arnk Dylie> between players?
Cerium> si
Arnk Dylie> I did it once
Arnk Dylie> probably using the worst algorithm evar
Cerium> I mean for weapons too
Arnk Dylie> an O(n^2) one
  D1st0rt> pain in the !@#$%^&* cerium
Cerium> well, I imagine, but I'm talking about load
Arnk Dylie> for just weapons you could probably get away with O(N)
  D1st0rt> have you ever thought about what would happen to a repped burst
Arnk Dylie> !@#$%^&*uming no repels
Cerium> the server would see it slightly quicker than other players
Arnk Dylie> lulz
Cerium> and slower than the player who repeled
Cerium> naturally there'd be lag
Cerium> but I was thinking about a few things:
  D1st0rt> lag would determine whether you had favorable results or not
Cerium> if continuum or any game like it were open source
Cerium> how could you do things like x-radar or anti-warp and remove the possibility for a client-mod to have them always enabled/disabled
  D1st0rt> just keep turning it off
Cerium> with x, you can't send a cloaked players position, as the client could just always show it
  D1st0rt> lol
Cerium> but if you simply didn't send regular position updates, you'd have some weapon desynch
Cerium> however, if there was a packet that said "invalidate weapon #"
  D1st0rt> cerium just keep turning their xradar off
  D1st0rt> loawl
Cerium> I'm being serious
  D1st0rt> yeah, keep turning it off
Cerium> what would that do if they've modified the client to always show cloaked players, regardless of the state of x radar
  D1st0rt> o
  D1st0rt> you're going that far
Arnk Dylie> you're asking how to do that
Cerium> I'm !@#$%^&*uming continuum were 100% open source
Arnk Dylie> or.
Cerium> I'm just thinking outloud, basically
Cerium> if weapons had actual IDs, and players always had watchdamage on (or a more efficient version) [zomg bandwidth!!!]
Cerium> then the server could just tell a client to invalidate a weapon
Cerium> then it wouldn't have to send position packets for cloaked players
Cerium> and the weapon desynch wouldn't be TOO bad
Arnk Dylie> you have to know if you hit a cloaked player though
Cerium> nah
  D1st0rt> what would stop a player from invalidating all weapons
Arnk Dylie> unless the nature of cloak is changed
Cerium> hrmm
Cerium> good point 
  D1st0rt> that would be a neat trick
Cerium> arnk, my idea was simply to have the cloaked player report when it's hit and by what weapon
Cerium> and the server tells other clients to invalidate that weapon
Arnk Dylie> oh, ok
Arnk Dylie> laggy cloak
Arnk Dylie> then
Cerium> but, as d1 said, a cheater could just modify the client to invalidate weapons on command
  D1st0rt> super zones be !@#$%^&*ed
Arnk Dylie> ^
Cerium> yeah, a tad laggy =P
Cerium> but it would effectively prevent the always-x cheat
Cerium> in favor of a godmode cheat =P
Cerium> well, actually
Cerium> hrmm... nevermind
  D1st0rt> well, what would stop a player from doing godmode anyway
  D1st0rt> if they had the full source
Cerium> hrmm
Cerium> I suppose that's where the server collision checks come into play
Cerium> originally I was thinking the server could tell another client they've hit a cloaked player
Cerium> but, this would also be able to tell a player when they've been hit
Cerium> I wonder if a hybrid client-server damage method would work
Cerium> realistically, how much traffic does a client require for this game?
  D1st0rt> sec
  D1st0rt> priit did the calculations one time on tw forums
Arnk Dylie> about...20b*players/s + others?
  D1st0rt> http://forums.trenchwars.org/showpost.php?p=137103&postcount=15
Cerium> so 500 bytes/sec per player in TW?
  D1st0rt> 2 KB/s
Cerium> ahh
Cerium> hrmm
Cerium> that's a lot of traffic
Arnk Dylie> no
Arnk Dylie> well ya on the server's end
Arnk Dylie> not for each client
Cerium> well, I'm more worried about server
Cerium> a lot of these ideas I'm going to be throwing at bak for discretion
Cerium> others... just because I'm !@#$%^&*in bored
Cerium> in any event, I think if you did a server/client damage system, you may be able to prevent godmode type stuff
Cerium> but at the expense of greatly increasing bandwidth
Cerium> also, the server itself would have to be a client.
  D1st0rt> cerium what you could do
  D1st0rt> is just do some rough checking, then if its blatant
  D1st0rt> spit out red text to online staff
Cerium> how rough are you suggesting though?
  D1st0rt> well obviously its not going to look the same as it does to the client
  D1st0rt> so you can't expect 100% accuracy
  D1st0rt> i would say your precision depends on the lag
Cerium> so you're saying, rather than the server telling a client about missed damage they should have taken
Cerium> just reporting it if a client is "evading" x%

[Smong]

I wonder how repels do work. Simplist glitchy method is for the client to apply the repel to nearby weapons as soon as it receives the packet. A more synced method could be to keep track of a weapon state history, and apply the repel when it was actually fired - although this would have to take into account weapons that the client already expired somehow (enemy ship, wall) between the actual time the repel fired and the current time.

 

If you had server side damage then a weapon invalidate packet for cloakers can be used, of course toggling cloak/xradar will now have a delay. Any client deleting all weapons would still die since the server would know it should. Clients won't be able to send their own kill packets anymore, since this leaves room for cheating within a threshold. There will probably be glitchy gameplay, which happens a lot in modern games too (people eating bullets, seeing people suddenly appear out of nowhere, getting killed without seeing the killer).

[L.C.]

If a player were to cloak, then the server should stop sending movement data and stuff about this player (except only to those players with x-radar on). The server would monitor this cloaked user. If the user shoots, then the server will send this new and fresh data, almost as if a player warped into a location. If you had an arena full of people (say 50) and hung around the center of the map peacefully (no firing of any projectiles or immobile things, strictly none), think of how much bandwidth traffic there would be going C2S and S2C. Now if players started turning on cloak, then there would be less data traffic in S2C. Of course if Stealth isn't turned on, the server would only bother sending that data (as simple as movement packets can get; it shouldn't concentrate on anything else). If both cloak and stealth were turned on, then that'd be a bandwidth saver for the time being.

 

Probably one of the things that could probably be done to minimize cheats could be to take a few client-side things (that are necessary for such method) and make it mostly server-side. Then again, what if the cheater has X-Radar or tries to cheat it on... :\ Server would need to monitor literally every spawn and ship (their status, items, etc) and verify them so often. Bandwidth traffic would increase though, so then this might not exactly be the greatest idea. :\ There are still some dialup players out there (I am one of them ).

 

EDIT :: Hey, talk with Invader-Zim about this. Mention DLL hacks and injections, maybe he might get started about telling of some of his neat toys.

Edited June 13, 2007 by L.C.

[Drake7707]

everything a client sends has to be double checked by the server. Weapon delay when client firing received, player position when client send 'turning to a different angle' (angle speed check too), ...

[»doc flabby]

Alternatively do no cheat detection on the server, but do it on the client,

Get the clients to do all the checking as they have more processor power space.

 

The clients then report cheating behaviour to the server.

It doesn't matter if people use the wrong client as the other clients will find them out and get them banned.

Much like distributed computing.

 

Of course this in itself could be abused without some careful security measures....so its a useless idea, but just an alternate view.

Edited June 13, 2007 by doc flabby

[Bak]

I like that idea doc flabby. One thing I came up with for these sorts of items like repels or portals is to give the server the option of having a delay between when the player presses the key and before it activates... so like when you press insert it won't warp you until 1 second later, thus preventing a cheat that says you pressed insert if you were about to get blown up (or repel, for that matter). Checking everything probably isn't necessary (you could check 10% of packets at random, for example), since you only have to catch someone cheating once to ban them but they have to cheat often to have an advantage.

[»CypherJF]

What stops someone from writing a client that abuses the privilege of reporting a cheating client.. especially when things get heated up during a game?

[»Ceiu]

If all it does is throws that player in the queue to be checked, it'll just be a waste of cycles really. Besides, if all the clients are doing these checks but only a few are generating these reports, you could still queue up the player check, but at a lower priority...

 

This is !@#$%^&*uming that the engine only checks players at random, rather than watching everyone in real time.

[Smong]

Server would need to monitor literally every spawn and ship (their status, items, etc) and verify them so often. Bandwidth traffic would increase though

The bandwidth doesn't have to increase if the server is doing the monitoring, it already gets sent all the necessary data. With ASSS you could even move initial bounty server side, so you know more accurately what players starting items are.

 

When you guys are talking about "checks" what are you actually talking about? I can't see how you can detect a bot firing a repel to avoid death, some players will do this anyway. Are you talking about using repels you don't have?

 

If the clients check each other how are you going to handle heavily modded zones that use per-player settings? Every client would need a copy of every other clients current settings to check against.

[Drake7707]

What stops someone from writing a client that abuses the privilege of reporting a cheating client.. especially when things get heated up during a game?

 

when a client reports a cheater along with the reason , let the server check the reason too. Although, the bad thing about distributed client approach is, like smong said, that clients need all info on the other players itself, which a modified client can exploit :/

 

@smong: yeah, the normally impossible stuff checks

[Smong]

So you're just going to ban anyone that warps, fires a repel, etc when a weapon would have hit them?

[JoWie]

To conserve server processing power. Instead of checking all players at once, check only a limited amount of players for a time period then move on to other randomly selected players.

 

You could even decrease the likelihood of a player being checked when it has a higher usage in the particular server then others.

 

Decreases the likelihood of catching a cheater a bit but would still make cheating a lot more difficult

[Drake7707]

So you're just going to ban anyone that warps, fires a repel, etc when a weapon would have hit them?

 

 

I ment based on conclusive evidence that someone is cheating.

 

Like calculating the distance required to go from point A to point B when they didn't use a warp point or attached to a ship or went to center, if the distance is remarkably smaller than shortest distance, then they just lagged or hacked through walls.

This is probably a bad example if you want to keep the server strain as low as possible with overhead checks.

 

 

Edit:maybe a bit better example: like the server checks what the delay was between 2 fired shots. Smaller delay than specified in the ini = not possible = hacking.

[Arry]

Even with open source, can't you have some sort of method to only allow the latest official versions of the client? (like code signing or something.. not sure exactly what it's called) If you could garuntee a player was using an unmodified client, then you wouldn't have to hunt down every last rabbit hole that a cheat could be hiding in by modifying the code. Actually, you still need checks because of memory hacks and such, but I think if you start out with verifying the version of the client, then you defeat blatent source-code changes.

[Samapico]

Yeah, can't there be a security module that is not open-source that makes some checksums on the client or something? I know it has been discussed before... dunno why noone talks about it anymore.

The module itself would have to send the key, encrypted in some way so it cannot be sniffed, that tells the server which version and if the checksum matches.

 

I think some people were saying that they could modify the client to fake the 'OK' signal to the server, but if it needs to actually send an encrypted key, I don't think they could do that.

And there could be updates (automatic) every X weeks or months that change the key/encryption method.

[Bak]

yes, that's a very good point. I think about this sometimes and what worries me is man-in-the-middle attacks, where there's a hacked discretion client, acting as a server talking to a real discretion client. the fake one connects to a server and passes the info to the real client, which generates the real response and sends it to the fake client, which then passes it on the server... then the fake client takes over and the server thinks everything's ok.

 

hmm, I think the security module would have to act as the module manager so it can be certain that it's doing checksums of the right code. also, the server could encode it's ip address into the encrypted packet and the security module could send data directly to that ip address (that could probably be worked around, although it would be a lot harder than a simple man-in-the-middle, I'm pretty sure that's how continuum's billing server works since if you ever try to do a man-in-the-middle server in continuum to an ssc zone you still get a "not connected to the central player database" warning when connecting).

 

I mean, it's definitely a possibility.

[»doc flabby]

hmm, I think the security module would have to act as the module manager so it can be certain that it's doing checksums of the right code. also, the server could encode it's ip address into the encrypted packet and the security module could send data directly to that ip address (that could probably be worked around, although it would be a lot harder than a simple man-in-the-middle, I'm pretty sure that's how continuum's billing server works since if you ever try to do a man-in-the-middle server in continuum to an ssc zone you still get a "not connected to the central player database" warning when connecting).

Why not force all packets to go though the security manager (ie make it include the encryption), making it impossible to byp!@#$%^&* (that act of byp!@#$%^&*ing means you won't be able to connect to offical zones, which is fine). It you make the module manager closed source you will run into trouble with using a open-source code (if you are using gpl code in your project anyway).

 

A closed source secuirty module or separate program is a good solution. Similar to other games, that detects cheats (of cource it will be a never ending battle, of updating, things get cracked). Its how i intend on securing TCP. As long as its good enough to stop 95% of hacks, its probably enough, after all people can always lag cheat, and to detect that you will need a person (espcially spikes etc) who can make a judgement if its "normal" or "manipulated" lag.

 

A simple way to prevent the security data key being sniffed would be to use RSA (with IV - salt to prevent it being predictable) encode the checksum with a public key. If the private key is ever leaked its very easy to generate a new one. That will prevent fake/clone/modded clients, then you just have to worry about memory hacking, which is harder to deal with.

 

One way to deal with cheating is to use the CPU on your clients to work out if someone is cheating, basically make all the clients snitches

Edited January 18, 2008 by doc flabby

[Bak]

even if your packets are perfectly encrypted, how do you know the networking security module is not passing along the valid decrypted data to say, a physics module that lets the player go through walls?

[»doc flabby]

even if your packets are perfectly encrypted, how do you know the networking security module is not passing along the valid decrypted data to say, a physics module that lets the player go through walls?

you don't One task of the security module would be ensure the integrety of the loaded modules. It would have to do this in an independant way one way would be by looking at the memory space of the client and seeing what shared modules are acctually loaded ie, it doesnt trust what the modulemanger says is loaded. Alternativly it could random run test cases (provided by the server) against the modules to ensure they are performing as expected.

 

The encryption was more to do with getting messages from the security module to the server without them being tampered with. By forcing all packets though the security manager it makes it difficult (but not impossible) to work out which packets are security packets, and which are regular.

[»Ceiu]

The problem is you're still relying on code running on the user's machine to be "telling the truth" -- it'll never be secure. The only thing we can really do is make breaking the security so tedious that no one would bother doing it (at which point we run the risk of writing so much spaghetti code that it's a pain in the !@#$%^&* to manage).

 

Meh. I say we just do a fair amount of server-level checks and physics.

[Drake7707]

or you implement a voting system that when enough users vote, the user gets monitored much more closely (server checks about anything the client sends). That avoids the server strain (unless people would actually be bothered or bored enough to do this on about every user in the zone but i doubt that (voting amount restriction could solve that)).

[Samapico]

A ?report would work... Though the server could ignore/warn/kick someone abusing it.

 

The problem is you're still relying on code running on the user's machine to be "telling the truth"

But again, just some kind of checksum could confirm that the exe is official. Like the current continuum.exe, if you hex-edit stuff in there, it won't work at all, right? Of course that won't solve 100% of the problems, but I'm pretty sure it would make cheating 90% more complicated, so 90% less cheating. Only freaks like you would be able to get through that It's enough to get rid of all the kids who are like "LOLZ IM GUNNA CHANGE DA CODE TO GO TRU WALLZ IM SO 1337 LOLZ"

[JoWie]

Just hire some guy in india to catch cheaters for $1 per find.

[Bak]

But again, just some kind of checksum could confirm that the exe is official.

 

ehh, who's gonna do the checksum? the client. So, again, man-in-the-middle attack works.

[Drake7707]

unless you encrypt each packet with the checksum.

 

 

(like every minute)

Server -> challenge -> Client

Client closed module creates checksum

 

Client closed module has encryptPacket() that needs to be used when data is sent to server

 

The time interval (e.g 1 minute) recycling would be used so the checksum can't be figured out when a lot of packets are sent (like the way WEP is cracked)

 

 

Hm though, the fake client could always use the legit module :/