-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds PCK encryption support (using script encryption key for export). #38308
Conversation
7afffb3
to
174e47e
Compare
174e47e
to
7c87f9f
Compare
Changed it to the per-file encryption (file name filter in the export settings + optional directory encryption to hide file names), previous approach was decrypting whole PCK to the memory, every time file in it is opened. |
8c99b13
to
cd178e8
Compare
af372b4
to
8b956fd
Compare
I was wondering how this behaves with large PCK files, but with per-file encryption it shouldn't be so bad. |
With mindless "encrypt everything" approach it's quite slow. Excluding textures (*.stex) from the encryption makes it fast enough even with the white-box decryption (which is significantly slower than release build with default mbedtls AES). With the reasonable filters for hiding sensitive information only, overhead should be negligible. |
Can the key that is stored in the binary be used to decrypt the pck file (a given), change the content (eg make walls translucent), then re-encrypt modified game data? Encryption is not something I'm that knowledgeable in so sorry if this is a question with what should be an obvious answer. |
Yes, if get the key out of the binary you can do this. With white-box encryption there is no plain key stored in the binary, it's mixed with random data and code and attacker will need to find and reverse-engineer decryption code, it's still possible but harder to do. |
Someone in the future is probably going to request something like an option to use public key encryption as a preventative measure against cheaters in multiplayer games. That or do it themselves. Personally I don't have a use for it as I'm just doing either single player games or small, co-op games. |
It's always possible to modify binary, and bypass encryption altogether, and it's possible to manipulate decrypted resources in the process or/and GPU memory. Adding asymmetric cryptography probably won't make it any harder. And relying on encryption as the only multiplayer anti-cheat measure is a bad idea anyway. Proper solution to prevent wall hacks is restricting the information sent by the server - calculate visibility on the server and give only visible opponent data to the clients and so on. |
That is not how public key encryption works. I guess you could use it to sign your binary or assets, but that doesn't really help against someone simply taking out the check for that. But I guess that's what bruvzg already outlined in the previous comment, which I somehow missed :P |
6550f3d
to
1006779
Compare
42b4d3e
to
ede0e6c
Compare
const int file_num = files.size(); | ||
if (p_verbose && (file_num > 0)) { | ||
if (count % 100 == 0) { | ||
printf("%i/%i (%.2f)\r", count, files.size(), float(count) / files.size() * 100); | ||
printf("%i/%i (%.2f)\r", count, file_num, float(count) / file_num * 100); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change was added to suppress MSVC: warning C4723: potential divide by 0
error.
e150f3f
to
392dfda
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really good work! 🚀 🏅
One thing I noticed, is that the Script
export tab is a bit misleading now.
Setting Script Export Mode
to Encrypted
do not actually encrypt scripts unless *.gd
files are included in the filter (which is not the default).
This is partly unrelated to this PR (since it was implemented in modules/gdscript/register_types.cpp
and removed in recent GDScript update).
My suggestion is to have the Encryption
tab always shown (maybe with an on
/off
switch) remove the Script
tab, and move the Script Export Mode
option to Resources
with just the option: Text
and Compiled
(since Encryption
will be handled by the dedicated section). This should also potentially allow to encrypt "compiled" gdscript.
What do you think?
Change default encryption mode from ECB to CFB.
392dfda
to
f043eab
Compare
Done. (When "Encrypt exported PCK" is unchecked, the rest of the encryption option are grayed-out). |
I think this will be great to add. Although anything can be broken some licences for 3d models and other assets require that you try to protect the assets. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank is amazing work 🚀 ! Thank you!
Thanks! |
BTW, one thing I thought about and mentioned to @Faless today is that it could be good UX-wise to validate the encryption key in the configured export template when exporting with encryption enabled. This could be done e.g. by exporting a temporary project with a simple magic string and see if it can be decoded properly (using OS.execute). Or possibly running a script directly with |
Should be possible with #41190. |
No, it's for 4.0 only. |
Should we add |
Maybe even default it to the |
We should have option select encrypt whole file data or encrypt 1000 first bytes of file data (textures). |
Adds optional
PCK
encryption (per file encryption + directory encryption) to exportPCK
andPCKPacker
.Changes
FileAccessEncrypted
's encryption mode from ECB to CFB (encryption/decryption is done in the one sequential pass anyway, there's no reason to use ECB).Adds support for whitebox decryption code instead of hardcoded key. Actual decryption function implementation should be supplied by user. Example generated by https://github.com/balena/aes-whitebox is provided for testing purpose.Removed, will add it as separate PR if I'll find usable open-source implementation.
Related issue #24716.