Multi-Box Temp Bans?

The server tells you what places you have available when you talk to the menu. They don't currently stop you warping to those places without access, but there's no reason they couldn't automatically parse all warps and detect every use of warping to a location you don't have. They don't need to collect anything from client, they just check the outgoing transmission that said what you had against the following incoming transmission saying where you're warping.

Server said you don't have a HP 1.5 sec before you warped to that home point? Done, easy.

Maybe people started rapidly using superwarp and pos hacking to make mules for reisenjima before DM campaign?

One thing to keep in mind whenever people are talking about "warping" is that there's no such thing as warping as far as the server is concerned. You are constantly sending the server a UDP packet with your current coordinates (X, Y, Z). Whenever you "warp" in-zone, what you're really doing is updating your current coordinates to some specific values and then sending those values to the server, typically resulting in your new coordinates having a significant delta (difference) from the previous set.

There's a good reason that they don't try to automatically prevent people from "warping". Let's say that you're in a zone and your current position is 0,0,0. If you start running forward in a straight line then maybe 20 seconds later you reach the coordinates 50,0,0. A typical interaction with the server would be you letting it know a few times every second that you've moved foward a little bit, 0,0,0 -> .5,0,0 -> 1,0,0 -> ... -> 50,0,0, etc., however, if you were to have any type of lag or packet loss then your coordinate updates might not be received until you were actually at the position 50,0,0 client side. It would be a terrible end user experience if the game prevented you from moving in that scenario, and they (probably) don't register that type of anomalous event either because it's a really, *really* common occurrence.

That isn't to say that they couldn't register and monitor that type of behavior, especially in scenarios where the new coordinates are significantly different from previously known coordinates to the point that they wouldn't typically be possible without altering the client side functionality. It's just that it's expensive to track coordinate deltas and it's not really an efficient or effective way to prevent cheating.

Doesn't the email sent when you get in trouble tell you why you were temp banned?

Edit: Surprisingly yes, see the images below.

Took me a bit of digging through old email accounts, but I thought I remembered it. If I can get this link to work....


Edit: Needless to say, I call B.S. on the OP thinking it was only because he was multi-boxing.

Generic Email, if you've never seen it:
I know that I was botting, but I was also clipping, out of bounds, running too fast, craft automating


It doesn't say which one they temped the account for etc They just say you broke rule 2.1 or 3.2 or the one for swearing, i forget the number.

MPKing
FINAL FANTASY XI User Agreement
3.2 Disruption. You may not in any way disrupt or interfere with the Game experience of other players, including the disruption of Square Enix's computers and servers.

"cheating"
FINAL FANTASY XI User Agreement
2.1 Cheating and Botting. You may not create or use any cheats, bots, automation software, hacks, mods or any other unauthorized software designed to modify the Game and gameplay. In addition, you may not take advantage of game system bugs and exploits during gameplay.

I'm really surprsied that they give you that much info, updated the post.

I remember back in like 2008, I got suspended like 4 times for trash talking. But they were all in increasingly longer increments. Starting only at 24 hours, eventually got a week long suspension for it and I finally shut my mouth.

actually, there's a packet requesting the server move you, then a response packet that does the movement

which is why it's a slight concern that superwarp is going to the wrong coordinates, it's not just reporting your position slightly off it's asking the server to warp you to a position that you cannot legitimately ask the server to warp you to

The client sends a run count to the server, so they can easily check if distance is greater than the run count allows(use squares instead of dividing it out for actual distances and the server cost is very low) and check if run count is greater than it should be for the amount of time since last packet. With legitimate lag, you'll have a run count to match and the actual time interval between packets will reflect the distance traveled.

I would absolutely not assume they cannot detect that.

I was thinking of Warper/POS warping rather than the sw/hp/etc warping. If this is true for basic movement then how do you move around when your internet connection dies temporarily?

How does that not trigger off of people dropping packets though?

Thought we were still on HPs/etc. You do report your position, but see my last post for why you shouldn't trust that the server can't track speed/warps.

Check 1: Check if run count is greater than time interval since last packet. If greater, it's been modified(don't trust the client). Single multiplication, low cost.

Check 2: Check if square of the x and y deltas is greater than (speed * run count) squared. Add 5-15% leeway to prevent false positives due to rounding. 3 more multiplications, 2 subtraction. No division. low cost.

A legitimate speedhack will get caught by this every time. Since an actual player will still have the client side run count updated while d/cing, when they finally resync with the server both their run count and time elapsed will allow them to pass both checks.

The other thing is, you don't have to trigger on one occurance. If someone is actually speedhacking, and you have automated detection, they're going to rack up hundreds of flags in a matter of hours. Someone lagging might be able to falsely accumulate one if they start d/cing while flee is on and it lasts longer than it should, but this is a very specific set of circumstances and they're not going to have the hundreds of flags an actual cheater will.

How does this take into account the fact that your movement speed varies with equipment and statuses? Speedhacks typically just modify the current movement speed variable in memory which already naturally differs if you have flee, crimson cuisses, etc. so how does the server know what value should be used in that scenario in less its keeping track of those variables on its own?

The server absolutely knows your speed. It's stored in yalms per second in client memory, and the server tells you how fast you're going every second or so. Likely all they have to do is a simple query to pull your current speed, already in the format they'd use for this calculation, from your char id. If they really wanted, since they have a ghetto tcp already built into their packet system, they could actually get the last speed your client received from them as well and prevent issues like the flee one I described.

The server has EVERY advantage, and it should not be this hard to explain that they can easily detect speedhacks and warp hacks.

I got my money on bidder as the ban reason, spamming AH is the only thing they actively are banning for.

Sans massive exploits changing the entire economy

The server knows what your speed *should* be, but I don't know how it would know what your current speed actually is without that value being sent in one of the outgoing packets, and if it's not currently being sent then they can't trust the run count which means that they need to rely on the delta calculation. Obviously that isn't terribly difficult but it does have a cost associated with it, both in the storing of previous values and the calculation, and it would be riddled with false positives unless they spent additional work hours to filter all of those out. It just seems very unlikely to me that they're actively trying to monitor and catch people out on speed when there are so many other areas that they can monitor more cheaply/easily and that wouldn't have probable deniability.

...it's pretty clear you're missing something here. Run count is a time based variable, not a distance based variable. If your speed is higher than it should be on client, that gets caught by the distance check.

The server doesn't need to know what your client speed is, they need to know what your actual speed is so they can check if you're going faster than you should be. They already know that, and it's readily available given they send it every 1s.

This is a matter of a couple hours of coding, tops, and will have no visible impact on server performance. I can explain it for you, but I can't understand it for you.

Your suggestion is that every time the server receives a packet that contains the current character coordinates it saves them, retrieves the previous coordinates, calculates the diff while ignoring factors like falling off the side of a cliff (or taking that into consideration which is even more unlikely), compares it against expected values based upon the time difference since the previous packet was received, and adds a flag that then gets compared against some magic threshold since you agree that false positives *can* occur. Sure.

yes

don't need to check vertical distance, 2d is much less costly and will still catch 99.99% as many cases, most zones have minimal vertical layering anyway


you want to make it sound complex, but it's not:

//check if run count from client is invalid, and flag if so
if (runcount > (runcountperunit * (time:now - lastpacketreceived) )) speedflags++;

else
{
//calculate square of distance traveled
val1 = currentx - lastx
val2 = currentz - lastz
val3 = val1 * val1 + val2 * val2
val4 = runcount * char->speed (add one more multiplication here if values aren't stored in format to directly multiply)

constant_value_tolerance = 1.10
max_dist = val4 * val4 * constant_value_tolerance

//Person traveled further than their speed allowed, they cheatin.
if (val3 > val4) speedflags++;
}
char->lastx = char->currentx;
char->lasty = char->currenty;
lastpacketreceived = time:now;

//don't do anything unless speed flags hit a certain number, this ensures that false positives don't matter, since this sort of check will quickly accumulate thousands of flags on actual speedhackers
if (speedflags > required_#) add_to_list_of_fuckers_to_ban

no division, costs next to nothing on cpu time, not rocket science. you obviously need access to the character object regardless when updating their positions, so little extra reference

or, if you don't want to take concept as good enough:

https://ffxiclopedia.fandom.com/wiki/Read_me

the ***'s been in the game since 2008 so it obviously exists or existed.. if you dig through the forums you'll find reports of people getting false positives for speed in the first month before they refined it

I appreciate the example and I agree that this could work if they make the constant_value_tolerance and required_# big enough but it still seems like it fails way too frequently using your example if you line it up with a real world scenario like constantly swapping in and out of crimson cuisses (1.18 modifier) in a Dynamis D zone (significant packet loss) while running around.

Good point.

You need to be continuously moving in a straight line to be potentially flagging this. If you're constantly swapping, you're likely engaged or standing still as a mage.

Further, the ghetto tcp system can actually check which speed the client last reported receiving anyway, if they really needed to.

That said, there's no reason you couldn't set the threshold to something like 500 flags in a day. Someone screwing around in dyna might pull up 20 or 30, but at 3 flags/second whenever running straight, a real speedhacker is still going to hit 500 in under 3 minutes.

A more practical implementation may only look at speeds in excess of 20%, 30%, whatever as well. I didn't start with that, because I don't want to falsely represent low speed hacks as safe, and they could still be detectable.

Fair enough, it doesn't seem too outlandish to have something like that in place. Adding some kind of current_speed check to a client packet always seemed like the most likely avenue of detection to me but I figured that if someone is running a program that alters their current move_speed var in memory then they could have it overwrite the related value in the outgoing packet as well.

funny you mention that, there's a flag for using maint mode in outgoing 0x15 and despite all sorts of tools having access to maint mode.. i haven't seen any public ones that correct the flag

if thread is shitty get to at least page 9 .exe

My guess is the name banhammer was offensive hence the ban.

There is a bigblackwoman on Asura which I guess is not offensive unless you are small black woman...or something !


https://www.ffxiah.com/player/Asura/Bigblackwoman