Pack Mode: Pack into archive file (*.zip) --> Add support for password protection?

[supercom32]

Hi Everyone,

I noted that in the "Pack Mode" options for exporting a project, you can choose "Pack into archive file (.zip)" as one of the targets. Would it be possible to add password protection as well to this archive as a feature? The reason being, it would be helpful in deterring cheaters, modders, etc.

I suppose the "Pack into executable" and "Pack into binary file (.pck)" option provide slightly better protection against cheaters and moddification, but I'm not sure by how much? Probably still better than a standard ZIP file which can be opened and tampered with via any modern archive program?

[Zephilinox]

there's an encryption option, though you need to compile godot from source to use it. A password for a zip sounds nice

[supercom32]

Yep, you can indeed encrypt your GDScript if you re-compile godot. Too bad there isn't an easier way to do this that wouldn't require compiling it.

As for the password protected ZIP feature, I'm sure we're all aware that you won't stop a determined individual from getting what he/she wants. However, being able to distribute something that would at least stop script-kiddies would be pretty neat indeed!

[vnen]

How and where would the password be stored so the executable can play the game?

[supercom32]

This idea is just off-the-cuff, but I assume if "load_resource_pack" could accept a password argument, you'd just provide it there. And in turn, your GDScript would be encrypted, so it wouldn't be trivial for someone to look at it. Then you wouldn't even need to worry about how you export your application.

I also suppose that the key could simply be the one you provide when you compile Godot, so the same key that is used to encrypt your GDScript is used for opening any ZIP archive containers. But that might be more work than just letting the GDScript encryption do it's job.

[ghost]

I'm pretty sure you'd be able to log the password when unpacking if this would be the case.

[supercom32]

Ah, maybe I misunderstand. I suppose you could run everything in a VM and watch for the key to appear when it gets revealed in memory, but by that point you've already achieved your objective. That is, you've stopped the average Joe-nobody (who only knows how to use an off-the-shelf, do-it-all-for-you, tool) from modifying or editing your files.

It's like compiling your own version and encrypting your GDScripts (which you can currently do). The key has to come with the treasure chest, so anyone smart enough will be able to snuff it out. It's just a matter of making it hard enough that the average users can't do it, and those who can, likely won't care.

I suspect if ether GDScript encryption was extended to all assets/archives as well, or if "load_resource_pack" was able to mount password protected ZIP files (while providing those keys via encrypted GDScript), it would be enough. Surely better than just a regular ZIP file any competent archiver can open.

[ghost]

Yeah, some basic scum repellent would be indeed nice. I'm pretty sure it would still create a single point of failure but that can probably be somewhat mitigated by several compression algorithms

[eon-s]

What about some way to detect package integrity? a checksum, signature. Maybe some of this may need a custom module or via GDNative.

[supercom32]

Some kind of built in integrity check would be awesome. Though I must admit, I still like the idea of having some kind of basic asset protection to complement it. Even if it the protection was simple, as long as it's unique enough (per application) that you couldn't just go "Ah, it's just a proprietary packing format. Just read the file specs from the repos and write an unpacker", that would be good.

That's why I suggested password protected ZIP, since even if the file format is known the password could be personalized and could act as a simple deterrent unique to each application. I would think this would be easy to do, since you don't even need to protect the password as long as your GDScripts are encrypted to begin with. Just pass it to "load_resource_pack" (If enhanced for password support) and go!

[reduz]

It's easy to extend encryption to the pck, but it will just make loading assets much slower.. so not quite sure if this is desired. A checksum is kinda easy to defeat, too.

On May 2, 2017 5:14 AM, "supercom32" notifications@github.com wrote:

Some kind of built in integrity check would be awesome. Though I must admit, I still like the idea of having some kind of basic asset protection to complement it. Even if it the protection was simple, as long as it's unique enough (per application) that you couldn't just go "Ah, it's just a proprietary packing format. Just read the file specs from the repos and write an unpacker", that would be good.

That's why I suggested password protected ZIP, since even if the file format is known the password could be personalized and could act as a simple deterrent unique to each application. I would think this would be easy to do, since you don't even need to protect the password as long as your GDScripts are encrypted to begin with. Just pass it to "load_resource_pack" (If enhanced for password support) and go!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/8614#issuecomment-298487413, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z25bJzX13SKQGEEwtc0PURKi7mBUvks5r1p-PgaJpZM4NNQQS .

[ghost]

