One of the recent cheats is based on weapon-config exploit in raknet part of the script: damage system remembers every last onfoot packet data to rewrite the new packets when sync will be 'frozen' or to re-send last sync data to every streamed player for a few reasons. The exploit itself is in that a cheater can send the onfoot packet with some invalid values (like NaN position or invalid velocity etc) which will be dropped by the server but still be processed in sync handlers and read by weapon-config into s_LastSyncData array. Then, when the cheater will need to send this broken packet for everyone (in a stream zone at least), he will just abuse some event which call SendLastSyncPacket function. It can be anything, the easiest one is to send OnPlayerTakeDamage on yourself (so this will call UpdateHealthBar, then UpdateSyncData and then SendLastSyncPacket).
The fix is in that we rewrite s_LastSyncData array with newly received packet data only in OnPlayerUpdate. This way we ensure it was processed and validated by the server and wasn't dropped for any obviously invalid values.
One of the recent cheats is based on weapon-config exploit in raknet part of the script: damage system remembers every last onfoot packet data to rewrite the new packets when sync will be 'frozen' or to re-send last sync data to every streamed player for a few reasons. The exploit itself is in that a cheater can send the onfoot packet with some invalid values (like NaN position or invalid velocity etc) which will be dropped by the server but still be processed in sync handlers and read by weapon-config into
s_LastSyncDataarray. Then, when the cheater will need to send this broken packet for everyone (in a stream zone at least), he will just abuse some event which call SendLastSyncPacket function. It can be anything, the easiest one is to send OnPlayerTakeDamage on yourself (so this will call UpdateHealthBar, then UpdateSyncData and then SendLastSyncPacket).The fix is in that we rewrite
s_LastSyncDataarray with newly received packet data only in OnPlayerUpdate. This way we ensure it was processed and validated by the server and wasn't dropped for any obviously invalid values.