You can find the open-source demo and updated save game guide here: github.com/gdquest-demos/godot-demos-2022/tree/main/save-game In the next video, we'll share a simple trick to optimize your 2D. Stay tuned!
@@PatrickChoi bump means "bring up my post". on sites where things are filtered by recent or top comments, it brings the post to the top of the list so more people see it. so dwikbtn5984 is just trying to have a new comment notification sent to GDquest about the demo download link being broken
@@swishfish8858 "Don't reward people's failures". Talking like the comment is saying: "Ohhh thank you so much for teaching us wrong." Obviously they are "rewarding" the correction.
@@asdaaaaaaaaaaaaaasd If someone is wrong, they are wrong. It doesn't matter if they admit it or not. Being a wrong teacher makes you a bad teacher. Period.
@@swishfish8858 I won't push this subject more since you're seeing what you want to see, so this is my last reply. In the rest of your life dear Swish Fish, you are going to be wrong 100% this is going to happen. No one is an anime or a movie character in this world we live. And at that point you'll see how wise and hard it is to admit and CORRECT what you did wrong. Such a shame we get scared of being wrong in such things as knowing something.
With this logic, every programming teacher would be a bad teacher then. Programming is so complex every single programmer makes mistakes. As for this very topic, the thing is for some people this kind of relative user security is very important, but in reality no user is safe the moment they download files from untrusted sources. The best you can do is mitigate the issue. Some companies don't even try, for example Minecraft mods can run arbitrary code - they get shared and downloaded a lot more than save games.
Becareful with XML as that could lead to what is known as the Billion Laughs or XXE if you are doing server side stuff. JSON is far more safe if that's the route you want to go down.
Well it's not really the dev's fault if it turns out to have malicious code embedded inside it. Plug-ins to avoid this issue aside, I'd rather trade a vulnerability for ease of use
@@arcanine_enjoyer it's absolutely your fault for allowing your software to have a massive exploit in it, it's extremely negligent if you are selling that as a product. Users should never have to worry about save files being filled with malware
I save my game data as serialized binary data. It's a hassle to impliment all of that with read and write but it's security and file size is top notch.
Yea JSON/XML are intended for human readable/editable data, such as for game modding. They have no buisness in savegame files which should be UN-editable by nature and need to be as size efficient as possible for storage and loading.
@@ofulgor this is late, but there's not really a turorial because custom binary serialization will be different for every project. You basically just have to save bytes in a specific order with specific rules then make sure you can reconstruct the data from bytes with the reverse order and rules.
@@kennethferland5579 tbf save file size is not an issue unless you're saving a crazy amount of data or a crazy amount of savegames. Unless you're saving every user's data to a central database then save file size is a non-issue for modern computers. A large save file is megabytes and people wont blink twice at that on their PC.
Safe is relative, anyone downloading a saved game from a random website always has the possibility of it having a virus. I'm not saying that we shouldn't take preventative measures to make sure our code is safer for the end user, but at some point, it is the end user's responsibility.
I was wondering why people were stressing over compromised save data when the game itself or script in pakfiles could be compromised. I overlooked that people might share save data. Thanks for clearing that up for me!
That's not true at all, a .txt file cannot just be malware by itself. It only becomes malware when a badly made program (your game) reads that text and then executes arbitrary code. If you write a proper save system like every responsible gamedev does then the save file can only execute very specific code in the game which can never put malware onto your PC.
Godot should have some sort of security system that allows you to disable file operations, maybe a project setting or whatnot atm it's extra dangerous with multiplayer At least a way for the project to check if a script contains File related stuff, allowing you to prevent loading of resources that do
There are functions that are secure by default bytes2var and var2bytes, as mentioned in the video, and you would use those to send data over the network. But yeah it'd be cool if resources had a safe mode in the future because right now this issue affects even ConfigFile.
Data permissions have been a thing at the OS level for at least 50 years. There's no reason Godot shouldn't be able to say "Load this resource, but treat it as data and ignore all functions/code" the same way I can set the permissions flags of a file in Linux to 666 to make it non-executable.
It won't be much of changes since memory vulnerability is much more complex than you may have envisioned (this type of bug is nothing new, and we are dealing with this all the time) Dealing with binaries in native way won't gonna have practical security no matter how hard you have tried to protect it.
It would be nice if you could disable scripts in resources like that, and just make it easier to write safe code and easier to read. Or even if you could disable certain callbakc functions like _init, _ready, _process or _physics_process.
In this video mostly for compatibility with the previous one. In general, for the structured data and full autocompletion + type support throughout my codebase, though you could use plain Reference instances for that then.
XML-Injection is a very common security risk. I don't know how complete is the XML interpreter on Godot, but if it has half the features XML usually has it can very well do things like code execution, code injection, downloads, etc. Stick to JSON.
How would it do code execution in ways that don't also apply to JSON? I've never used XML, I thought it was just a method of formatting data to be read like JSON?
Well, to make things more precise, your previous approach was perfectly fine for locally saved games. If a hacker has access to the saved games, it means they could simply alter the game's scripts too by editing the pck's content or the binary manually. Some already hacked Sonic Colors Ultimate using this technique. So there's not really a security increase here. This new approach makes more sense if you have to upload the saved game to a server, but the server will still have to check itself if the received JSON is using the expected format anyway. I guess JSON is a little bit easier to parse than Godot resource files but, theoretically, it should not be impossible to parse and verify a sent Godot .tres file. So in the end, I think your previous method was perfectly fine. The new one maybe makes it a little bit more complex to inject code in the game, but it does not increase security in a significant manner IMO. It's basically the equivalent of local save game encryption, as it "obfuscates" things a little bit but won't stop anyone determined enough to hack your game.
Even if it's local, people can share save files online. Sure, you shouldn't download files from people you don't trust, but people will. People will assume that save files will be safe to download.
It's because some people care very much about players having the ability to e.g. share a save file and download it from an untrusted source safely. Basically that's the case the video covers.
@@kevinscales it's reasonable to assume save files are safe, just like downloading any .txt from the internet. It's negligent to let your software turn a .txt into arbitrary code with zero warning about potential consequences. VSCode is a tool for professionals and it has lots of warnings and safety features regarding ACE. A tool for regular consumers should really just have none of those vulnerabilities at all.
This reminds me of how the machine learning community is using Python pickle files to distribute neural networks. Python pickle files may hold malicious code. It is a bad practice and you should use inert formats like JSON instead.
It's funny how this happened and the open source community had to create methods to verify pickles just because math nerds working on ML don't understand security.
Yeah, the risks are the same but you can't do much about it. Minecraft mods let you write any Java code so there's 0 security there. Skyrim mods have some protection but there have been exploits, and if the mod comes with an installer, well the installer can do anything. Generally speaking, as soon as players download files from the web, it is unsafe. With the savegame thing, the truth is if someone wants, they can share an executable and say "hey to put this save in the game, double click the file."
@@Gdquest what if we make a custom loader that just takes set variable values (isnt this just possible with JSON) that way no code can be executed right?
@@RenderingUserthat is what I personnally do. JSON files for conversatios with even some custom code when parsed and ini files for the rest of the 90% of the config. You do indeed need to make some custom loaders.
@@RenderingUser You can do that but in that case modders might have a problem with the limited capabilities your loader would have. Let's say you made a platformer game and enabled modders to add blocks with custom textures and given them the option to set some variables for the player when being touched. If a modder wanted to add guns for whatever reason they still wouldn't be able to do so. The same goes for Minecraft mods: While you can create a datapack to run some ingame commands you still can't add such things as keybinds. Every system that doesn't allow you to completely modify the game's code has some limitations some modder will have trouble with.
Yes, this is a design feature of the engine. Resource files are used in the editor and are supposed to be powerful. You should never give that power to the user.
Also note You can use .res or .tres files .res will put the data into unreadable in a text file but data that it uses .tres will put the data into readable data in a text file I think use tres for things you dont care about being edited, or while debugging/testing/building the game maybe change it to .res when you are sharing a build/version of the game Maybe have code that lets you just change one line that will affect all of them to be tres or res so you dont have to go through updating .tres or .res in your code just do it one time, to easily swap back and forth. Maybe even save the .tres and .res files in different folders or something to make it easy to make sure you have no .tres files in your shared projects so people cannot edit the data. This is just a thought!
Isn't the whole point of this video that you SHOULDN'T use .tres or .res, since you can put arbitrary code into them? Imagine sharing a save file on the internet and it has malicious code in it.
I dont usually comment on YT, but saving is a massive thing to figure out how to do and on the last project I started, I tried a thing and seemed to be successful on it. for this project I save on godot by generating a JSON file with the variables of the script I wanna save. example: # generating array with the variables: const baseFilePath = "res://SaveData/" var file_name = "res://SaveData/slot1" var data := {} var s_slot := 1 func save(): for v in globals.get_script().get_script_property_list(): saveData(v.name, globals.get(v.name)) # (globals being the script I'm pulling from) # then on the saveData function it goes: func saveData(variableName, value): var dir = Directory.new() dir.remove("res://SaveData/slot" + str(s_slot)) data[variableName] = value var file = File.new() file.open(file_name,File.WRITE) file.store_string(to_json(data)) file.close() # probably not the most elegant way to do it, doesnt even encrypt the data, but it seems to work. # This passes the current values to the savefile and it is easy to add more variables later in development, since it is grabbing everything from the script. # And then to load I search the variables of the "in game" script on the json file with: func loadData(): var file = File.new() if file.file_exists(file_name): file.open(file_name, File.READ) var savefileData = parse_json(file.get_as_text()) file.close() if typeof(savefileData) == TYPE_DICTIONARY: data = savefileData for v in globals.get_script().get_script_property_list(): var name = v.name globals.set(name, data[name]) print(globals.inventory) get_tree().paused = false globals.load_room(data.room, str2var(data.position), str2var(data.rotation)) # And with that, we never add new code to the game script, as it will search for the immutable internal names ignoring anything that is not part of those names. Once the load_room(), that is basically a change_scene with some extra oomph, runs, the level is loaded, the position/rotation of the player is set and all the global variables (ie. health, ammo, already picked up objects) are set to their loaded values as globals is a singleton. # doing this way, I assume, takes out the risk of having extra code injected while remaining simple and modular, instead of referencing every value I wanna save by hand. # sorry for the long comment, jsut wanted to share the way I go about doing this process. # if there are any exploits with this way of doing the safe file, please let me know.
2 solutions popped into my head while watching the video. 1. If saving in a text format rather than binary, first open the save file as text rather than with the ResourceLoader. Scan it for malicious keywords (like func!) so no dangerous code can be executed. Some method of filtering the types allowed would be welcome though (like banning Callables in Godot 4). 2. Generate a key for the save file and make sure you get the same key on load, preferably in a compiled language so nobody can figure out what goes into it exactly. The raw contents of the file from that key onwards would play a part in addition to manually putting together many different variables. The downside is that, outside of small edits to stats that can be easily calculated by the user, tampering with save files is impossible this way. But downloading existing saves is no problem.
the second solution is called a checksum, if people wanna search it out. To be noted that this will not prevent people from sharing complete save files ; this kind of issue is unavoidable unfortunately, but at least, one cannot partially edit their files, because it will fail the checksum.
The checksum might not be completely safe if users can decompile your game and see how it's generated. And if it's simple, they could reverse engineer it just by looking at a number of save files and their associated checksum value.
Unity (technically c#, but I found that this issue is most common in Unity) has this issue too with the BinaryFormatter class. There are some pretty big games (untitled goose sim for example) that had issues with RCE.
Two questions: 1. Is the issue concerning only for saving files online (eg for multiplayer games)? 2. Isn't the json file easily editable by the player? How can we make it unreadable to prevent the player from cheating the game changing the values in the json save file?
Make the Game Server feed a new JSON file with the proper variables to the Game Console at the start of the game. So if anybody tries to tweak the variables, they will get overwritten at the start of the game. From there, just use streaming game play data. I use and/or bitwise operators and enumerators to keep the game state to be described in a single integer. The only other data that needs to be sent are coordinates, Game Console IDs, and Character IDs.
Glad you corrected this, I saw your other video, goes to show you though that you can't just follower what you see on YT. There are other YTers one comes to mind more vividly whose argument was "Godot does it so this is the intended way." You can and will hit the same issue with var_to_file if you are including code there. In my saves I serialize all my data into a dictionary and just var to file that without including objects. This way he information must be de-serialized for that layer of safety.
Yes, but you know that the downside of JSON and XML is that they're human-readable text format... so anyone in this instance can open it up in any text editor and therefore cheat / hack the game... While when the binary format is used, the less amount of people can modify it and also harder it is...
You could also encrypt, binary or simple encryption are easy to bypass but they're very simple and will prevent most players from editing the saves, if you really mind that. All you have to do is call File.open_encrypted() instead of File.open() to load and write the data.
@@alabvix Everyone is tryna protect their own work (models, scripts, ...) if one can... There is absolutely no guarantee that those protective measures make the game unhackable, but it keeps 3/4 of the snooping people out.. The ones who have skill, knowledge and the will to crack / hack something will do it, despite the security measures that the game has..
@@andrewpozenel2931 yeah man, I got your point. I was thinking in terms of my current project, a very specific one when we won't have security requiriments. So, I think a best way can be create a lib for encrypt/decrypt data for Godot, but probably someone already did this or think about. Anyway, have a great day man!
To save in json or xml, which are local text files, still does not prevent players to unlock paid content they did not paid for. If you make a game with online community/monetary features, I would suggest to save your data in a remote database. Also, I think it would be nice to highlight the cases where it is okay to save/load locally with godot’s solution (offline game, or even simple multiplayer games with no community/monetary aspect). In these sort of games, only the player can modify their save files, and it only affect their own experience. As soon as you have online community feature, shops and monetary reward, you would need to save your data in a database.
Yup, but regarding something like paid content, that's less an issue with _how_ data is saved and more with _where_ data is saved. You can still use JSON or XML or whichever format you'd like for saving data, but the key part is that the data _must_ be saved remotely, like you mentioned.
@@jacobpipers Encrypted by the client. Nothing is stopping you from writing you own JSON, encrypting it with the same format and replacing your save file. He's right, nothing is safe as long as it's on the user's computer. The only way is to use a database. In the case of paid content, you'll also need to make sure to avoid including the paid content in the base game and only download it from your servers as needed. It's a common flaw in games, especially Unity-made games which can be easily decompiled and DLCs can be unlocked this way. For a solo game with trading between players like Diablo 3 used to work, you basically need the game to be always online even if it's a solo game. Every action needs to be validated by your server, to avoid clients cheating in their sessions and breaking the market. That's why it was strange seeing people complaining about Diablo 3 being always online for a solo game, because that's the only way to do it
I have a save workflow that looks like the following: - Get save data using inst2dict(). - Convert using var2str() on debug builds, or var2bytes() on release - Save to a regular text file on debug (it will not be a JSON, but will easily be readable like one) or an encrypted data file on release To load, you just need to get the file data, convert it back to a dictionary and return it with inst2dict(). With inst2dict, you don't need to manually modify the base dictionary everytime
now if only there was an API that supports Godot's native type serialization, disallows objects by default, and comes with support for encryption as an extra. :) imho File (store_var and get_var) is generally the most suitable API for savegame serialization and I am surprised it's not being mentioned. I wouldn't recommend JSON or XML unless you need to interface with external applications/servers.
Thanks, I just didn't know there was the option to prevent object parsing with File.get_var. It's good to know. At least that way you can directly store and get vectors and whatnot. I hope we get the option to serialize object fields without code at some point too!
Neat. I'm a noob, so low-level basics like this are a bit confusing to me. Two questions: 1) Does using "File.store_var" and ".get_var" effectively render Resources and JSON irrelevant for saving data in single-player games? 2) Do statically-typed equivalents like ".get_64" and such have the same security benefits as ".get_var"?
@@redthepencilmonster7011 1) Not entirely, as store_var doesn't produce something that is human readable. You may want curious players to be able to manually edit save files (or you may specifically NOT want that. Up to you) 2) Yes, those are fully safe
@@L4Vo5 Thanks for the reply. If this is the case, why don't the docs indicate "allow_objects = false" by default for statically-typed variants? Is it because they thought that this would be self-evident, or because there's actually no need for such a safeguard with static types? Excuse my ignorance (^_^;)
@@redthepencilmonster7011 It's because there's no need. get_var doesn't immediately know what kind of variable it's getting, so it has to also get the variable's type from the file itself. Since it could be any type, there's a safeguard in case it's an Object (which could have code). Meanwhile, get_64 knows it will only ever get an integer. An integer can't be an object or have code of its own. The docs even say that the function reads exactly 64 bits and interprets them as an integer. Meaning, at no point does it "ask" the file what type the variable is, like get_var does. You could be reading complete meaningless garbage, but you will never get anything out of it that isn't an integer. So there's no danger in that case, and the idea of "decoding an object" or "storing code" doesn't even make sense.
I don't convert my dictionary data to anything other than JSON. I load the dictionary into an autoload script, and use the data from that for the entire game. Since it is always available, it saves and retrieves the game configuration across all the menus, and is available during game play. This way, any variable that needs to be configurable can be placed in the dictionary/JSON file and be changed through menus, or by power users who want to tweak the game using JSON. I have two types of network data; High Security Authentication, and minimized unsecured game play streaming data. The game play data can be considered somewhat secure, because using bitwise and/or operators (and enumerators to see what is going on) I can put 64 data members in a single integer. So game play data could be a list, or dictionary, with few floating point numbers for coordinates, an integer to describe the character/game state, and an id to find the character in the game.
I wonder if it’s possible to override the resource saver/loader to include a key for encrypting the save file and then decrypt it using that key. If you have your game generate a local key and then the save is created with that key, then in theory you shouldn’t be able to open the new file as the keys won’t match (I’m oversimplifying). At any rate I prefer the resource approach over json. I may have to look at whether this key idea holds water or not. ;)
I'd prefer using resources too. Not sure if this would work. I would rather add a safeguard to prevent loading any resource that has code or loads another resource: open the tres file first at text and ensure there's no pattern suggesting code in there. _init, or one of the script resources. Something like that. I'm just not sure if this is 100% safe so couldn't recommend it in the video.
Im not sure but i think godot has a way to encrypt files by using an encryption key as a string, you can make a personal encryption key so the save file can only be decrypted with the user computer generated key, the only thing would be making key generator complex enough to not repeat keys which with external tools can be easily done, also saving the key somewhere where cannot be changed or exposed
Hackers could always get the crypto keys that are hardcoded or generated. Unless you have it talk to a server that generates the key so the client, the game, has no idea what the key is.
@@NihongoWakannai sure, but can they figure out how you “properly” hid that in code? After a while. But is it worth the effort to do so? Maybe not for the average user of your game. The same logic applies to putting security in your house. It will deter most who wouldnt bother and some of the more opportunistic only theft. But for the determined ones, security of ANY form is inconsequential to their end goals.
Not yet, this video and updated demo are just out. I need to think about it. We will at least explain the caveats in the lessons but I´d rather not complicate things for students there. Note that we have plans to eventually replace some series, so this needs some thoughts.
Hi! I'm using the ResourceSaver to save the game. Then I copy the content using the File.open_encrypted_with_pass to encrypt the content. Anyone knows if I can be hacked that way? Thanks!
What you could do is open the file as text before loading it with the resource loader and ensure there's no _init function or embedded code resource or that it tries to load an external file you don't recognize. If you see anything indicating code, then you return and don't load the save. That'd be one way to at least have a simple protection, but I can't say if it doesn´t leave the door open to any potential exploits or whatnot.
I now have made a frankenstein solution with this... I have whole objects as binary in my JSON dictionary, where it was too tedious to unwrap. Those could also be injected with malicious code. But I encrypt the save file with unique user passwords so it should be alright.
Do you mean can you load resources safely now? No, but you can search the asset store for "Godot Safe Resource Loader". I haven't tested it myself but the plugin author is very reliable.
@@Gdquest Godotneers' (creator of said plugin) video on the subject of saving/loading was so thorough! I loved it. He doesn't promise 100% that the Safe Resource Loader is impossible to circumvent, just that he doesn't know a way to do so yet
Is there a sane/safe method of supporting mods for the game? I mean exposing some interface of the game, allowing modders to use Godot to create new logic (because why not facilitate already existing tool) and then (safely) loading the mod? I guess if we only limit ourselves to data-driven approach then I guess we can always use json, but we lose scriptability.
Mods can never be 100% safe because players download and share them on the web. Regardless of your data format, anyone malicious can make an executable claiming to make mods easy to install and put malware in it. On your side, you could mitigate that in two ways: 1. If you want to safeguard programming, you can code sandboxed programming tools, like the event sheets in RPG maker. It's quite a bit of work and it will limit modders, so it's a tradeoff. 2. You could have an official repository of whitelisted mods. Then it means you need to review every mod update and ensure no malicious code is included. Something like the nexus websites for the elder scrolls. But it's never 100% safe either.
The only way to make mods safe is by pre-defining code in your game and then letting modders only call those pre-defined code blocks. Any mod where you allow arbitrary code is inherently unsafe and you're best just giving a warning popup when users load a mod.
Resources initially were intended to be used inside Godot projects, and not for external save files or as a format to exchange files. Someone could probably contribute this feature and it'd be welcome.
How would you make the main playerdata resource file that everything like position and all that would be written and loadable? having hella issues with it not wanting to write anything and someone told me id have to look into it, but im just not understanding anything at all bc most videos i come across all of that is already made and it just goes to creating the save resource. plz help
For game saves, you probably want to use some binary format with basic encryption or at least encoding, so it won't be that easily user modifiable as editing JSON file using notepad. But for loading and saving your config file, this tutorial is a great example!
Why is it a problem if a player wants to hack their own save? As long as they're not giving themselves competitive advantages in multiplayer (i.e., hacking themselves the best weapons or exploiting stat calcs that save the stat instead of doing/checking the math on load), why should the devs get to tell the players how they're allowed to have or bypass fun?
The easier is to change something the more chances it will be changed by the user. And the more changes they'll make outside - the less they'll want to grind it ingame. Think about it this way - giving player an ability to change their stats straight inside a game. The game will be much fun? Very doubtful. Storing those stats in the JSON document is barely different.
@@anispinner I still fail to see how it's the devs' job to stop the player from modifying their game in single-player, though. If somebody, especially on a third or fourth playthrough, wants to give themselves the best weapons in the game against the first boss, or remove some forced upgrades as part of a challenge run, or set impossible combinations of story flags to see how the game reacts, who are the devs to say "No! You can only have fun the way we WANT you to have fun!" It's one of the reasons Nintendo doesn't make games as good as they used to: They got so focused on intended fun that overall fun got caught in the crossfire. Also, what about unlockables? If you play a game at a friend's house and unlock, say, a secret character on their file, why not unlock it on yours too? Sometimes save files corrupt, or cloud saves get reverted and set your progress back. Who are the devs to say I have to have the starting roster again or go back to level 3 when I was in the last world? Technological ability != moral right.
I'm not sure whether you still reply to old videos, but here's the thing though: If you need to save textures and the kinds, the resource method is the only way to do it no? You could save the textures as images in a path and then save the path, but that's soooo hacky and weird.
Isn't easier to just change the format that the resource is written to disk? Kinda similar to what you did with the JSON layer, but using the resource directly without worrying about that extra layer
It's the act of loading resources that causes the code to run, not the details of the file format or extension themselves, so that wouldn't work considering that Godot runs code when loading resources right now.
@@Gdquest I mean, you can use ResourceFormat* to do exactly the same as what you did on the video, I wanted to know if doing that is easier than writting an extra loader/saver step
This is so pointless. Security for save game files does not matter one tiniest bit. As with any file... ANY FILE, don't download it/open/use it unless you trust the source... that goes for plain text/scripts/json/xml/etc... does not matter. The only thing that matters is where the file came from and do you trust the source. You can save a game in ANY format. It does not matter. It could be a python script. It does not matter. Civ6 uses a sqlite db to save their games... "oh no, but sqlite dbs can contain executable code" so what? It doesn't matter what the save file format is or whether or not it has executable code. The format in which a game is saved DOES NOT MATTER (when it comes to security). What matters is where you get the files you allow onto your computer and that goes for ANY FILE. This is so moot. It's really frustrating that even programmers don't really know anything about security.
Do you know a way to save InputEvents using json? As in user-defined keybinds? Most people suggest using a resource but this exploit seems very under-reported
For user-defined key bindings, the risk would not be relevant. People have to download a malicious file and manually replace it in their copy of the game for a risk to exist. Also note there is a small plugin you can use to mitigate the issue when loading resources if you prefer. If you want to save anything using JSON you have to convert the Godot data to a dictionary that you can then convert from and to JSON.
That's not much more protection against someone with bad intentions. You can always easily find the encryption key, decrypt the save data, inject the code, encrypt again, and put it online.
I don't understand, this seems more like an issue for players who are downloading weird programs/save files from sketchy websites, rather than an problem on the developer end? Like, your average indie gamedev isn't going to have the scenario of their game infecting players' computers if they simply don't hide a virus inside the game?
It’s a pretty common trend to share save files for Sandbox games like Minecraft. UA-camrs share their saves all the time, and many people wrongfully trust youtubers they’ve followed for a long time. But if you insist that it needs to be the developer’s problem to warrant fixing it, asking a player for their save file is a common and very effective way to diagnose and fix bugs. I hope you don’t adopt this same mindset when developing multiplayer games. Having players pass around resources is a great way to get hacked, and it all happens automatically.
I already expected this to happen, since Godot is written in C++, which, by default, has no memory security built-in in mind. Dealing with binaries in native will eventually leads to vulnerability if the source of the file is untrusted. (Godot already put side notes on this but people rarely pay attention on it, including many of famous Godot tutorial makers), and it's also part of reason that Godot suggest saving files in standardised/human-readable formats (like, JSON) rather than this type of "easy" way, although it's not the best way to do it.
It was too good to be true😂 When I saw your video on saving with resources I was so happy I dont have to use File class anymore but I guess Ill stick with that method.
you can use an encryption/ decryption key its build in godot ... for singleplayer games its the user decision ... for multiplayer you can store the key on a server ... and fe bind it to a steam account that way its pretty hard to change anything
You should probably take the other video down. It's still recommended and some people are still using it without reading the description for the link to this video.
Would you perhaps be open to doing a video on saves with encryption? There's not a ton of videos/helpful and clear guides on it for Godot and it's really good for say helping deter people from cheating or giving themselves steam achievements etc. so I think a lot of people could benefit from it~ ^-^
Good video! But honestly, if the vulnerability as I understand it is that only people who are downloading saves from online are at risk then to my mind that's an end-user problem. You can't walk through a minefield and pretend you won't step on one. That said, I might be misunderstanding the issue and I think an online or multiplayer game would have much more risk than say a singleplayer offline game and would be worth investing much more time and effort into security. In any case I respect you putting a correction video out and you got a subscriber!
You have a point there. However, users that don't have in-depth IT knowledge might receive the save game from a "friend" and just drop it in their app data folder without opening it to check if it contains harmful code. In the end, it's going to be your game that gets the bad reputation. So considering this is time well spent in my opinion! 😉
Same problem if you use the resource loader, but I think it's mentioned in the video that the built-in var2bytes and bytes2var functions are safe by default.
Not at all, it will be very easy for someone to notice that you're using this loading method and then create malware which targets your users. Gamers don't expect save files to be anything more than a data file, so they will trust random files from the internet and then get malware because you allowed ACE in your save file loading. For hobby projects it's fine, but don't sell a commercial product with an ACE exploit like this. You're just putting your customers at risk.
LOL, someone yelled at me in the Godot discord for telling them to save gamestate with JSON because it'll be more interoperable with whatever they may want to do in the future. Do I post this video there?
They might've watched the original GDQuest video about this in the first place. At this point I think Resource and its ilk should be forbidden to be saved to/loaded from user://.
I say let people edit their savefiles in single player games. Too much energy is put in to stopping people from cheating when there are very simple ways to get around it ALL. If they are motivated enough to find the save file, they will be motivated enough to download Cheat Engine. To me, once the game is in a player's hands, it is theirs to do what they please with. If cheating makes it more fun for them, great! Why should I care? When devs make a big deal about it it feels like Big Brother is mad you aren't playing his game the way he wants.
Thats just stupid. In your opinion its equally unsafe to use a text file as using resources, where you can execute malicious code? You could literally install a trojan via Resources. A text file cannot.
6 місяців тому
@@jumpsneak give me legal consent to infect your computer and I'll send you a txt file
@@jumpsneak "A text file cannot" It's very easy to disguise one type of file as another. What you think is a text file, can actually be an executable. SQL / HTML injections, for instance, are hacks starting with just a few lines of text entered by a malicious user (not even a file needed, just some input). Some cellphones could also be hacked with a simple message. If you download and open a file from the internet, there's always a risk, no whatever what it is. It's up to the user to be careful, 100% security simply doesn't exist with computers.
@@Neptas Of course, anything could be somehow used as an Injektion, but that is up to the Implementation to be Injektion proof. The problem with resources is that godot just executes those no matter the implementation (of the dev), so a fix to the godot engine to disable such execution would prevent such an injection. When using self made text files for storing you are at least able to make your own code and make it injection proof. The same way as SQL Injektion are prevented
My God, you still have it wrong. Your default data management is crap. You need a global game state structure. That should include chapter/level/scene, narrative path, resources/achievements/weapons/inventory, character class/stats/position/action, interactable objects status, maybe enemy/npc stats/spawning positions. Some of these can reset on load - not important on game save/load. All of these should be reset for a separate play trough (new game), some may be random seed generated. The exact storage system needs to be compatible with the target system: A database (or a whole load of servers, or cloud provider) for multiplayer hosted games, or whatever Mac OS, Android, Switch, Playstation expects (windows is a mess - use what's easiest, linux expect some sort of file in the user/home path). I know Android apps are generally expected to tie the save states to a google account. Online games need to process state on the server and save it with an account system and into a database. There's no going around it. On the client you just get display and sound playback and send input. Make sure you figure out what is an object or action in the world and needs to be on the server, and what is an effect (that lives on the client). For game prototypes and game jams use whatever you can get away with - csv, resources(serialized objects are indeed dangerous if your game revives functions), json. I expect the minimal single player commercial game to save system settings in whatever is simpler, and game state to either json or sqlite or a custom binary format.
This is already possible with the File class, which allows you to write text and binary files with any structure. There's also built-in support for compression and/or encryption. It's less convenient to use the File class compared to custom resources, but it's more flexible and likely allows for tighter data packing in certain circumstances.
@@Calinou you theoretically can use in-memory Resource object, but serialize and encrypt it. But I'm usually using C# in Godot, so in my case it's better to write just classes that handle it
@@Calinou To add to Calinou's answer, you can use var2bytes to instantly convert, say, entire dictionaries to binary, and bytes2var to do it the other way around. By default, this function prevents serializing objects (e.g. resources) so it doesn't have the same issues as resources or other similar functions (var2str for instance).
You should remove your previous video - it's outright dangerous to spread the old information and there's no guarantee everyone who clicks on the old one will make their way to this video
Actually the previous way is OK too, it's not that dangerous. In truth, there's no absolute safety the moment players download files online, so I'm making this mostly for the people for whom it's really important.
You can find the open-source demo and updated save game guide here: github.com/gdquest-demos/godot-demos-2022/tree/main/save-game
In the next video, we'll share a simple trick to optimize your 2D. Stay tuned!
Hi, the page doesn't work anymore, is there a new version?`thanks!
@@PatrickChoi bump
@@dwikbtn5984 what do you mean haha
@@PatrickChoi bump means "bring up my post". on sites where things are filtered by recent or top comments, it brings the post to the top of the list so more people see it. so dwikbtn5984 is just trying to have a new comment notification sent to GDquest about the demo download link being broken
Its really cool when people recognise their mistakes makes me like this channel even more
Disagree, teachers making such big mistakes makes me more wary of trusting them. Don't reward people's failures.
@@swishfish8858 "Don't reward people's failures". Talking like the comment is saying: "Ohhh thank you so much for teaching us wrong." Obviously they are "rewarding" the correction.
@@asdaaaaaaaaaaaaaasd If someone is wrong, they are wrong. It doesn't matter if they admit it or not. Being a wrong teacher makes you a bad teacher. Period.
@@swishfish8858 I won't push this subject more since you're seeing what you want to see, so this is my last reply. In the rest of your life dear Swish Fish, you are going to be wrong 100% this is going to happen. No one is an anime or a movie character in this world we live. And at that point you'll see how wise and hard it is to admit and CORRECT what you did wrong. Such a shame we get scared of being wrong in such things as knowing something.
With this logic, every programming teacher would be a bad teacher then. Programming is so complex every single programmer makes mistakes.
As for this very topic, the thing is for some people this kind of relative user security is very important, but in reality no user is safe the moment they download files from untrusted sources. The best you can do is mitigate the issue. Some companies don't even try, for example Minecraft mods can run arbitrary code - they get shared and downloaded a lot more than save games.
Becareful with XML as that could lead to what is known as the Billion Laughs or XXE if you are doing server side stuff. JSON is far more safe if that's the route you want to go down.
Me : stores save data in Json
Everyone : bad idea, bad practice, use resources
Me now : *overexagerated air of superiority*
Same
how do you store objects in JSON? I'm struggling with this
@@Chspas you can't. Depending on what you need, you can find workarounds.
Well it's not really the dev's fault if it turns out to have malicious code embedded inside it. Plug-ins to avoid this issue aside, I'd rather trade a vulnerability for ease of use
@@arcanine_enjoyer it's absolutely your fault for allowing your software to have a massive exploit in it, it's extremely negligent if you are selling that as a product.
Users should never have to worry about save files being filled with malware
I save my game data as serialized binary data. It's a hassle to impliment all of that with read and write but it's security and file size is top notch.
Do you have a link to a tutorial or something?
would love to know how you do it!
Yea JSON/XML are intended for human readable/editable data, such as for game modding. They have no buisness in savegame files which should be UN-editable by nature and need to be as size efficient as possible for storage and loading.
@@ofulgor this is late, but there's not really a turorial because custom binary serialization will be different for every project.
You basically just have to save bytes in a specific order with specific rules then make sure you can reconstruct the data from bytes with the reverse order and rules.
@@kennethferland5579 tbf save file size is not an issue unless you're saving a crazy amount of data or a crazy amount of savegames.
Unless you're saving every user's data to a central database then save file size is a non-issue for modern computers. A large save file is megabytes and people wont blink twice at that on their PC.
Safe is relative, anyone downloading a saved game from a random website always has the possibility of it having a virus. I'm not saying that we shouldn't take preventative measures to make sure our code is safer for the end user, but at some point, it is the end user's responsibility.
I was wondering why people were stressing over compromised save data when the game itself or script in pakfiles could be compromised. I overlooked that people might share save data. Thanks for clearing that up for me!
That's not true at all, a .txt file cannot just be malware by itself. It only becomes malware when a badly made program (your game) reads that text and then executes arbitrary code.
If you write a proper save system like every responsible gamedev does then the save file can only execute very specific code in the game which can never put malware onto your PC.
Godot should have some sort of security system that allows you to disable file operations, maybe a project setting or whatnot
atm it's extra dangerous with multiplayer
At least a way for the project to check if a script contains File related stuff, allowing you to prevent loading of resources that do
There are functions that are secure by default bytes2var and var2bytes, as mentioned in the video, and you would use those to send data over the network.
But yeah it'd be cool if resources had a safe mode in the future because right now this issue affects even ConfigFile.
Data permissions have been a thing at the OS level for at least 50 years. There's no reason Godot shouldn't be able to say "Load this resource, but treat it as data and ignore all functions/code" the same way I can set the permissions flags of a file in Linux to 666 to make it non-executable.
It won't be much of changes since memory vulnerability is much more complex than you may have envisioned (this type of bug is nothing new, and we are dealing with this all the time) Dealing with binaries in native way won't gonna have practical security no matter how hard you have tried to protect it.
It would be nice if you could disable scripts in resources like that, and just make it easier to write safe code and easier to read. Or even if you could disable certain callbakc functions like _init, _ready, _process or _physics_process.
If you save ends up dictionary, what's the point using resource?
Why not use dictionary from begin to end?
In this video mostly for compatibility with the previous one. In general, for the structured data and full autocompletion + type support throughout my codebase, though you could use plain Reference instances for that then.
XML-Injection is a very common security risk. I don't know how complete is the XML interpreter on Godot, but if it has half the features XML usually has it can very well do things like code execution, code injection, downloads, etc.
Stick to JSON.
How would it do code execution in ways that don't also apply to JSON? I've never used XML, I thought it was just a method of formatting data to be read like JSON?
Well, to make things more precise, your previous approach was perfectly fine for locally saved games. If a hacker has access to the saved games, it means they could simply alter the game's scripts too by editing the pck's content or the binary manually. Some already hacked Sonic Colors Ultimate using this technique. So there's not really a security increase here.
This new approach makes more sense if you have to upload the saved game to a server, but the server will still have to check itself if the received JSON is using the expected format anyway. I guess JSON is a little bit easier to parse than Godot resource files but, theoretically, it should not be impossible to parse and verify a sent Godot .tres file.
So in the end, I think your previous method was perfectly fine. The new one maybe makes it a little bit more complex to inject code in the game, but it does not increase security in a significant manner IMO. It's basically the equivalent of local save game encryption, as it "obfuscates" things a little bit but won't stop anyone determined enough to hack your game.
Even if it's local, people can share save files online. Sure, you shouldn't download files from people you don't trust, but people will. People will assume that save files will be safe to download.
It's because some people care very much about players having the ability to e.g. share a save file and download it from an untrusted source safely. Basically that's the case the video covers.
@@kevinscales it's reasonable to assume save files are safe, just like downloading any .txt from the internet. It's negligent to let your software turn a .txt into arbitrary code with zero warning about potential consequences.
VSCode is a tool for professionals and it has lots of warnings and safety features regarding ACE. A tool for regular consumers should really just have none of those vulnerabilities at all.
This reminds me of how the machine learning community is using Python pickle files to distribute neural networks. Python pickle files may hold malicious code. It is a bad practice and you should use inert formats like JSON instead.
It's funny how this happened and the open source community had to create methods to verify pickles just because math nerds working on ML don't understand security.
With this in mind. How would you go about letting users mod your game with resources? Is there the same risk?
Yeah, the risks are the same but you can't do much about it. Minecraft mods let you write any Java code so there's 0 security there. Skyrim mods have some protection but there have been exploits, and if the mod comes with an installer, well the installer can do anything.
Generally speaking, as soon as players download files from the web, it is unsafe. With the savegame thing, the truth is if someone wants, they can share an executable and say "hey to put this save in the game, double click the file."
@@Gdquest what if we make a custom loader that just takes set variable values (isnt this just possible with JSON)
that way no code can be executed
right?
@@RenderingUserthat is what I personnally do. JSON files for conversatios with even some custom code when parsed and ini files for the rest of the 90% of the config. You do indeed need to make some custom loaders.
@@RenderingUser You can do that but in that case modders might have a problem with the limited capabilities your loader would have.
Let's say you made a platformer game and enabled modders to add blocks with custom textures and given them the option to set some variables for the player when being touched. If a modder wanted to add guns for whatever reason they still wouldn't be able to do so.
The same goes for Minecraft mods: While you can create a datapack to run some ingame commands you still can't add such things as keybinds. Every system that doesn't allow you to completely modify the game's code has some limitations some modder will have trouble with.
@@underscore-dash I'm not making a game large enough to mod anyway
Any updates on this? Are resources still unsafe?
Hey! Thanks for this. Do you know if it is still a problem in Godot4?
I was asking myself the same thing.
I was able to replicate in 4.2.1 just now after copying the code from the video into a resource I had been testing saving data to.
Yes, this is a design feature of the engine. Resource files are used in the editor and are supposed to be powerful. You should never give that power to the user.
Also note
You can use .res or .tres files
.res will put the data into unreadable in a text file but data that it uses
.tres will put the data into readable data in a text file
I think use tres for things you dont care about being edited, or while debugging/testing/building the game
maybe change it to .res when you are sharing a build/version of the game
Maybe have code that lets you just change one line that will affect all of them to be tres or res so you dont have to go through updating .tres or .res in your code just do it one time, to easily swap back and forth.
Maybe even save the .tres and .res files in different folders or something to make it easy to make sure you have no .tres files in your shared projects so people cannot edit the data.
This is just a thought!
Isn't the whole point of this video that you SHOULDN'T use .tres or .res, since you can put arbitrary code into them? Imagine sharing a save file on the internet and it has malicious code in it.
I dont usually comment on YT, but saving is a massive thing to figure out how to do and on the last project I started, I tried a thing and seemed to be successful on it.
for this project I save on godot by generating a JSON file with the variables of the script I wanna save.
example:
# generating array with the variables:
const baseFilePath = "res://SaveData/"
var file_name = "res://SaveData/slot1"
var data := {}
var s_slot := 1
func save():
for v in globals.get_script().get_script_property_list():
saveData(v.name, globals.get(v.name))
# (globals being the script I'm pulling from)
# then on the saveData function it goes:
func saveData(variableName, value):
var dir = Directory.new()
dir.remove("res://SaveData/slot" + str(s_slot))
data[variableName] = value
var file = File.new()
file.open(file_name,File.WRITE)
file.store_string(to_json(data))
file.close()
# probably not the most elegant way to do it, doesnt even encrypt the data, but it seems to work.
# This passes the current values to the savefile and it is easy to add more variables later in development, since it is grabbing everything from the script.
# And then to load I search the variables of the "in game" script on the json file with:
func loadData():
var file = File.new()
if file.file_exists(file_name):
file.open(file_name, File.READ)
var savefileData = parse_json(file.get_as_text())
file.close()
if typeof(savefileData) == TYPE_DICTIONARY:
data = savefileData
for v in globals.get_script().get_script_property_list():
var name = v.name
globals.set(name, data[name])
print(globals.inventory)
get_tree().paused = false
globals.load_room(data.room, str2var(data.position), str2var(data.rotation))
# And with that, we never add new code to the game script, as it will search for the immutable internal names ignoring anything that is not part of those names. Once the load_room(), that is basically a change_scene with some extra oomph, runs, the level is loaded, the position/rotation of the player is set and all the global variables (ie. health, ammo, already picked up objects) are set to their loaded values as globals is a singleton.
# doing this way, I assume, takes out the risk of having extra code injected while remaining simple and modular, instead of referencing every value I wanna save by hand.
# sorry for the long comment, jsut wanted to share the way I go about doing this process.
# if there are any exploits with this way of doing the safe file, please let me know.
Thanks for sharing!
2 solutions popped into my head while watching the video.
1. If saving in a text format rather than binary, first open the save file as text rather than with the ResourceLoader. Scan it for malicious keywords (like func!) so no dangerous code can be executed. Some method of filtering the types allowed would be welcome though (like banning Callables in Godot 4).
2. Generate a key for the save file and make sure you get the same key on load, preferably in a compiled language so nobody can figure out what goes into it exactly. The raw contents of the file from that key onwards would play a part in addition to manually putting together many different variables.
The downside is that, outside of small edits to stats that can be easily calculated by the user, tampering with save files is impossible this way. But downloading existing saves is no problem.
the second solution is called a checksum, if people wanna search it out. To be noted that this will not prevent people from sharing complete save files ; this kind of issue is unavoidable unfortunately, but at least, one cannot partially edit their files, because it will fail the checksum.
The checksum might not be completely safe if users can decompile your game and see how it's generated.
And if it's simple, they could reverse engineer it just by looking at a number of save files and their associated checksum value.
Unity (technically c#, but I found that this issue is most common in Unity) has this issue too with the BinaryFormatter class. There are some pretty big games (untitled goose sim for example) that had issues with RCE.
interesting
why not hashing the scripts and not load the resource if there is a mismatching script?
Two questions:
1. Is the issue concerning only for saving files online (eg for multiplayer games)?
2. Isn't the json file easily editable by the player? How can we make it unreadable to prevent the player from cheating the game changing the values in the json save file?
Make the Game Server feed a new JSON file with the proper variables to the Game Console at the start of the game. So if anybody tries to tweak the variables, they will get overwritten at the start of the game. From there, just use streaming game play data. I use and/or bitwise operators and enumerators to keep the game state to be described in a single integer. The only other data that needs to be sent are coordinates, Game Console IDs, and Character IDs.
" Reference " class was renamed to " RefCounted " in Godot 4
Glad you corrected this, I saw your other video, goes to show you though that you can't just follower what you see on YT. There are other YTers one comes to mind more vividly whose argument was "Godot does it so this is the intended way."
You can and will hit the same issue with var_to_file if you are including code there.
In my saves I serialize all my data into a dictionary and just var to file that without including objects. This way he information must be de-serialized for that layer of safety.
How can we access the save game demo these days? The link in the description leads to a 404 error
Do we have to do this for Godot 4 as well?
Yes, but you know that the downside of JSON and XML is that they're human-readable text format... so anyone in this instance can open it up in any text editor and therefore cheat / hack the game... While when the binary format is used, the less amount of people can modify it and also harder it is...
You could also encrypt, binary or simple encryption are easy to bypass but they're very simple and will prevent most players from editing the saves, if you really mind that.
All you have to do is call File.open_encrypted() instead of File.open() to load and write the data.
@@Gdquest isn't that method removed
Yeah, but what is the point to hack a game that you are trying to beat? If the player wants to do that, for me is fine.
@@alabvix Everyone is tryna protect their own work (models, scripts, ...) if one can... There is absolutely no guarantee that those protective measures make the game unhackable, but it keeps 3/4 of the snooping people out.. The ones who have skill, knowledge and the will to crack / hack something will do it, despite the security measures that the game has..
@@andrewpozenel2931 yeah man, I got your point. I was thinking in terms of my current project, a very specific one when we won't have security requiriments. So, I think a best way can be create a lib for encrypt/decrypt data for Godot, but probably someone already did this or think about. Anyway, have a great day man!
To save in json or xml, which are local text files, still does not prevent players to unlock paid content they did not paid for. If you make a game with online community/monetary features, I would suggest to save your data in a remote database. Also, I think it would be nice to highlight the cases where it is okay to save/load locally with godot’s solution (offline game, or even simple multiplayer games with no community/monetary aspect). In these sort of games, only the player can modify their save files, and it only affect their own experience. As soon as you have online community feature, shops and monetary reward, you would need to save your data in a database.
json can be encrypt the json file.
Yup, but regarding something like paid content, that's less an issue with _how_ data is saved and more with _where_ data is saved.
You can still use JSON or XML or whichever format you'd like for saving data, but the key part is that the data _must_ be saved remotely, like you mentioned.
@@jacobpipers Encrypted by the client. Nothing is stopping you from writing you own JSON, encrypting it with the same format and replacing your save file. He's right, nothing is safe as long as it's on the user's computer. The only way is to use a database.
In the case of paid content, you'll also need to make sure to avoid including the paid content in the base game and only download it from your servers as needed.
It's a common flaw in games, especially Unity-made games which can be easily decompiled and DLCs can be unlocked this way.
For a solo game with trading between players like Diablo 3 used to work, you basically need the game to be always online even if it's a solo game. Every action needs to be validated by your server, to avoid clients cheating in their sessions and breaking the market. That's why it was strange seeing people complaining about Diablo 3 being always online for a solo game, because that's the only way to do it
@@HansFriedrich532 How ironic that a "DLC" which literarly means "DownLoadable Content" is shipped with a game and only unlocked via a purchase.
Godot has the inst2dict() and dict2inst(), which are able to convert Objects into Dictionary and vice-versa, are they good to use in saves?
I have a save workflow that looks like the following:
- Get save data using inst2dict().
- Convert using var2str() on debug builds, or var2bytes() on release
- Save to a regular text file on debug (it will not be a JSON, but will easily be readable like one) or an encrypted data file on release
To load, you just need to get the file data, convert it back to a dictionary and return it with inst2dict().
With inst2dict, you don't need to manually modify the base dictionary everytime
Since var2bytes disallows objects, I believe it's possible to check if the instance dictionary is trying to load some malicious script.
I'm curious if this vulnerability still exists in godot 4.x?
A but late but how does this make Config Files vulnerable?
now if only there was an API that supports Godot's native type serialization, disallows objects by default, and comes with support for encryption as an extra. :)
imho File (store_var and get_var) is generally the most suitable API for savegame serialization and I am surprised it's not being mentioned.
I wouldn't recommend JSON or XML unless you need to interface with external applications/servers.
Thanks, I just didn't know there was the option to prevent object parsing with File.get_var. It's good to know. At least that way you can directly store and get vectors and whatnot.
I hope we get the option to serialize object fields without code at some point too!
Neat. I'm a noob, so low-level basics like this are a bit confusing to me. Two questions:
1) Does using "File.store_var" and ".get_var" effectively render Resources and JSON irrelevant for saving data in single-player games?
2) Do statically-typed equivalents like ".get_64" and such have the same security benefits as ".get_var"?
@@redthepencilmonster7011 1) Not entirely, as store_var doesn't produce something that is human readable. You may want curious players to be able to manually edit save files (or you may specifically NOT want that. Up to you)
2) Yes, those are fully safe
@@L4Vo5 Thanks for the reply. If this is the case, why don't the docs indicate "allow_objects = false" by default for statically-typed variants? Is it because they thought that this would be self-evident, or because there's actually no need for such a safeguard with static types? Excuse my ignorance (^_^;)
@@redthepencilmonster7011 It's because there's no need. get_var doesn't immediately know what kind of variable it's getting, so it has to also get the variable's type from the file itself. Since it could be any type, there's a safeguard in case it's an Object (which could have code).
Meanwhile, get_64 knows it will only ever get an integer. An integer can't be an object or have code of its own. The docs even say that the function reads exactly 64 bits and interprets them as an integer. Meaning, at no point does it "ask" the file what type the variable is, like get_var does. You could be reading complete meaningless garbage, but you will never get anything out of it that isn't an integer.
So there's no danger in that case, and the idea of "decoding an object" or "storing code" doesn't even make sense.
I somehow managed to search for this channel 55 seconds after it uploaded lol
there is no way to make saving/loading method with resources secure?
Have you found an answer to this?
I don't convert my dictionary data to anything other than JSON. I load the dictionary into an autoload script, and use the data from that for the entire game. Since it is always available, it saves and retrieves the game configuration across all the menus, and is available during game play. This way, any variable that needs to be configurable can be placed in the dictionary/JSON file and be changed through menus, or by power users who want to tweak the game using JSON. I have two types of network data; High Security Authentication, and minimized unsecured game play streaming data. The game play data can be considered somewhat secure, because using bitwise and/or operators (and enumerators to see what is going on) I can put 64 data members in a single integer. So game play data could be a list, or dictionary, with few floating point numbers for coordinates, an integer to describe the character/game state, and an id to find the character in the game.
I wonder if it’s possible to override the resource saver/loader to include a key for encrypting the save file and then decrypt it using that key. If you have your game generate a local key and then the save is created with that key, then in theory you shouldn’t be able to open the new file as the keys won’t match (I’m oversimplifying). At any rate I prefer the resource approach over json. I may have to look at whether this key idea holds water or not. ;)
I'd prefer using resources too. Not sure if this would work. I would rather add a safeguard to prevent loading any resource that has code or loads another resource: open the tres file first at text and ensure there's no pattern suggesting code in there. _init, or one of the script resources. Something like that. I'm just not sure if this is 100% safe so couldn't recommend it in the video.
Im not sure but i think godot has a way to encrypt files by using an encryption key as a string, you can make a personal encryption key so the save file can only be decrypted with the user computer generated key, the only thing would be making key generator complex enough to not repeat keys which with external tools can be easily done, also saving the key somewhere where cannot be changed or exposed
Hackers could always get the crypto keys that are hardcoded or generated. Unless you have it talk to a server that generates the key so the client, the game, has no idea what the key is.
People can decompile your game and see how to encrypt and decrypt files.
@@NihongoWakannai sure, but can they figure out how you “properly” hid that in code? After a while. But is it worth the effort to do so? Maybe not for the average user of your game. The same logic applies to putting security in your house. It will deter most who wouldnt bother and some of the more opportunistic only theft. But for the determined ones, security of ANY form is inconsequential to their end goals.
Is this 'correction' in the Kickstarter course?
Not yet, this video and updated demo are just out. I need to think about it. We will at least explain the caveats in the lessons but I´d rather not complicate things for students there. Note that we have plans to eventually replace some series, so this needs some thoughts.
Hi! I'm using the ResourceSaver to save the game. Then I copy the content using the File.open_encrypted_with_pass to encrypt the content. Anyone knows if I can be hacked that way? Thanks!
Someone could extract your encryption pass
What you could do is open the file as text before loading it with the resource loader and ensure there's no _init function or embedded code resource or that it tries to load an external file you don't recognize. If you see anything indicating code, then you return and don't load the save.
That'd be one way to at least have a simple protection, but I can't say if it doesn´t leave the door open to any potential exploits or whatnot.
How does Unity avoid this problem?
I now have made a frankenstein solution with this... I have whole objects as binary in my JSON dictionary, where it was too tedious to unwrap.
Those could also be injected with malicious code. But I encrypt the save file with unique user passwords so it should be alright.
The demo project no longer exists :( Can you reupload it? I was just starting to understand inventories and json!
So godot 4 us out, did they release that json+resource system?
Do you mean can you load resources safely now? No, but you can search the asset store for "Godot Safe Resource Loader". I haven't tested it myself but the plugin author is very reliable.
@@Gdquest Godotneers' (creator of said plugin) video on the subject of saving/loading was so thorough! I loved it. He doesn't promise 100% that the Safe Resource Loader is impossible to circumvent, just that he doesn't know a way to do so yet
There's a plugin that do security tests for saving. I think it's safe saving something like that
Is this still an issue in godot 4?
Yes, it's intentional design because resources aren't supposed to be used this way
Is there a sane/safe method of supporting mods for the game? I mean exposing some interface of the game, allowing modders to use Godot to create new logic (because why not facilitate already existing tool) and then (safely) loading the mod? I guess if we only limit ourselves to data-driven approach then I guess we can always use json, but we lose scriptability.
Mods can never be 100% safe because players download and share them on the web. Regardless of your data format, anyone malicious can make an executable claiming to make mods easy to install and put malware in it.
On your side, you could mitigate that in two ways:
1. If you want to safeguard programming, you can code sandboxed programming tools, like the event sheets in RPG maker. It's quite a bit of work and it will limit modders, so it's a tradeoff.
2. You could have an official repository of whitelisted mods. Then it means you need to review every mod update and ensure no malicious code is included. Something like the nexus websites for the elder scrolls. But it's never 100% safe either.
The only way to make mods safe is by pre-defining code in your game and then letting modders only call those pre-defined code blocks.
Any mod where you allow arbitrary code is inherently unsafe and you're best just giving a warning popup when users load a mod.
Why is there no option to just disable loading of scripts?
Resources initially were intended to be used inside Godot projects, and not for external save files or as a format to exchange files. Someone could probably contribute this feature and it'd be welcome.
Or disable it outside of res:// altogether, which might be the more secure route.
I almost hate to say it, but problems like this are why code signing was invented.
how is this any different than sharedPreferences?
Why is it necessary to to declare character = Character.new() again on line 65? Isn't it already declared at the beginning of the script?
If I want player to add custom images in the game can I use json to add the custom image
Or it’s better to use resources
How would you make the main playerdata resource file that everything like position and all that would be written and loadable? having hella issues with it not wanting to write anything and someone told me id have to look into it, but im just not understanding anything at all bc most videos i come across all of that is already made and it just goes to creating the save resource. plz help
For game saves, you probably want to use some binary format with basic encryption or at least encoding, so it won't be that easily user modifiable as editing JSON file using notepad. But for loading and saving your config file, this tutorial is a great example!
Why is it a problem if a player wants to hack their own save? As long as they're not giving themselves competitive advantages in multiplayer (i.e., hacking themselves the best weapons or exploiting stat calcs that save the stat instead of doing/checking the math on load), why should the devs get to tell the players how they're allowed to have or bypass fun?
The easier is to change something the more chances it will be changed by the user. And the more changes they'll make outside - the less they'll want to grind it ingame.
Think about it this way - giving player an ability to change their stats straight inside a game. The game will be much fun? Very doubtful. Storing those stats in the JSON document is barely different.
@@anispinner I still fail to see how it's the devs' job to stop the player from modifying their game in single-player, though. If somebody, especially on a third or fourth playthrough, wants to give themselves the best weapons in the game against the first boss, or remove some forced upgrades as part of a challenge run, or set impossible combinations of story flags to see how the game reacts, who are the devs to say "No! You can only have fun the way we WANT you to have fun!" It's one of the reasons Nintendo doesn't make games as good as they used to: They got so focused on intended fun that overall fun got caught in the crossfire.
Also, what about unlockables? If you play a game at a friend's house and unlock, say, a secret character on their file, why not unlock it on yours too? Sometimes save files corrupt, or cloud saves get reverted and set your progress back. Who are the devs to say I have to have the starting roster again or go back to level 3 when I was in the last world? Technological ability != moral right.
@@angolin9352 Cus they made the game, simple as that really. You can dislike it if you want, but that's really all there is to it.
I'm not sure whether you still reply to old videos, but here's the thing though:
If you need to save textures and the kinds, the resource method is the only way to do it no?
You could save the textures as images in a path and then save the path, but that's soooo hacky and weird.
Isn't easier to just change the format that the resource is written to disk? Kinda similar to what you did with the JSON layer, but using the resource directly without worrying about that extra layer
It's the act of loading resources that causes the code to run, not the details of the file format or extension themselves, so that wouldn't work considering that Godot runs code when loading resources right now.
@@Gdquest I mean, you can use ResourceFormat* to do exactly the same as what you did on the video, I wanted to know if doing that is easier than writting an extra loader/saver step
This is so pointless. Security for save game files does not matter one tiniest bit. As with any file... ANY FILE, don't download it/open/use it unless you trust the source... that goes for plain text/scripts/json/xml/etc... does not matter. The only thing that matters is where the file came from and do you trust the source. You can save a game in ANY format. It does not matter. It could be a python script. It does not matter. Civ6 uses a sqlite db to save their games... "oh no, but sqlite dbs can contain executable code" so what? It doesn't matter what the save file format is or whether or not it has executable code. The format in which a game is saved DOES NOT MATTER (when it comes to security). What matters is where you get the files you allow onto your computer and that goes for ANY FILE. This is so moot. It's really frustrating that even programmers don't really know anything about security.
Do you know a way to save InputEvents using json? As in user-defined keybinds?
Most people suggest using a resource but this exploit seems very under-reported
For user-defined key bindings, the risk would not be relevant. People have to download a malicious file and manually replace it in their copy of the game for a risk to exist. Also note there is a small plugin you can use to mitigate the issue when loading resources if you prefer.
If you want to save anything using JSON you have to convert the Godot data to a dictionary that you can then convert from and to JSON.
Godot InputMap actions (for user keybinds) will be saved in a project's override.cfg (this is the file that Godot uses to save project settings).
Can't the resource file be encrypted? If so there is not how to inject code but from the encripter itself.
That's not much more protection against someone with bad intentions. You can always easily find the encryption key, decrypt the save data, inject the code, encrypt again, and put it online.
Any example of maybe using Firebase to save your save data?
I don't understand, this seems more like an issue for players who are downloading weird programs/save files from sketchy websites, rather than an problem on the developer end? Like, your average indie gamedev isn't going to have the scenario of their game infecting players' computers if they simply don't hide a virus inside the game?
It’s a pretty common trend to share save files for Sandbox games like Minecraft. UA-camrs share their saves all the time, and many people wrongfully trust youtubers they’ve followed for a long time.
But if you insist that it needs to be the developer’s problem to warrant fixing it, asking a player for their save file is a common and very effective way to diagnose and fix bugs.
I hope you don’t adopt this same mindset when developing multiplayer games. Having players pass around resources is a great way to get hacked, and it all happens automatically.
but someone would have to modify the resource to insert a virus
Yes, this is only about save games people download from untrusted sources, as mentioned at the start of the video.
Very informative, thanks
i wish u deleted the other vid or linked to this one. i just wrote off JSON for no reason 😭
wow now ur explaining json to me thank you 😢
bro I was writing notes like "json = bad" lmao
ill still make custom files and file loaders for saves
I had no idea resources were capable of arbitrary code execution...Makes sense, though.
Hi
Pls how can I add animation my game(coding)
I would recommend googling or searching on UA-cam for animation in godot. I would also recommend researching the AnimationPlayer node
@@donatoclemente4421 ok thanks
I already expected this to happen, since Godot is written in C++, which, by default, has no memory security built-in in mind. Dealing with binaries in native will eventually leads to vulnerability if the source of the file is untrusted. (Godot already put side notes on this but people rarely pay attention on it, including many of famous Godot tutorial makers), and it's also part of reason that Godot suggest saving files in standardised/human-readable formats (like, JSON) rather than this type of "easy" way, although it's not the best way to do it.
guys please i need a way to make a voice typing in godot please
I'm glad this is happening.
Shouldn't it be possible to use resources as before but filter out everything but the safe stuff when loading it?
It was too good to be true😂
When I saw your video on saving with resources I was so happy I dont have to use File class anymore but I guess Ill stick with that method.
Thanks for sharing
still, players can access the json file and change the save file
you can use an encryption/ decryption key its build in godot ... for singleplayer games its the user decision ... for multiplayer you can store the key on a server ... and fe bind it to a steam account that way its pretty hard to change anything
You should probably take the other video down. It's still recommended and some people are still using it without reading the description for the link to this video.
Would you perhaps be open to doing a video on saves with encryption? There's not a ton of videos/helpful and clear guides on it for Godot and it's really good for say helping deter people from cheating or giving themselves steam achievements etc. so I think a lot of people could benefit from it~ ^-^
last video There is wrong way to do it. Json format used by many games. this video I was wrong. I research and find out using json is good
When you already built a whole game with resources:
Great video and good points made by everyone!
Good video! But honestly, if the vulnerability as I understand it is that only people who are downloading saves from online are at risk then to my mind that's an end-user problem.
You can't walk through a minefield and pretend you won't step on one.
That said, I might be misunderstanding the issue and I think an online or multiplayer game would have much more risk than say a singleplayer offline game and would be worth investing much more time and effort into security. In any case I respect you putting a correction video out and you got a subscriber!
You have a point there. However, users that don't have in-depth IT knowledge might receive the save game from a "friend" and just drop it in their app data folder without opening it to check if it contains harmful code. In the end, it's going to be your game that gets the bad reputation. So considering this is time well spent in my opinion! 😉
What about binary?
Same problem if you use the resource loader, but I think it's mentioned in the video that the built-in var2bytes and bytes2var functions are safe by default.
To err is human, and I think all of us here commend you for actually correcting yourself when needed. Great job!
How to save in godot:
Just press ctrl+S
simple.
yeah, i guess godot resources is not the best thing ever
C# users: this bullshit class doesnt even exist.
Don't waste your time.
in reality, for 99.999% of cases, this is too much paranoia
This isn't true. Arbitrary code execution is a very real threat (godot has full access to a computer, including the command line).
Not at all, it will be very easy for someone to notice that you're using this loading method and then create malware which targets your users. Gamers don't expect save files to be anything more than a data file, so they will trust random files from the internet and then get malware because you allowed ACE in your save file loading.
For hobby projects it's fine, but don't sell a commercial product with an ACE exploit like this. You're just putting your customers at risk.
LOL, someone yelled at me in the Godot discord for telling them to save gamestate with JSON because it'll be more interoperable with whatever they may want to do in the future. Do I post this video there?
They might've watched the original GDQuest video about this in the first place. At this point I think Resource and its ilk should be forbidden to be saved to/loaded from user://.
I say let people edit their savefiles in single player games. Too much energy is put in to stopping people from cheating when there are very simple ways to get around it ALL. If they are motivated enough to find the save file, they will be motivated enough to download Cheat Engine. To me, once the game is in a player's hands, it is theirs to do what they please with. If cheating makes it more fun for them, great! Why should I care? When devs make a big deal about it it feels like Big Brother is mad you aren't playing his game the way he wants.
did you not actually watch the video? the issue isn't cheating, it's arbitrary code execution
Any file can be malicious. I think this isn't a real reason to not use resources for saving
Thats just stupid. In your opinion its equally unsafe to use a text file as using resources, where you can execute malicious code? You could literally install a trojan via Resources. A text file cannot.
@@jumpsneak give me legal consent to infect your computer and I'll send you a txt file
No, any file cannot be malicious. If this were the case, the internet itself would be a hellscape, and would not be possible to browse safely.
@@jumpsneak "A text file cannot" It's very easy to disguise one type of file as another. What you think is a text file, can actually be an executable.
SQL / HTML injections, for instance, are hacks starting with just a few lines of text entered by a malicious user (not even a file needed, just some input). Some cellphones could also be hacked with a simple message.
If you download and open a file from the internet, there's always a risk, no whatever what it is. It's up to the user to be careful, 100% security simply doesn't exist with computers.
@@Neptas Of course, anything could be somehow used as an Injektion, but that is up to the Implementation to be Injektion proof. The problem with resources is that godot just executes those no matter the implementation (of the dev), so a fix to the godot engine to disable such execution would prevent such an injection. When using self made text files for storing you are at least able to make your own code and make it injection proof. The same way as SQL Injektion are prevented
My God, you still have it wrong. Your default data management is crap.
You need a global game state structure. That should include chapter/level/scene, narrative path, resources/achievements/weapons/inventory, character class/stats/position/action, interactable objects status, maybe enemy/npc stats/spawning positions. Some of these can reset on load - not important on game save/load. All of these should be reset for a separate play trough (new game), some may be random seed generated.
The exact storage system needs to be compatible with the target system: A database (or a whole load of servers, or cloud provider) for multiplayer hosted games, or whatever Mac OS, Android, Switch, Playstation expects (windows is a mess - use what's easiest, linux expect some sort of file in the user/home path). I know Android apps are generally expected to tie the save states to a google account.
Online games need to process state on the server and save it with an account system and into a database. There's no going around it. On the client you just get display and sound playback and send input. Make sure you figure out what is an object or action in the world and needs to be on the server, and what is an effect (that lives on the client).
For game prototypes and game jams use whatever you can get away with - csv, resources(serialized objects are indeed dangerous if your game revives functions), json.
I expect the minimal single player commercial game to save system settings in whatever is simpler, and game state to either json or sqlite or a custom binary format.
well, make your own tutorial vid on this then
If godot supported writing normal binary files without having to go through resources this wouldn't be an issue 🙄
I wonder if this would be do-able with the C# ver? I would assume so, although I've yet to move over from gdscript.
This is already possible with the File class, which allows you to write text and binary files with any structure. There's also built-in support for compression and/or encryption.
It's less convenient to use the File class compared to custom resources, but it's more flexible and likely allows for tighter data packing in certain circumstances.
I write binary saves all the time without Resources. Just File.store_*()
@@Calinou you theoretically can use in-memory Resource object, but serialize and encrypt it. But I'm usually using C# in Godot, so in my case it's better to write just classes that handle it
@@Calinou To add to Calinou's answer, you can use var2bytes to instantly convert, say, entire dictionaries to binary, and bytes2var to do it the other way around. By default, this function prevents serializing objects (e.g. resources) so it doesn't have the same issues as resources or other similar functions (var2str for instance).
Lost straight from the beginning. Make stuff more simplified, or explain what things are. You started off with json and im already done.
You should remove your previous video - it's outright dangerous to spread the old information and there's no guarantee everyone who clicks on the old one will make their way to this video
Actually the previous way is OK too, it's not that dangerous. In truth, there's no absolute safety the moment players download files online, so I'm making this mostly for the people for whom it's really important.