Threaded Mode | Linear Mode

Extreme · (03-15-2014)

I've made a script to check how many steps a player did in 1s, BUT checking every 100ms (200ms to be clear... Timerd 1 isnt 100ms... Is buggy)
So im every 1s it counts if the player did more than 11 steps... More than this is speedhacking..
I also made the same script on injection which is more accurate because I can use lower timers..

Using boths is very easy to detect speeehacking.

Later I share it.

Staff_Stanic · 03-15-2014 04:01 AM

Here guys: http://forum.spherecommunity.net/Thread-...tion--3339
The script use the Packet 0x02 to check the distance that the player walked in the last 200ms.
We use a lot of tags (to improve the checking system), but all are cleared when finalized, so don't worry.
Please feed me back Smile

***Coruja*** · 03-16-2014 02:25 AM

(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

***Feeh*** · (03-16-2014)

(03-16-2014 02:25 AM)Coruja Wrote: 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

I'll try to describe the (packet key based) complete detection process I'm using on my RunUO, the default method is omitted

Code:

@Player login

-Initialize a new stack with 6 keys and send it to the client

-player tag.stackwarn set to 0

-player tag.moves set to 0

//Stack = array of keys stored on the server

@Player movement

IF player changing direction

    IF stack count > 15

        -Reset the stack, add 6 new keys and store them

    ENDIF

    -Send a new single key and store it to the stack

    -Handle movement

    return;

ENDIF

IF stack contains key AND player tag.moves < 6

    -Remove key from stack

    -increase player tag.moves by 1

    -Initialize the separated thread FastWalkHelper if not initialized (we do not want 2 threads working)

ELSE

    -Possible fastwalk detected, block movement (paralize) for 0.2s (rejecting movement causing client to stop walking until teleport)

    -increase player tag.stackwarn by 1

ENDIF

-Handle movement

@player resync request

-Add a new key to the stack and send it to the player

@FastWalkHelper

WHILE player tag.moves > 0 AND player connected

    -wait run speed seconds (0.1 for mounted / 0.2 for foot)

    -decrease player tag.moves by 1

    IF stack count > 15

        -Reset the stack, add 6 new keys and store them

    ENDIF

    -Add a new key to the stack and send it to the player

    IF player tag.stackwarn > 0

        -decrease player tag.stackwarn by 1

        IF player tag.stackwarn > 5

            -report to the staff team the fastwalking player (movement was already blocked)

            //break while ?

        ENDIF

    ENDIF

ENDWHILE

-player tag.stackwarn set to 0

-thread end, exit and dispose resources

The FastWalkHelper is a separated thread, it runs asynchronous from the main thread, one thread per player (a bit unoptimized here)
The run time for each thread should not be any longer than 1 second and does not consume much memory and processor usage.
Tested with ~100 bots running from the same machine as the server (my pc) with some of them speedhacking

It can be possible to translate the thread to timer(f)-based but I have no idea on how Sphere handles the timers.
SQLite based tables could do the trick, but would require and incredible sync (time<>key<>move speed)

***Coruja*** · 03-16-2014 11:23 AM

I'm trying using the sphere packet filter
but what packet I must send to the client to make it use these generated numbers?

***Feeh*** · 03-16-2014 01:27 PM

BF.01 will send six(?) of them and invalidate the old ones
BF.02 will send a single one

***Coruja*** · 03-16-2014 03:36 PM

done

Code:

//Send 5 keys:

SENDPACKET 0bf W29 W01 D<R1000000000> D<R1000000000> D<R1000000000> D<R1000000000> D<R1000000000> D<R1000000000>

//Send a single key:

SENDPACKET 0bf W09 W02 D<R1000000000>

I already tested filtering packet 02 received from the client and it's working fine, the client can receive and use these keys on next 5 (or 1) walk requests

now the problem is create an engine to validate all this thing

after some more tries, now I'm stuck because there's no way to do this by scripts, it must be done on server side

I found this info on packet guide:

Quote: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 !

there's no way to do this only using scripts because the key must be sent to the client when the server send the packet 021 / 022 too, which is the server response to packet 02 (walk request) telling if the walk request was accepted (021) or denied (022)

on scripts we can only filter packets received by the server, but not packets sent. So we can check the packet 02 data, but there's no way to send the "keys packet" together with packet 021 / 022

so to make it work I think we will need a dev hand to make the server send this new packet together with packet 021 / 022

Code:

[FUNCTION AddFastWalkKey]

SENDPACKET 0bf W09 W02 D<R1000000000>

only sending this single packet wont solve the problem yet, but will allow the packet 02 response to be checked later on the script-side to make the engine works

***Ben*** · 03-16-2014 10:39 PM

ok, I just had a look into the source... surprise surprise... This seems to have already been implemented if you activate the DebugFlags = 0x80 in sphere.ini; 0x80 is DEBUGF_WALKCODES.

Now, I'm not sure if the whole thing works like described above, but if some of you would like to test it, I'll be glad to tweak it to work properly. Maybe it could also be moved to an OF_Flag instead of a Debug flag

***Feeh*** · 03-17-2014 02:09 AM

(03-16-2014 03:36 PM)Coruja Wrote: 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 you send a key after 0x21/0x22, when you receive the next 0x02 the stack will never be empty, right? Although RUOSI provides the most complete packet guide I started to find it not-so-much reliable or not well described
PS: I don't know if you're still in the test phase of the script or started the real development, but these keys you send to the client must be stored in the server, once it is possible to hijack the packets it is possible to send non-zero keys and bypass the fast walk check Smile

(03-16-2014 10:39 PM)Ben Wrote: ok, I just had a look into the source... surprise surprise... This seems to have already been implemented if you activate the DebugFlags = 0x80 in sphere.ini; 0x80 is DEBUGF_WALKCODES.

What about the DEBUGF_WALK 02000? It does use the F0/F1 packet?

***Coruja*** · (03-17-2014)

(03-16-2014 10:39 PM)Ben Wrote: ok, I just had a look into the source... surprise surprise... This seems to have already been implemented if you activate the DebugFlags = 0x80 in sphere.ini; 0x80 is DEBUGF_WALKCODES.

Now, I'm not sure if the whole thing works like described above, but if some of you would like to test it, I'll be glad to tweak it to work properly. Maybe it could also be moved to an OF_Flag instead of a Debug flag

roflmao

I tested here and it seems to be broken, sphere send first 5 keys on client login, check for the keys on walk packet 02, but doesnt "renew" these keys. So the char can only walk 5 steps after login, then it got stuck and cant walk anymore, spamming this console error:

13:42:ERROR:1: Invalid walk echo (00). Invalid after valid.

I tried to send these keys manually to the client, but even if it receive and use these keys, the char doesnt walk. Maybe there's something internal on sphere checking for a specific value and will only allow the char to move using this value

(03-17-2014 02:09 AM)Feeh Wrote:
(03-16-2014 03:36 PM)Coruja Wrote: 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 you send a key after 0x21/0x22, when you receive the next 0x02 the stack will never be empty, right? Although RUOSI provides the most complete packet guide I started to find it not-so-much reliable or not well described
PS: I don't know if you're still in the test phase of the script or started the real development, but these keys you send to the client must be stored in the server, once it is possible to hijack the packets it is possible to send non-zero keys and bypass the fast walk check

for now I'm just testing, the most important is make it works even with a simple code Tongue

1st stage = make it work
2nd stage = improve the code
3rd stage = test on live server lol

Threaded Mode \| Linear Mode Change-Speed Detectation
Author	Message