Post: #13

(03-07-2014 03:25 AM)Feeh Wrote:  The client/server protocol does have an specific way to check if the client is speedhacking. Talking about packets, each step is followed by a random number that should be generated by sphere and sent back to the server to validate the step. When the player log in the server send six of these random numbers to the client, and when the client is about to send the last one the server resend six new numbers to the client only if the last walk packet time is sent AFTER the next update time.
I was not able to reproduce this system using sphere some time ago, but I made it for RunUO.

I can give more information about it if anyone find it usefull

As I found here, there's 4 packets handling movements
-02: Move Request (client -> server)
-021: Move Rejection (client <- server)
-022: Character Move ACK/ Resync Request (client <-> server)
-0bf (subcommand 02): Add key to Fast Walk Stack (client <- server)
http://docs.polserver.com/packets

and the packet 02 has this note:

Quote:Sequence number starts at 0, after a reset. However, if 255 is reached, the next seq # is 1, not 0.

Fastwalk prevention notes: each 0x02 pops the top element from fastwalk key stack. (0xbf sub1 init. fastwalk stack, 0xbf sub2 pushes an element to stack)
If stack is empty key value is 0. (-> never set keys to 0 in 0xbf sub 1/2)
Because client sometimes sends bursts of 0x02's DON'T check for a certain top stack value.
The only safe way to detect fastwalk: push a key after EACH 0x21, 0x22, (=send 0xbf sub 2) check in 0x02 for stack emptyness.

If empty -> fastwalk alert.
Note that actual key values are irrelevant. (just don't use 0)
Of course without perfect 0x02/0x21/0x22 synch (serverside) it's useless to use fastwalk detection.
Last but not least: fastwalk detection adds 9 bytes per step and player !

I can filter packet sent to server to get some packet data, but I don't get the point on how to handle everything in the correct order to sync all packets and make they work together