PCK files include human-readable script code #24716
Comments
|
good discussion in #19790 as well? |
|
.pck can be opened? I tried doing it when I found exported a test project that I later mistakenly deleted the source of... and couldn't... |
|
@Zireael07 It's a custom binary format, opening it in a text or hex editor can reveal some data directly as text (as shown above). There's also third-party tools which can "parse" custom binary formats and extract resources out of them, without any prior knowledge of the format. These tools rely on common patterns found in binary files such as PNGs to extract data. Lastly, it would be fairly easy to write a PCK extraction tool (either as part of Godot itself, or as a standalone tool). |
|
Maybe we can encrypt the .pck similar to how .gde files are encrypted? Or alternatively, encrypt each file separately with keys derived from a key given at export. |
|
would #24582 be a solution to this issue? (the "compiled" option under the script tab) |
In case it might be useful here's my old PCK extraction tool (AFIAK PCK format was not changed ever) or you can find everything necessary for extraction in core/io/file_access_pack.cpp. It's quite simple format, basically list of file names, sizes and offsets and raw content. |
|
@bruvzg okay very cool. thank you so much for sharing that. i found that godot does still create .gdc files, however, the raw text of the gdscript is still visible inside the .pck file itself. i initially thought if we could see the raw gds in the .pck, we could then extract the .pck and then look at all the gdscript files. that's not the case. they get extracted as .gdc. now that i think of it, this seems like sorcery |
|
Compiled |
|
@bruvzg would that still be possible even if exporting with encryption enabled for scripts? (using a AES key)? |
Encryption won't help much, it's just 5 minute delay. |
|
dang @bruvzg. thanks. very interesting. i wonder if it's possible so the .pck file doesn't show raw gds, but the compiled gds instead? |
|
Decompiling gdscript turns out easier than I expect, here's proof-of-concept Clone into Godot's |
|
Any encryption in the exported game will not avoid a persistent person who wants to get the contents. That is because not matter what you do, the encryption key must be somewhere in the binaries. Also note that the PCK is essentially a file system, with the ideal of being easy and fast to seek to any specific file without having to extract the PCK itself. We couldn't encrypt the whole PCK just because it would require extracting the contents somewhere (which then could be looked by any person anyway). Encrypting each individual file is possible, but still the key needs to be somewhere, and the things are decrypted in memory, so anyone with CheatEngine or the likes of it could check it out. Compiled GDScripts are not really "compiled", they are just the tokenized form written in a binary format. |
|
If you really need to avoid people from peeking, the only solution is to host the data on your own server. |
i see. very interesting, thanks! |
|
The initial idea (mentioned in the title of this issue) is not to encrypt the files (that would not stop anyone, just delay them, as many people here already mentioned), but to obfuscate the files. While the names of variables seem to be hidden in the .pck file, the string content is very much visible. Is there a way to hide it somehow from the people who simply open the .pck file in Vim ? |
i tested it. opening a .pck in a text editor shows "uncompiled" gds (even variable names, etc) |
|
That seems like a serious issue for someone who wants to make bigger, professional games using Godot. |
|
@miskatonicstudio yeah, even now the hacker will prob stumble upon gdsdecomp 🗡 |
|
I have been working with C# and i also found it strange when the project.dll is add to pck the classes itself also have to be add to pck for resources that have reference to those classes. Been working on a custom packer (for mono) that does 3 steps compile than obfuscate the project.dll and after that collect all stuff what should be packed into the pck. |
|
@vnen Do you not put locks on your house doors, because anyone who's willing enough will find a way in? Or not lock your bike because anyone who's determined enough will steal it anyway? Just because you cannot prevent the most determined people does not mean we shouldn't provide any protection. |
|
i think vnen was just saying that to make a point that it can never really be hack proof. there will always be some way for a naughty person to get what they want. whether it's using ollydbg, gdscript decompiler, etc. |
|
@girng I have the utmost respect for the core developers for their contributions to Godot. But @vnen closed another, more inclusive issue (#19790) after stating "... a false sense of security. Obfuscation is not really security." So he's not "just saying that to make a point"; he used that line of argument to dismiss a similar, earlier issue raised by others. I am thankful to him for all his contributions, but I wholeheartedly disagree with him on his stance on this topic. P.S. I used to hack games when I was a kid (for single-player games, long before the multi-player games existed). So take it from someone who knows how things can be made harder to hack. We're not protecting national secrets here, and a little protection goes a long way. |
|
@ArdaE yes, i understand. he's not wrong though, since it's a open source project, it's gonna be impossible to protect because all algorithms will be found in the repo. however, IMO, i do believe raw gdscript should not be available in the .pck (would solve the OP's issue too), but i don't know if that is possible because my knowledge is limited. |
|
There seems to be great misunderstanding of what obfuscation means here. It doesn't matter if someone knows the algorithm used to obfuscate script files. Obfuscation is a one-way process; when done right, you can't get back to the original scripts, ever, nor does Godot need to do so to run the scripts. For those who seem to confuse it with encryption, please look up .NET obfuscators. Further, as I've stated, "impossible" is not a reason to not provide any protection (at the end of the day, nothing short of quantum encryption is impossible to break). The idea is simply to make things difficult. If you don't need protection, that's fine, but I ask you to please not dilute and dismiss the discussion for those of us who care for it. |
|
someone is working for compiling gdscript to gdnative. I hope he makes PR someday. related issue here #11068 |
|
To clarify, the use case shown in the OP needs to be solved. End users should not be able to access human readable source code (scripts, scenes) by opening the .pck file in a text/hex editor, nor by extracting the contents of the .pck somehow. This is easy to do, scripts and scenes need to be converted to binary formats on export (and we're supposed to have an option to do exactly that already - but maybe it's not working as expected?). Further obfuscation to prevent crackers from getting access to resources and binary code is not planned. It's well established by now that even by spending millions on DRM and anti-cracking measures, AAA studios can only win a few days at most. It's not Godot's job to fight that (and I'd argue that it's pointless to even try). There's a PR to restore the script encryption feature. As mentioned above, it's not particularly efficient, but if it makes some users feel more confident that their code is "harder" to crack, it doesn't hurt. To further on the "door lock" analogy, sure, it's good to lock your door to prevent the neighbour's kid to enter and snatch your Switch. That's what should be done by preventing scripts and scenes to be human-readable in .pck files. But you can put 15 locks on a heavy duty door, it's no use against determined robbers if all it takes to get in is to break a window.
While this is true, obfuscation is not planned for Godot scenes nor GDScript. This issue is just badly titled, what it asks for is just to make scenes and code non human-readable. |
@bojidar-bg How is encryption any type of protection for code that needs to be loaded into memory? I'll simply let your code load and decrypt itself nicely using whatever advanced algorithm and key you have devised, and then peek into its memory space using a debugger. (Mind you, I guess it would address the title of the issue, and provide some false sense of security). |
Well, that's your "locked door". Experienced robbers can always break your lock or find another way in, but that's good enough to prevent most unwanted visitors. |
Touché. |
|
To be clear, I think most users will be perfectly happy with this kind of "protection" offered by non-human readable binary files and optionally, some encryption. Sure, it can be broken, and quite easily if you know what you're doing, but it's still good enough for 99.9% of their legit users who have nothing to do in this code (and likely no interest to look into it beyond curiosity). A real obfuscation feature as discussed above could be interesting for the users who really want this kind of protection, but I'm not sure the additional complexity is worth it for the engine out of the box. Might be worth exploring this possibility as a C++ module, and let interested users compile it in themselves. If it turns out not to make things too complex and a very popular module, we could consider merging it in the core. |
Your time to shine, ArdaE 💯. I'll be the first one to test it out too, please lmk. |
|
https://www.youtube.com/watch?v=FdNXTFD59Tw it's very sad bad hacking file open pck (Images, Music, 3D Models) |
|
As someone who was planning to use Godot for production and who has supported it via Patreon during the past 4 months, I have found this issue a real no-go deal breaker with the following irreversible takeaways: (AA)
Even more so frustrating is the amount and names of upvoters to this. (BB) not so much of a mystery anymore considering that core contributors are of the following opinion:
(CC) (#19790) opened Jun 26, 2018 [closed, unresolved]
(#12452) opened Oct 28, 2017 (DD) (EE)
And that comment has 5 upvotes. Both Unreal and Unity do not contain source of the either Blueprints / C# code; Unity has a popular 5-star obfuscator in the asset store plus an ati-hack solution, whereas Unreal actually compiles Blueprint and the end result is ahead of time compiled binary. (FF)
Sounds promising but has not been delivered ever since. (GG)
"apparently exists already" apparently, it is buggy:
(HH)
To conclude, it seems that Godot project and their maintainers are rather interested in achieving academic goals than preparing itself for a heavy commercial AAA production. With all due respect, I am afraid this direction and approach are not sustainable for the real world application use case. Please tell me, why a person with commercial goals would want to continue supporting this project with further voluntary contributions - directly monetary via Patreon and indirectly with knowledge / product / title releases, while witnessing all this negative attitude towards the real world needs of a commercial publisher/developer/entity? This is a rhetorical question, mind you. ref |
|
@n3xxt: The fact that Unity has obfuscators has nothing to do with Unity devs itself, as you mentioned, it's a 3rd party asset. The fact is, any obfuscation can be beaten, and for a project like Godot that is created in 90% by people doing things in their free time, any time sunk into obfuscation is therefore wasted time. |
I mean, thats a bit like saying "we'll never get completely lifelike graphics, so any effort spent improving graphics realism is wasted". This reduces the question for some security to an all-or-nothing state, which doesn't reflect reality. In security, you have the concept of threat modeling, or more simply "Which kind of attack are you trying to prevent?" Nobody is saying "lets make Godot games unhackable for nation-state agencies". The requests I've read are simply "please prevent even the most unskilled player being able to open my game in a text editor and seeing the whole code reproduced plaintext, as well as all assets and secrets". This is a quite possible and IMO worthwhile goal. @n3xxt But donating or using the engine won't magically make things that much quicker. |
Oh, I wasn't aware it was such a simple request. Because most people asking for obfuscation were interested in commercial games, I thought they wanted commercial level obfuscation. Such a basic obfuscation could probably be achieved easily with Base64 or a simple cipher. (Unfortunately, my c++ skills are nearly zero :( ) |
|
For the reference, encrypting everything is easy (and probably really slow with the large |
|
@bruvzg I feel like this could solve most use cases. If performance is an issue, perhaps it would be reasonable to have an option to separate "sensitive" resources like scripts, shaders etc. into their own encrypted If no files are marked for encryption, then nothing changes, just export everything the way it is now. |
|
Hi @n3xxt!
I'm releasing a commercial game. I would just like to add: Take a look at Path of Exile. Their content.ggpk has been "cracked" if you will, and every single file has been extracted. There is even a public website that lets you view its data. The only "truly compiled" code is in their What I'm trying to say is, view their |
|
Addressing issues that pointed to me, just to clarify.
Well, it is true though. You can make it harder to figure out, but only way to completely avoid it is to not have it in the binary at all.
GDScript predates GDNative by many years. We do have plans to compile GDScript to native code eventually.
Those are not opinions, those are facts. Like everything else, whether or not we should reconsider is open to discussion. We will have a proper compiled form in GDScript for Godot 4.0 (though that won't really hide plain text strings in the source file, they can still be viewed in a hexdump like in pretty much any other language). You'll still be able to encrypt the resulting file (as it's already possible in stable releases for quite a while).
It's pretty normal to close issues are like an existing one (duplicates), since there's no need for two reports of the same problem. You can see that this very issue here was never closed, and that one could be considered a duplicate of this, so there's still a tracked issue.
People should not expect to dictate the project goals just because they are donating. Not even the companies do that. What companies do is to hire their own developers to add features to the engine that they are missing, instead of waiting for voluntary contributors to do the work. |
|
I've seen a lot of updates recently, so I'd like to chime in. The solution of the original problem from this issue was suggested by @mhilbrunner : it is not about making the data completely unreadable by experts, it is just about being unable to read the crucial bits of PCK files with a normal text editor ;) Any obfuscation would prevent it, and I'd consider it a solution. If users start reverse engineering the game, then little can be done to prevent it other than (as mentioned) storing the binary on the server. But the original problem was just that a normal user can open a PCK file in Vim and read the solutions to the puzzles. |
|
Variable and function names don't have to be human-readable for executing scripts, so there is no need to make them accessible to everyone. This is not comparable to not having a lock on your door, it's more comparable to sending everyone a map of your house that includes where to find all the valuable stuff and telling them when you're not home. You don't want that information out there at all, not even in pseudo-"encrypted" form with the key included in the binary. |
|
I believe this is solved by #38308. You can encrypt any file in the PCK. See https://docs.godotengine.org/en/latest/development/compiling/compiling_with_script_encryption_key.html |
Godot version:
3.0.6
OS/device including version:
Linux Pop!_OS 17.10 (Artful Aardvark)
Issue description:
One of the people playing our game noticed that the source code is available in the .pck file downloaded by Steam. The game (Intrepid) is an escape room and the source code contains all the codes (answers to puzzles) used in the game. The game was released for free, so this is not a problem for now (only this one person found out the solutions this way) but we'd like to use Godot for future games too, and for that we need to be sure that crucial details will not be available by investigating the .pck file.
Steps to reproduce:
Example:
Minimal reproduction project:
The text was updated successfully, but these errors were encountered: