For the past month a “Desync” exploit has been spreading in my and other Roblox games that’s impossible to catch with any server-side checks due to it’s weird nature - the exploiter actually stays “in sync” with the server, but other clients observe a character that stays in one place essentially making the exploiter both invisible and invincible (in fighting games). I don’t use any exploiting software myself, but I’ve collected some data to share:
I also had a user show me this exploit in our game today. It has allowed him to abuse our bank robbing function, and shoot other players without being seen.
Tried reporting this numerous times for over a year. It’s an issue with networking that they refuse to address. First I was told Hyperion would solve this, then I was told the removal of fast flags would solve this. Now I am being told server authority will solve this. Yet the core issue has nothing to do with any of these, it has to do with how Roblox netcode allows a client to still somehow update their server-side position while blocking that position from replicating to other clients. @Bitdancer When will this be elevated to the networking team?
So this should no longer be possible with latest versions of Clients due to this change.
EDIT: I may be wrong about the above, since bad actors can still modify flags in memory, but not through local file editing.
Separately, because of Roblox’s Client-side nature of character physics players manipulating their outgoing packets can recreate the effect even without access to flags.
My understanding is that most shooters on Roblox do a “loose hit verification” that at least checks whether the character could have possibly have made the shot on the server at all (IE: Are they even in range of the enemy?) Does this game not use a similar pattern?
Long term, this is one of the things that Server Authoritative tech will help address more wholistically.
not the OP, but theyre describing it such that all the data is still passed to the server, however its not propagated correctly back to the clients—on the server, theyre moving around & are near players, but the actual clients dont see this. the OP mentioned that its impossible to detect serverside checks because of it, which is very spooky.
Client settings should only affect the Client’s simulation and the data they send to the Server. Other player characters are simply forwarded from the Server to other Clients, so what every other player should be seeing is what the server sees.
If there is an exploit that somehow makes the Server and OTHER Clients see different positions about their player Character, that would be very interesting and concerning beyond the initial “Roblox is Client Authoritative Player Physics”.
I don’t believe that I can easily repro it in studio, since I would need third party software to edit the fast flags now (i think). But I have also tested this in the game I work for with a friend who does penn testing. When he runs the script that loleris posted, it descyncs his client from the server, allowing him to move around the game, and interact with things just like if the server was actually replicating him. It’s bypassing the hit verification and other magnitude verifications we actually have in place.
In the server’s view, is the player character moving or not moving? This is my disconnect that I’m trying to understand.
In general networking manipulation like this still leaves your player character in the position where the character was desynced, meaning if on the server when the Client sends you a “I shot a gun and hit target X” event, you can try to validate whether it was possible or not at all based on the last updated position you had of the player that did the shooting, but on the server. My understanding is that egregious exploits like this would be avoided. (Roblox Laser Tag template does this)
Are you saying the games do that and this exploit is somehow bypassing them?
The exploit updates the position on the server, but somehow prevents the player’s position from replicating to other clients. For example, if your game has a ring in which you stand in to gain points. With this exploit you could trigger the desync, walk to the ring, stand in it, and gain points ‘invisibly’. The server sees you as in the ring, but all other clients see you as somewhere far away. You are moving on the server, it’s not the same as a lagswitch where the server receives no updates. Everything looks normal on the server side. The exploit prevents the server from replicating your position to all other clients
Games that also do hit detections on the client before validating them on the server won’t be able to detect the exploiter’s hitbox with this. Roblox Laser Tag does hit detections entirely on the server so it’s unaffected (although the exploiter is still invisible to others), but this usually isn’t an option for fast-paced games that are aiming for client responsiveness.
My guess is that there’s something in the server-to-client netcode that’s filtering out these ‘malformed’ packets but not the other way around, so the client can send their position to the server, but the server won’t replicate it back.
Hello, I’m also seeing this issue within multiple games I develop for. Keep in mind all the games I work on use completely server-sided hitboxes, so this issue means that the server does in fact see the player’s character moving but other clients do not.
Not sure why this was marked closed but apologies on our behalf: I re-opened it.
The fact that Servers seem to actually receive position updates, but they don’t forward them to other players seems to be a very new issue/unique issue. Thanks for for the extra update.
Trying to escalate this because an exploit like that should not be possible (if the server sees the updates they should be forwarded).
Okay wait, this is the piece that I was missing! Apologies, I didn’t click on this before because I got a little sketched out by a random google drive link and didn’t think to check if it were a video!
I can repro this, and this does seem to be a more serious bug that can’t just be solved with server-sided checks! Will escalate this!
This is true, but I’ve never seen exploited clients somehow tell the server to not replicate their position to other clients! Thanks for working on this issue.
No you’re good, I appreciate the info. I think that was on me because Google Drive usually gives you a preview that you can trust before you can download anything sketchy and I was being unreasonably paranoid.
Thanks for the back in forth on this topic, everyone. I was misunderstanding what the initial bug report was, but all the feedback and explanations everyone gave made it clear that it was a serious one to resolve ASAP.
and I was being unreasonably paranoid.