Exploiters datawiping my game

I don’t know what better category I could have put this in. Some players found a way to datawipe save slots in my game. My game is extremely small but maintains a small concurrent player count, and some players spend hours building realistic jets and other vehicles that my game is meant to create.

I do not know how these exploiters can even datawipe my game, cause most server scripts responding to remote events already check check if the player is saving data to their own userid or not.

Is there a good solution to this problem? I feel like I should go into the direction of loading version history of each player save slot until it finds a non-empty/corrupted version and loads that, but I do not know how I should implement that.

I’m sorry if this is extremely vauge, I need to go to school and I will be back to reply to questions.

2 Likes

Data versioning is good to use as a backup for if a save fails and you know that player has data, but it’s also costly (has much more strict limitations). While it’s hard to tell what the cause could be without seeing how your system works, the most common cause of this is unprotected remotes. You mentioned checking if the ID patches, but that doesn’t exactly sound like a system that’s even relevant in this particular case. I don’t know how your game is meant to work, so take this with a grain of salt, but generally you’ll want the server to handling saving automatically without needing user input, unless you want a manual save system.

3 Likes

The game allows players to save to different save slots, so manual saving is required.

1 Like

Just for general advice, and in this case too, a remote sent from the client should only include input. It shouldn’t include information. The remote for requesting a save should only say “I want to save to this slot”, and nothing else. The server would then receive the request and process it by figuring what what needs to be saved, and then saving it to the slot the player chose. Make sure the slot that’s being saved to is a slot owned by the player. Verification shouldn’t be needed, however, as the player should only have to say something like “Save to slot 1”, where the server can save to slot 1 of that player’s data.

In summary, the client should only provide basic input and the server should never need to rely on the client to give any information outside of input. An easy way to tell is to understand that anything the client sends can be edited. Nothing can be trusted on or from the client. So if you assume that the client is lying, make sure that the input from the client won’t cause any issues.

8 Likes

I think that could be true in your case, depends on your system.

Even if player has different slots to save that would be a table that can be saved when player leaves, or any other event, so it can be performed automatically without needing user input too

1 Like

Roblox has builtin data versioning with :ListVersionsAsync() and etc. So you can use that to un-wipe everything.

But for stopping it from happening in the future you should make players only send data that only the player has, all data that the server has should be used from the server. So clients can’t spoof anything. Like others have said.

For example:

Players should only be able to choose the slot. Not the full key used in the datastore (or something similar). Otherwise they can trick your check like they have probably done.

2 Likes

This could be hooked by the exploiter, but if its on the server then I prefer this method.

what game is it? mind sending a link? im gonna do some research on the exploit.

I have it private right now since I don’t want the exploiters causing mayhem. I have some devlogs about it but you will probably not get any good information about it.

While I sympathize with your issue, what you posted up is so general, no one is going to be able to help you solve the issue here. I know you aren’t going to post up pages of code for review, so your next best option is to find someone who is good with database coding or other stuff related to your game and that you trust to take a look at it. Ever since client/server games came out last century, you just can not trust clients for anything other than the strict rules you lay down in your game and what they are allowed to send. This isn’t a dig at you personally, but I read of lot of exploit topics here where all the code runs on the client and devs wonder why hackers are running rampant in their games. :sweat_smile:

Yeah. Early on in the development of the game, I made the client process stuff because the server faced lag issues. Now I am transferring all that stuff to be processed by the server.

I understand that I’ve barely given any description or detail. I’ve already reached out to a few developers for help, but they can’t. So far, I have been going in the right direction using the help from this forum though.

Thank you! Do you recommend that I add anything else to make sure stuff like this doesn’t happen?

Essentially, the server should be the side that takes care of networking/communication and secure data. The client should handle everything else (especially visuals). The server can’t be exploited while the client can, however there’s also only one server and multiple clients (so don’t make the server do anything that the clients can do themselves, but don’t let the client do something that would affect other players or secure data in any way).

Thanks. Also do you know anything about hopperbin exploits?

It’s been a little bit and I’ve realized a long time ago that the exploiting group was bluffing.

Pro tip: Don’t believe a random exploiter with no proof

2 Likes

wish i was told that 10 months ago :skull:

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.