How to cool-down the Char Jump

I'm playing in a Private server, and there are so many abuser using the new conquer online jump, the server is classic with old jump.

So i'm asking about a way to cool-down the old jump in C3 folder so no one can edit it.

I got a video with jump editing > <

When the client loads, the file that dictates the animation of a jump is loaded into memory; basically, edits to this file after the client loads will not change anything.

Knowing that, you could communicate a CRC hash of the C3 file to the server for verification, but also a CRC hash of the library which creates the CRC hashes. Ensuring no modifications to the library which creates the hash causing the library to constantly send the proper hash, even though the file was edited, can only be done this way.

Using your own, proprietary cipher.. send the hashes to the server, decipher them, and match them with constant values within the server's configuration. If they're not matching or if the information expected wasn't received, there are edits involved.

I would suggest this modification in the log-in process.

#edit
Just keep in mind this will not block all methods of editing jumps.
There's still the need for memory checking in the event of memory edits.

Or maybe ... this is gonna sound crazy ... put a server-side check that prevents people from jumping too fast?

Quote:

Originally Posted by Best Coder 2014 ...put a server-side check that prevents people from jumping too fast?

Good idea, but it creates a problem for those with low throughput networks or those networks with high latency to the carrier. Especially with cellular and satellite networks, data can come through in bursts after a long pause, same with DSL networks; the majority of players use DSL to connect to my servers. A couple or three jump packets get caught up in one of these pauses, then sent at once.. what's going to happen to that player? Disconnection, ban (like TQ not more than a year ago :p)??

I suppose you could use the time stamps in the client packets, though they could be easily edited, extra server-side checks could be necessary.

Quote:

Originally Posted by .Ocularis Good idea, but it creates a problem for those with low throughput networks or those networks with high latency to the carrier. Especially with cellular and satellite networks, data can come through in bursts after a long pause, same with DSL networks; the majority of players use DSL to connect to my servers. A couple or three jump packets get caught up in one of these pauses, then sent at once.. what's going to happen to that player? Disconnection, ban (like TQ not more than a year ago :p)?? I suppose you could use the time stamps in the client packets, though they could be easily edited, extra server-side checks could be necessary.

Just use the "pullback" (MsgAction with action = 108) packet whenever a player goes too fast. I think that's what ConquerPS and most other "decent" servers do.

Quote:

Originally Posted by Best Coder 2014 Just use the "pullback" (MsgAction with action = 108) packet whenever a player goes too fast. I think that's what ConquerPS and most other "decent" servers do.

Server side speedhack checks should always be implemented but are in no way accurate.

Quote:

Originally Posted by .Ocularis Good idea, but it creates a problem for those with low throughput networks or those networks with high latency to the carrier. Especially with cellular and satellite networks, data can come through in bursts after a long pause, same with DSL networks; the majority of players use DSL to connect to my servers. A couple or three jump packets get caught up in one of these pauses, then sent at once.. what's going to happen to that player? Disconnection, ban (like TQ not more than a year ago :p)?? I suppose you could use the time stamps in the client packets, though they could be easily edited, extra server-side checks could be necessary.

Based on my minor testing recently, it appears as though the client side timestamps are also not accurate in earlier patches.

Yes, they work but they often will be far closer together than they should be (claiming the client jumped twice within ~300 ms when that's obviously not the case)



In my experience you want basic server side checks to catch very obvious speed hackers (say jumping faster than 400-500 ms and ensuring the check is not performed right after fly/xp/transformation ends and not checking during those states) but you're still going to want some sort of extra protection (such as a client side exploit check or invisible proxy that sends extra validation to the server)


It's my VERY limited understanding that ConquerPS uses heavy client editing to accomplish most of their features and as part of those changes added a large amount of extra data verification both to the client and server which is how they accurately detect things like speedhack.