How about just some unusual compression that's not supported by common archiving tools? At least I think that's how Unity does it (and still fails miserably because it's popular but that bridge can be crossed when we get there)

[ghost]

Actually, thinking about it, that's how almost everyone does it. At least I never encountered encrypted resources during romhacking. Just homegrown compression.

[reduz]

Whathever we add, it will make loading slower, sad fact of life :/ I don't think there is an easy way of doing this.. the simplest and most efficient is still encrypting scripts.. which forces people to look for the cipher in the binary..

On May 2, 2017 7:53 AM, "ArcFutahito" notifications@github.com wrote:

Actually, thinking about it, that's how almost everyone does it. At least I never encountered encrypted resources during romhacking. Just homegrown compression.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/8614#issuecomment-298503449, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z28QgHdLkO1Mu-jUuZyTKFnqi6Iueks5r1sTFgaJpZM4NNQQS .

[ghost]

Well, yeah, sure, uncompressing would make stuff more taxing, but unlike encryption you get an extra benefit of having your game take up less space. Besides, it's not like games don't already pack up their stuff like that (at least on consoles).

[ghost]

http://www.oberhumer.com/opensource/lzo/ Something like this for example. But not recognizable by every damn archival tool in the world xD

[akien-mga]

Well .pck is already a custom (zip-derived) format AFAIK, and you can encrypt your scripts. What more is needed?

[ghost]

Pck actually compresses stuff? Huh, I didn't know that since packages get bigger than original files. Then I guess all is fine and well.

Well, the topic can probably be closed then. @supercom32 I can tell you with authority that decompressing some random archival formats can be quite a task. Won't be hard since godot is open source and all but still won't let some rando just pass.

[akien-mga]

Well I don't know if .pck compresses stuff, but probably just as much as .zip (i.e. mostly none :D).

[eon-s]

Extending the script encryption to some selected scenes may help, but the "pro" way to protect your game may be a custom build with modules.

[supercom32]

Ah, some pretty good points made all around! In regards to the 'speed' of encrypting assets, I kind of feel that rather than make that choice, it should be up to the user to decide. Not all applications will be super large or intensive, and for some people the trade-off might be worth while.

In addition, I really like eon-s idea that perhaps the ability to make some encryption to "key" scenes/files/assets could be done. It really strikes a balance for performance, while covering some key components essential to the operation of the program.

Question, while we're on the subject: Does bundling everything in the executable simply cause an *.pck to be appended to the end of it? Or is the internal structure totally different? Is the contents still compressed?

PS: Assuming encryption was added, how much slower loading are we talking about? Because on most modern computers running LUKS encryption, or another form of full disk encryption, I never really notice much of a performance problem.

[Calinou]

.pck does not compress, but .zip does. So, if you want the fastest loading possible, you should favor .pck over .zip (but .zip compression is plenty fast for most use cases).

Note that while generic archive managers can't open .pck files (it's a custom format made for Godot), it would be easy to extract them (and possibly re-create them) by writing a custom utility.

[punto-]

If you can control what happens with your zip file, you can archive (ie not compress) certain files

On 2 May 2017 at 15:48, Hugo Locurcio notifications@github.com wrote:

.pck does not compress, but .zip does. So, if you want the fastest loading possible, you should favor .pck over .zip (but .zip compression is plenty fast for most use cases). Note that while generic archive managers can't open .pck files (it's a custom format made for Godot), it would be easy to extract them (and possibly re-create them) by writing a custom utility.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/8614#issuecomment-298726003, or mute the thread https://github.com/notifications/unsubscribe-auth/AGVmPUrwz1ti9P_Ql1CMWxKzqxRsQMHbks5r13qHgaJpZM4NNQQS .

[ghost]

If files are just strung together then you probably don't even need a utility, you can just open hex editor and look up file headers.

[eon-s]

Another option, add full pck encryption but allow encrypted and unencrypted pcks (I wonder if this can be done on 2 already), so assets can be unencrypted while scenes and scripts are protected (to prevent loading them on other Godot projects).

[rraallvv]

I came here because of this video, that shows a tool that supports out-of-the-box decompression for Godot package files.

So, I just wanted to point out that there is a tool that can be used to access encrypted virtual volumes on-the-fly. It's multi-platform, open source, and fast, and don't even require additional space, although active development has stoped.

Maybe someone wants to pick up on that, to add that kind of thing to Godot.

[Calinou]

So, I just wanted to point out that there is a tool that can be used to access encrypted virtual volumes on-the-fly. It's multi-platform, open source, and fast, and don't even require additional space, although active development has stoped.

Neither TrueCrypt nor its fork VeraCrypt are under an FSF-approved or OSI-approved license. Additionally, I think they would be too large to be embedded into a game engine.

[rraallvv]

Reiterating with this issue, I'm trying to find other options to TrueCrypt/VeraCrypt, since @Calinou pointed out that those are not an alternative.

The closest I've got is with this two:

• zbox
• MiniCrypt

Both use LZ4 and AES, in fact, it seems LZ4 is almost twice as fast than FastLZ. The later is the one built-in in Godot.

However zbox might not be entirely compatible with Godot's license requirements, and was developed in Rust.

Regarding MiniCrypt, it's written in C# and it's not well known, instead of using it, I might as well create my own library.

So, maybe a light weight alternative for TrueCrypt/VeraCrypt is totally doable, without compromising that much performance as with zip + password encryption, by means of using LZ4 + AES.

[rraallvv]

I just found this website with some very interesting charts comparing the most commonly used compression algorithms.

In particular for an assets container one might be interested in looking at fastlz, lz4 and yalz77. For instance lz4 is faster than fastlz, although it's compression ratio might be lower depending on the type of the files added to the container. Also yalz77 has the fastest decompression speed of the three, with a similar compression ratio to the other two algorithms, although it's compression speed is the slowest.

I'm implementing an custom assets container format using lz4 and AES in C# for a separate project, also I will try yalz77 to see which one is faster with the assets I'm using, since a small compression time isn't a requirement for that project.

Maybe we could add both lz4 and yalz77 as alternatives to fastlz for network communication and stuff to Godot, or maybe as a alternative to the zip format for exported packages. What do you think guys?

I haven't published yet a repository for my custom assets container format using lz4 and AES, but if anyone want to experiment with it just let me know. Cheers!

[akien-mga]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!