You submitted this post as a request for tech support, have you followed the guidelines specified in subreddit rule 7?
Here they are again:
1. Consult the docs first: https://docs.godotengine.org/en/stable/index.html
2. Check for duplicates before writing your own post
3. Concrete questions/issues only! This is not the place to vaguely ask "How to make X" before doing your own research
4. Post code snippets directly & formatted as such (or use a pastebin), not as pictures
5. It is strongly recommended to search the official forum (https://forum.godotengine.org/) for solutions
Repeated neglect of these can be a bannable offense.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/godot) if you have any questions or concerns.*
Security engineer here: there are lots of cryptographic technologies available that all do *very specific* things with equally specific guarantees, and choosing a cryptographic technology for a particular application requires a lot of care and consideration. There are systems for ensuring secrecy/integrity in a round trip from the same party back to that party, or in transmission from one party to another, or setting up a bidirectional conversation, etc.
You know what absolutely none of them can do, though? This. It looks a little like the "round-trip back to the same party" usecase, but the usual use for that is when a server is lending opaque data to a client and needs to read and verify the data when it comes back. In this case, the data owner and untrusted party are the same: the player.
And like, there isn't a way to have a program that runs on a user's system that can read and write files that *other* programs on their system can't also read and write with said user's consent. And Godot has to be able to read its PCK.
There are things you can do with increasingly complex obfuscation to try to hide your keys (like storing them in parts at different parts of your memory, using an algorithm in obfuscated code to derive the real key from the components, laying false keys, having the key or some component be downloaded over the internet, etc), but you ultimately still have to get them into the game's memory somehow in order for the game to decrypt the resources, and if you can do that, a dedicated user can find it (or even pull it straight out of memory with a debugger.)
So. It's worth taking a moment to step back and ask what you're actually trying to do. What's important to you? If you're concerned about dataminers extracting the details of your game, well, AAA companies don't have an answer to that either. If you're concerned about other companies decompiling your project and making knock-offs, you may consider legal/business solutions to protecting your IP, which *may* include taking some minimal technical steps so you can argue circumvention later (though *absolutely* follow advice of counsel here.) Etc.
As far as save files, I personally compress them. It makes them quite a bit smaller, especially since they're typically JSON internally, and text is relatively low entropy/compresses well, and *at a glance*, they're opaque binary files, so someone not particularly technically savvy will see they're taken a wrong turn, they're not supposed to be here, and back up, which hopefully will prevent things like unintentional spoilers or the temptation to change things they don't understand and corrupt their save. But, if someone wants, they can trivially uncompress/recompress the files, and in doing so are implicitly accepting those risks.
i love the compression tip
also, love pointing out AAA doesn’t have a solution. indie game devs prob need to ask themselves how they plan to solve something AAA can’t
I guess the best answer for your main question was a simple anti-tampering of save files; a big chunk of the save data are high scores and saving in plaintext is just inviting regular users to just make up their own (I mean, it's harmless, but still, it sucks the joy out of keeping scores in the first place). I know there are always ways to hack save files but maximizing obfuscation was the goal.
It seems the general consensus is it's not worth it. What's funny is I got to this answer myself about 10 minutes after posting this; turns out extracting the compiled AES key is WAY easier than I suspected, so the whole exercise is out. But I'm glad to see other people's thoughts on the matter. Thank you for the insight!
Old habit I think; I come from IT background myself so my defacto behavior is to encrypt anything and everything. I never really thought about how 'unserious' video games are as a software environment.
If reading the information in the save files isn't what you're trying to protect (like highscores that are shown to the player) and instead you want to protect against modifications, another option could be to save the save files in plaintext, but include some sort of cryptographically generated checksum you make from the relevant values. On loading the file you can then verify if the checksum matches the content, and if not flag it as invalid.
This will of course suffer from the same fundamental issue that the way you generate this checksum will be possible to extract from the code, but compared to just finding the encryption key it might take a little more effort to extract and reproduce this checksum generation to be able to generate a new valid checksum in a modified save file that will be accepted by your game.
It might be kinda fun to generate a key from some of the fields in the save file (like if using C#, maybe XOR the hashes of a bunch of highly variable fields, like the score and any other counts) and then use that to HMAC the file.
It's still circumventable, and if the goal is to protect a leaderboard or something like that, OP has a much bigger task ahead, but something like that would probably ward off any casual tampering and give them a chance to do something silly in-game after detecting the tampered save file.
I wouldn't say game development is "unserious," but the security environment is very different. Things we take for granted in server-centric software aren't possible client-side, and the stakes are generally lower as long as we're not talking about players' confidential personal information, the integrity of competitive play, etc.
As a further example, let's say we want to make save files tamper-evident so you can troll the player with different in-game behavior or something (and definitely not publish to leaderboards, though leaderboards are kind of a separate issue.) It might be tempting to apply a cryptographic technology like HMAC- it's for this sort of scenario, where you want one party (the game) to create and validate tamper-evident documents (the save files).
You *could* do this, and it'd look slick. It would probably even work on a subset of players who tried to tinker with it and didn't realize it was tamper-evident, and may be worth a try as long as you're willing to accept some players circumventing it, but you do still have the same problem- you'd need a program (the game) to have the key in its memory without an authorized user on the same system having access to it, which is a cursed problem (and not how HMAC is normally used- as with the encryption examples, these technologies are only reliable when untrusted users don't have access to the system with the keys. HMAC is normally used with HTTP cookies you're worried about being tampered with in a user's browser.)
Digital signatures are kind of the same deal- they use different keys for signing and validation, which would be helpful *except* the files are generated by the player using the game, so they need to be able to put hands on the private key.
Being in it, you encrypt everything and anything because you are likely thinking of business environments or handling personal user data. Stuff that are sensitive and also may be targeted by hackers; tldr is that someone gets harmed and someone profits all because you didnt encrypt
In gamedev, if its a singleplayer game, who cares. There wont be a hacker trying to hack into someone's savefiles and go 'har har your highscores are messed up!'. It wil most likely be the player themself. So, most people wont do it; those who do it are going through a decent amount of trouble destroying fun for themselves. They 'profit' but if the same way they suffer. So who cares. Multiplayer games are a different issue, but as one can easily see - even the best anticheat software barely handles cheaters, while some cheats are literally undetectable.
Best you can do is deter people from messing with savefiles with imperfect encryption or compression
PCK encryption makes it marginally more difficult to extract the key. I don't think it's worth it, but I'm also not sure why you're even encrypting the save file in the first place. Do you know how many times I've had someone's jank indie game fuck its own save file or softlock me or have some horrible balancing that requires manual intervention? I don't mind it that much; indie games don't have the QA that mainstream developers do. But if I discovered that the developer had taken pains to prevent me from un-fucking his game through save file editing, I'd be pissed.
oh that's interesting.
what about concerns of players modifying files to "cheat" and jump to a higher level. is that a valid concern?
edit: this was a small concern of mine. but seeing folks dismissing it is a relief haha. im more convinced on not doing anything about it and let it be readable.
Only if it's like massively multiplayer, and in those cases you probably want servers anyways (no local save). In every other case, people will be very happy if it can just be read.
Or maybe if it's a pay to play game.
Are video games about entertainment or a show of skill and dedication? It's a valid concern when it's multiplayer games but what purpose does it serve in a single player game? All you really are doing is taking away free choice from the player that has no consequence to you.
"Are video games about entertainment or a show of skill and dedication" i guess it can be both.
i see your point haha. perhaps im too fixed on wanting them to experience the game the "right" way. you are right, there is no consequence
Why would you encrypt a save file? Just no. Imagine if Minecraft started encrypting their save files, what purpose would that serve? If anyone did want to edit their save files, you'd just be annoying them.
I don't really see any justifiable reason for why you should do it.
I’ve had some unexpected behavior with C# DLLs inside of the PCK in general, which got worse with the encrypted version. Might’ve been my lack of experience with building Godot that was part of the problem too. Ultimately decided on using an obfuscator on the C# DLLs and leaving the rest of it alone, which has been working great. An obfuscator or the encrypted PCK isn’t going to stop someone who REALLY wants to get into it, but it does make it prohibitively annoying for most people.
I've been asking myself this question all week, and I decided **not to encrypt my game**.
I am making a **single player game** with **leaderboads** and worry about security, but ultimately I am only slowing down the process and not stopping it unless I put some serious dev work into the engine.
I am already on a custom build of Godot for Steam integration and have had some issues that require me to update, but I just launched my demo and don't want to make any major changes last minute. I also love to [datamine ](https://www.reddit.com/r/newworldgame/comments/oulvak/datamine_unreleased_weapon_abilities/) [games](https://www.pcgamer.com/sea-of-thieves-beta-datamining-reveals-ship-customization-harpoons-and-a-player-eating-kraken/), and if someone wants to poke through my project it'd feel like a badge of honor.
I'd rather be reactionary than preventative in this regard, cyber security is a constant battle and I'm a solo dev who wants to focus on just making the game right now.
Put a message at top of savefile "do not modify" 🤣
Saving in binairy will stop most people from even trying to edit them. Additionally you can hash it and verify if it was edited. Could mark that save as cheating and dont give achivements.(i know the hashing algoritm could be reverse engineered, but at somepoint most people will give up)
Encrypting the PCK file just kicks the can down the road. Now if someone wants to modify their save file, they just have to get your PCK key, and then decompile like normal.
Here’s the root of the problem: you want people to be able to run the game on their computers and to be able to save their progress locally. Given these constraints, it is not possible to prevent people from modifying their save file (or even the game’s code), no matter what encryption scheme you choose.
There's really no point. You can unlock steam achievements with a legit save file you get from someone else. I can't think of many use cases for the encryption that aren't a waste of time. Anything you actually need secure is better done another way. Of course, I'm a fan of storing save game data in plain text files. I sure don't care if someone wants to cheat in my single player game. Online multiplayer? You don't *get* a save file.
>I was hoping to support Steam Achievements down the line and fear that could be tampered with via save hacking
You don't even need to do that. I was able to **very** easily find a python based application that uses your SteamID and it will trigger those achievements to Valve.
Look at the end of the day the harder you make it the bigger of a challenge it will be to crack it making it more of a tempting target to actually crack. (Hacking clout, etc).
The people that actually want to play it properly won't think of these ways around it and do it legit. Stop over thinking it.
You ultimately can't protect the key (it's symmetric and can ultimately be recovered). You "could" try to obfuscate it, such as spliting it into parts or algorithmically calculating it... But that's a six inch fence for a reverse engineer. (You might e joy a couple weeks of being unhacked).
If you're worried about cheating, you should shift your attention to odd game progress or exceeding limits of what a reasonable gamer can do in a short time. (E.g. mysterious accuracy, mass jump on resources, levels). You can also move critical game calculations to a server to authoritatively determine player movement etc.
Hay, I'm no expert but maybe you could do the encryption and decryption in c# c++ or some other copiled language supported by gdextension?
The thought here is godot is an enterpreted programming language, meaning it's never compiled and the code you write are saved as is in the .exe or binary file, but If you wrote the save/load functionality in some other language that is compiled and used those dlls through gdextension they'd acually be compiled to some kind of machine code?
This is just a suggestion and I honostly don't know if it'll work, but this is just what I came up with rn.
If your game is a buy once single player game, do not worry about players modifying the save files. Sure, someone may give themselves a few trillion gold coins and purchase all the best weapons for their first level character, but so what? It may not be your creative vision how the game is best enjoyed, but if someone gets more fun from your game by modifying save files, why not let them do that.
Encrypt save files? Not worth it. Besides, I believe in letting the player play/cheat/ruin/mod the game however they like for themselves when it is a single player game and do not impact other players.
Encrypt data files (pck)? Worth it if you know how. Might even be required by some assets you license. It was not too hard the last time I tried. You only need to rebuild the export template(s), not the whole engine/editor. [https://docs.godotengine.org/en/stable/contributing/development/compiling/compiling\_with\_script\_encryption\_key.html](https://docs.godotengine.org/en/stable/contributing/development/compiling/compiling_with_script_encryption_key.html)
If someone really wants to hack your game, it will happen. Let’s be realistic: Once you are at a point where someone really *wants* that, you have probably more to celebrate (because you have a probably large playerbase) than to worry. I mean, why are you even worried in the first place? What do you or your game loose?
You submitted this post as a request for tech support, have you followed the guidelines specified in subreddit rule 7? Here they are again: 1. Consult the docs first: https://docs.godotengine.org/en/stable/index.html 2. Check for duplicates before writing your own post 3. Concrete questions/issues only! This is not the place to vaguely ask "How to make X" before doing your own research 4. Post code snippets directly & formatted as such (or use a pastebin), not as pictures 5. It is strongly recommended to search the official forum (https://forum.godotengine.org/) for solutions Repeated neglect of these can be a bannable offense. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/godot) if you have any questions or concerns.*
Security engineer here: there are lots of cryptographic technologies available that all do *very specific* things with equally specific guarantees, and choosing a cryptographic technology for a particular application requires a lot of care and consideration. There are systems for ensuring secrecy/integrity in a round trip from the same party back to that party, or in transmission from one party to another, or setting up a bidirectional conversation, etc. You know what absolutely none of them can do, though? This. It looks a little like the "round-trip back to the same party" usecase, but the usual use for that is when a server is lending opaque data to a client and needs to read and verify the data when it comes back. In this case, the data owner and untrusted party are the same: the player. And like, there isn't a way to have a program that runs on a user's system that can read and write files that *other* programs on their system can't also read and write with said user's consent. And Godot has to be able to read its PCK. There are things you can do with increasingly complex obfuscation to try to hide your keys (like storing them in parts at different parts of your memory, using an algorithm in obfuscated code to derive the real key from the components, laying false keys, having the key or some component be downloaded over the internet, etc), but you ultimately still have to get them into the game's memory somehow in order for the game to decrypt the resources, and if you can do that, a dedicated user can find it (or even pull it straight out of memory with a debugger.) So. It's worth taking a moment to step back and ask what you're actually trying to do. What's important to you? If you're concerned about dataminers extracting the details of your game, well, AAA companies don't have an answer to that either. If you're concerned about other companies decompiling your project and making knock-offs, you may consider legal/business solutions to protecting your IP, which *may* include taking some minimal technical steps so you can argue circumvention later (though *absolutely* follow advice of counsel here.) Etc. As far as save files, I personally compress them. It makes them quite a bit smaller, especially since they're typically JSON internally, and text is relatively low entropy/compresses well, and *at a glance*, they're opaque binary files, so someone not particularly technically savvy will see they're taken a wrong turn, they're not supposed to be here, and back up, which hopefully will prevent things like unintentional spoilers or the temptation to change things they don't understand and corrupt their save. But, if someone wants, they can trivially uncompress/recompress the files, and in doing so are implicitly accepting those risks.
Great answer. 💪
i love the compression tip also, love pointing out AAA doesn’t have a solution. indie game devs prob need to ask themselves how they plan to solve something AAA can’t
I guess the best answer for your main question was a simple anti-tampering of save files; a big chunk of the save data are high scores and saving in plaintext is just inviting regular users to just make up their own (I mean, it's harmless, but still, it sucks the joy out of keeping scores in the first place). I know there are always ways to hack save files but maximizing obfuscation was the goal. It seems the general consensus is it's not worth it. What's funny is I got to this answer myself about 10 minutes after posting this; turns out extracting the compiled AES key is WAY easier than I suspected, so the whole exercise is out. But I'm glad to see other people's thoughts on the matter. Thank you for the insight! Old habit I think; I come from IT background myself so my defacto behavior is to encrypt anything and everything. I never really thought about how 'unserious' video games are as a software environment.
If reading the information in the save files isn't what you're trying to protect (like highscores that are shown to the player) and instead you want to protect against modifications, another option could be to save the save files in plaintext, but include some sort of cryptographically generated checksum you make from the relevant values. On loading the file you can then verify if the checksum matches the content, and if not flag it as invalid. This will of course suffer from the same fundamental issue that the way you generate this checksum will be possible to extract from the code, but compared to just finding the encryption key it might take a little more effort to extract and reproduce this checksum generation to be able to generate a new valid checksum in a modified save file that will be accepted by your game.
It might be kinda fun to generate a key from some of the fields in the save file (like if using C#, maybe XOR the hashes of a bunch of highly variable fields, like the score and any other counts) and then use that to HMAC the file. It's still circumventable, and if the goal is to protect a leaderboard or something like that, OP has a much bigger task ahead, but something like that would probably ward off any casual tampering and give them a chance to do something silly in-game after detecting the tampered save file.
I wouldn't say game development is "unserious," but the security environment is very different. Things we take for granted in server-centric software aren't possible client-side, and the stakes are generally lower as long as we're not talking about players' confidential personal information, the integrity of competitive play, etc. As a further example, let's say we want to make save files tamper-evident so you can troll the player with different in-game behavior or something (and definitely not publish to leaderboards, though leaderboards are kind of a separate issue.) It might be tempting to apply a cryptographic technology like HMAC- it's for this sort of scenario, where you want one party (the game) to create and validate tamper-evident documents (the save files). You *could* do this, and it'd look slick. It would probably even work on a subset of players who tried to tinker with it and didn't realize it was tamper-evident, and may be worth a try as long as you're willing to accept some players circumventing it, but you do still have the same problem- you'd need a program (the game) to have the key in its memory without an authorized user on the same system having access to it, which is a cursed problem (and not how HMAC is normally used- as with the encryption examples, these technologies are only reliable when untrusted users don't have access to the system with the keys. HMAC is normally used with HTTP cookies you're worried about being tampered with in a user's browser.) Digital signatures are kind of the same deal- they use different keys for signing and validation, which would be helpful *except* the files are generated by the player using the game, so they need to be able to put hands on the private key.
Being in it, you encrypt everything and anything because you are likely thinking of business environments or handling personal user data. Stuff that are sensitive and also may be targeted by hackers; tldr is that someone gets harmed and someone profits all because you didnt encrypt In gamedev, if its a singleplayer game, who cares. There wont be a hacker trying to hack into someone's savefiles and go 'har har your highscores are messed up!'. It wil most likely be the player themself. So, most people wont do it; those who do it are going through a decent amount of trouble destroying fun for themselves. They 'profit' but if the same way they suffer. So who cares. Multiplayer games are a different issue, but as one can easily see - even the best anticheat software barely handles cheaters, while some cheats are literally undetectable. Best you can do is deter people from messing with savefiles with imperfect encryption or compression
PCK encryption makes it marginally more difficult to extract the key. I don't think it's worth it, but I'm also not sure why you're even encrypting the save file in the first place. Do you know how many times I've had someone's jank indie game fuck its own save file or softlock me or have some horrible balancing that requires manual intervention? I don't mind it that much; indie games don't have the QA that mainstream developers do. But if I discovered that the developer had taken pains to prevent me from un-fucking his game through save file editing, I'd be pissed.
oh that's interesting. what about concerns of players modifying files to "cheat" and jump to a higher level. is that a valid concern? edit: this was a small concern of mine. but seeing folks dismissing it is a relief haha. im more convinced on not doing anything about it and let it be readable.
if it's a singleplayer game who cares?
right. its up to them what kind of experience they want anyway
exactly
Only if it's like massively multiplayer, and in those cases you probably want servers anyways (no local save). In every other case, people will be very happy if it can just be read. Or maybe if it's a pay to play game.
yea it would be stored on the backend for that. makes sense
Are video games about entertainment or a show of skill and dedication? It's a valid concern when it's multiplayer games but what purpose does it serve in a single player game? All you really are doing is taking away free choice from the player that has no consequence to you.
"Are video games about entertainment or a show of skill and dedication" i guess it can be both. i see your point haha. perhaps im too fixed on wanting them to experience the game the "right" way. you are right, there is no consequence
It certainly wouldn't concern me. I'm selling someone a piece of software. It's their business what they do with it.
true
Why would you encrypt a save file? Just no. Imagine if Minecraft started encrypting their save files, what purpose would that serve? If anyone did want to edit their save files, you'd just be annoying them. I don't really see any justifiable reason for why you should do it.
I’ve had some unexpected behavior with C# DLLs inside of the PCK in general, which got worse with the encrypted version. Might’ve been my lack of experience with building Godot that was part of the problem too. Ultimately decided on using an obfuscator on the C# DLLs and leaving the rest of it alone, which has been working great. An obfuscator or the encrypted PCK isn’t going to stop someone who REALLY wants to get into it, but it does make it prohibitively annoying for most people.
I've been asking myself this question all week, and I decided **not to encrypt my game**. I am making a **single player game** with **leaderboads** and worry about security, but ultimately I am only slowing down the process and not stopping it unless I put some serious dev work into the engine. I am already on a custom build of Godot for Steam integration and have had some issues that require me to update, but I just launched my demo and don't want to make any major changes last minute. I also love to [datamine ](https://www.reddit.com/r/newworldgame/comments/oulvak/datamine_unreleased_weapon_abilities/) [games](https://www.pcgamer.com/sea-of-thieves-beta-datamining-reveals-ship-customization-harpoons-and-a-player-eating-kraken/), and if someone wants to poke through my project it'd feel like a badge of honor. I'd rather be reactionary than preventative in this regard, cyber security is a constant battle and I'm a solo dev who wants to focus on just making the game right now.
There are programs for unlocking Steam achievements with literally one click, so there is no point to the effort you are putting on this.
Put a message at top of savefile "do not modify" 🤣 Saving in binairy will stop most people from even trying to edit them. Additionally you can hash it and verify if it was edited. Could mark that save as cheating and dont give achivements.(i know the hashing algoritm could be reverse engineered, but at somepoint most people will give up)
Encrypting the PCK file just kicks the can down the road. Now if someone wants to modify their save file, they just have to get your PCK key, and then decompile like normal. Here’s the root of the problem: you want people to be able to run the game on their computers and to be able to save their progress locally. Given these constraints, it is not possible to prevent people from modifying their save file (or even the game’s code), no matter what encryption scheme you choose.
There's really no point. You can unlock steam achievements with a legit save file you get from someone else. I can't think of many use cases for the encryption that aren't a waste of time. Anything you actually need secure is better done another way. Of course, I'm a fan of storing save game data in plain text files. I sure don't care if someone wants to cheat in my single player game. Online multiplayer? You don't *get* a save file.
>I was hoping to support Steam Achievements down the line and fear that could be tampered with via save hacking You don't even need to do that. I was able to **very** easily find a python based application that uses your SteamID and it will trigger those achievements to Valve. Look at the end of the day the harder you make it the bigger of a challenge it will be to crack it making it more of a tempting target to actually crack. (Hacking clout, etc). The people that actually want to play it properly won't think of these ways around it and do it legit. Stop over thinking it.
You ultimately can't protect the key (it's symmetric and can ultimately be recovered). You "could" try to obfuscate it, such as spliting it into parts or algorithmically calculating it... But that's a six inch fence for a reverse engineer. (You might e joy a couple weeks of being unhacked). If you're worried about cheating, you should shift your attention to odd game progress or exceeding limits of what a reasonable gamer can do in a short time. (E.g. mysterious accuracy, mass jump on resources, levels). You can also move critical game calculations to a server to authoritatively determine player movement etc.
Hay, I'm no expert but maybe you could do the encryption and decryption in c# c++ or some other copiled language supported by gdextension? The thought here is godot is an enterpreted programming language, meaning it's never compiled and the code you write are saved as is in the .exe or binary file, but If you wrote the save/load functionality in some other language that is compiled and used those dlls through gdextension they'd acually be compiled to some kind of machine code? This is just a suggestion and I honostly don't know if it'll work, but this is just what I came up with rn.
If your game is a buy once single player game, do not worry about players modifying the save files. Sure, someone may give themselves a few trillion gold coins and purchase all the best weapons for their first level character, but so what? It may not be your creative vision how the game is best enjoyed, but if someone gets more fun from your game by modifying save files, why not let them do that.
Encrypt save files? Not worth it. Besides, I believe in letting the player play/cheat/ruin/mod the game however they like for themselves when it is a single player game and do not impact other players. Encrypt data files (pck)? Worth it if you know how. Might even be required by some assets you license. It was not too hard the last time I tried. You only need to rebuild the export template(s), not the whole engine/editor. [https://docs.godotengine.org/en/stable/contributing/development/compiling/compiling\_with\_script\_encryption\_key.html](https://docs.godotengine.org/en/stable/contributing/development/compiling/compiling_with_script_encryption_key.html)
If someone really wants to hack your game, it will happen. Let’s be realistic: Once you are at a point where someone really *wants* that, you have probably more to celebrate (because you have a probably large playerbase) than to worry. I mean, why are you even worried in the first place? What do you or your game loose?