UOX3 and Fastwalking/Speedhacking

[Xuri]

Anyone know where UOX3 stands when it comes to fastwalking/speedhacking? Are there any measures implemented to prevent it?

Found some interesting tidbits in a thread on the POL forums about anti-fastwalking packets etc:
http://www.polserver.com/modules.php?na ... pic&t=1034

[giwo]

I can almost guarantee it's possible. Fastwalking, at least as much as I know about it, is based on pushing multiple packets to the server. Much of our walking code hasn't changed since the 0.69.x versions and thus is run everytime it receives a packet, even if it were to receive 3x the amount of walking packets the OSI client would normally send.

I believe the client has some measures against this, but I do not believe we have implemented support for those measures as of yet. Honestly while this is an issue as UOX3 begins to come into a place where it is a viable option, there are quite a few bugs (and even more we don't know about yet) that could be show stoppers as well.

Ultimately security and proper handling should be built into every new system and change we do, and I do strive for that. It doesn't always happen that way, though.

[Sydius]

I would not worry about the whole stack/client-based approach… I am sure it is more accurate, but for the purposes of emulation, I think the server-side timing approach would be easiest to implement. Just add a variable to each client connection, and store the last “walk succeed” time, then compare the next time it receives an attempt. If it the attempt comes too soon, delay the response until it is okay. If it receives two or three attempts before it is okay, can the connection and log it.

You have to take into account the fact that packets can pile up, though, and come in bursts due to network conditions, but generally, the above method would probably suffice.

[giwo]

Yeah, with any method false positives are what I'm most concerned with.

A laggy connection could get you consistently flagged for "fastwalking"

[Xuri]

Well, simply having a way of flagging potential cheaters is better than nothing, even if it did nothing else than mark the account/character or whatever with a "possible fastwalk"-note.

And if it was implemented in a way that let the admin customize whatever variables are used (required number of times to be "noticed" by the server before being flagged for fastwalking, for instance), it could be up to the admins to find the "sweet spot" for their shard where they'd have less false positives.

[Grimson]

If it receives two or three attempts before it is okay, can the connection and log it.

Or just drop the packets and wait till the amount of them has gone back to normal. So if it's real lag it will resolv itself after a few moments. If it's a hack the player get's the exact opposite of what he intended, because he stopped moving instead of moving faster than allowed.

You could also try to smooth out the amount of packets, so the player still moves but not faster than normal. For example, if you can normally send 4 packets per second (I don't know the real numbers) and the player suddenly sends 40 of them only use one packet, drop all packets until a time of 0.25 ms has passed, then process the next incoming packet and wait again 0.25 ms until you process the next incoming packet, and so on.

In both ways the attempt to do Speedhacking by flooding the server with packets won't do any good for the player, while normal lag shouldn't do too much harm.

[Sydius]

Don’t satellite connections group packets together and send them in bursts?... Such as system as this might be death for such people. However, I could have been lied to/remembered wrong.

[Sydius]

Almost simple solution: add a variable to players called "last walk time" which is sat every time a player moves. Then, add a variable "process time" to all packets, which is sat, upon receipt, to the current time. Then, only process packets that have a "process time” equal or less than the current time. If a walk packet is processed, but it has not been long enough since the last walk, reset the packet’s “process time” to the appropriate time, when it will be acceptable, and push it back into the front of the packet queue.

Assuming there is a seperate packet queue for each player, of course.

[giwo]

At the moment there is no packet queue. We just pull them off the socket buffer as they are received (and send them out in the same manner). Considerations on packet order and timing were why I was thinking of creating a packet queue as discussed here

[Sydius]

Sounds like a great idea to me, so long as you have a separate queue for each client.

[Grimson]

Sounds like a great idea to me, so long as you have a separate queue for each client.

Yes, if you only have one queue for all clients it would also be possible to lag all other clients by eigther flooding or increasing the response time on packets.