• Building

  • There should be options for protecting game resources, even if they are third party.

@BillGHero said: Has anyone successfully protected game-resource through encryption or obfuscation with their Godot game? If so, please share what you can here.

I have not personally had to deal with protected/encrypted files, though I did at one point look a bit through it. From what I remember, .pck files are not encrypted or otherwise protected. However, .pck files cannot simply be opened with a zip utility, at least not yet, so it at least isn't super easy to access the assets within a .pck file.

As I mentioned in this topic, contacting the authors of the protected asset(s) and getting their opinion on Godot and asset protection in relation to their asset is probably the best way to handle the situation if you are worried about protecting 3rd party assets. (Also, as I mentioned in the topic: I am not a lawyer, so please do not take what I write as legal advice!)

(If you wish to argue with me over why I should want to protect game-resource then open a post in a more appropriate section of the forum and I will happily debate with you there)

Just a reminder to anyone wishing to have this type of argument/debate/discussion: Please keep it civil and respect others when posting, even if you disagree with their opinion/idea/etc. It is fine to talk about topics like this, and to share your opinion on something, but please be respectful when participating in discussions, even if it is in the appropriate section of the forum, like the general chat section. Thanks!

I haven't done this myself, but it probably wouldn't be that effective. Because if you encrypt the files, the client still needs to decrypt them somehow (to play the game), which would require the keys to be stored with the game assets and available to any hackers. While it would protect against casual snoopers, anyone dedicated enough could probably easily bypass this. Not saying it can't be done, or that it is not useful in some cases, though it would be pretty hard (or impossible) to make it 100% effective.

@cybereality said: I haven't done this myself, but it probably wouldn't be that effective. Because if you encrypt the files, the client still needs to decrypt them somehow (to play the game), which would require the keys to be stored with the game assets and available to any hackers. While it would protect against casual snoopers, anyone dedicated enough could probably easily bypass this. Not saying it can't be done, or that it is not useful in some cases, though it would be pretty hard (or impossible) to make it 100% effective.

I understand what you are saying, @cybereality, and I agree that there is no bullet proof way to protect the game resources. But this is intended as a technical thread concerning the industry-standard practice of protecting game assets (which is quite flawed, but still a standard practice). I have amended my original post to help make the intention of this thread more obvious.

Yeah, I understand.

Did a quick search, it looks like the LZMA SDK is public domain, and supports strong AES 256 encryption.

https://www.7-zip.org/sdk.html

I guess you could modify Godot source to additionally AES encrypt the pck file and then decrypt it on load. I am not sure if a module could do this, but that would be ideal versus modifying and re-compiling the whole engine. And, like I mentioned before, the key would still have to exist somewhere, though if pck is binary (I'm not sure) it would probably all look like junk to a casual observer.

Another thing to consider, is that people can still rip assets (even if encrypted) through hooking into DirectX/OpenGL and pulling the art from the GPU memory (or during transit, when they are in the clear). Though this does require more sophistication, and will likely be out of reach from anyone without advanced skill.

3 months later

Would be really useful. @TwistedTwigleg linked my topic, but just to repeat my point: I have 0 interest in actually protecting assets, my only interest was in adhering to license agreements that called for it.

I'm not big on asset stores but they do have their uses and most agreements that I have read seem pretty clear about not being able to be opened in publicly available software and requiring some degree of reverse engineering.

It's disheartening to see the discussion on Github closed by people who seem to completely ignore this reasoning.

[QUOTE] a dedicated person would be able to extract them no matter what you do..

..

If you're worried about copyright, the law enforcement might be a better bet than trying to obfuscate the assets in your game.

...

I think this is an overreaction and other engines might not offer that much protection you're thinking they do.

...

I'm closing this since DRM won't be added

@vnen vnen closed this on Jun 30, 2018 [/QUOTE] (https://github.com/godotengine/godot/issues/19790)

Should we contact asset stored and suggest they change their terms and contact law enforcement?

The discussion seems to have come to an end with the following: [QUOTE]Do other game engines have any built-it "assets protection"? Nop, Unity and Unreal forums are full of the similar "Protect game resources" topics, with the exactly same answer: "it's pointless". (And asset stores are full of third-party snake-oil tools).[/QUOTE]

Not only does this miss the point, but it's also completely false:

[QUOTE]When distributed in a shipped product, .Pak files can be signed or encrypted, usually to hinder data extraction or tampering. To activate, deactivate, or adjust the cryptographic settings on your project, go to the Project Settings menu and find the Crypto section. [/QUOTE] (https://docs.unrealengine.com/en-US/Engine/Basics/Projects/Packaging/index.html)

I am unsure why there is such opposition to this feature.

I think the opposition is that it's a losing battle. It might stop some casual snooper, but anyone with any skill could easily decrypt or otherwise steal the assets (using OpenGL hooking, or memory hacking, etc.). So there is an element of pointlessness, when you know you are shipping protection that could be easily broken in a few days with a dedicated adversary.

That said, I think it could still be worthwhile. As you say, you may not completely own all the assets in your game, and I'm not sure what kind of legal liability there is if the assets get stolen from your game. And you can make it difficult enough that most people won't bother or it will be beyond them and they will give up. Not a bullet proof solution, but probably enough to show you did your best effort and I don't think you would be accountable at that point (but I'm not a lawyer).

I'm not sure what kind of legal liability there is if the assets get stolen from your game. And you can make it difficult enough that most people won't bother or it will be beyond them and they will give up. Not a bullet proof solution, but probably enough to show you did your best effort and I don't think you would be accountable at that point (but I'm not a lawyer).

Also not a lawyer, but I'm fairly certain there is no liability provided you meet the terms, and the terms are (for those I have read) very specific:

You must take all reasonable and industry standard measures to prevent other parties from gaining access to Stock Media Products. Stock Media Products must be contained in proprietary formats so that they cannot be opened or imported in a publicly available software application or framework, or extracted without reverse engineering. WebGL exports from Unity, Unreal, Lumberyard, and Stingray are permitted. Any other open format or format encrypted with decryptable open standards (such as an encrypted compression archive or other WebGL programs not listed here) are prohibited from using Stock Media Products.

(https://blog.turbosquid.com/royalty-free-license/#Creations-of-Computer-Games)

If you use any Product in software products (such as video games, simulations, or VR-worlds) you must take all reasonable measures to prevent the end user from gaining access to the Product. Methods of safeguarding the Product include but are not limited to: -using a proprietary Product format; -using a proprietary and/or password protected database or resource file that stores the Product data; -encrypting the Product data.

(https://help.cgtrader.com/en/articles/2402359-royalty-free-license)

Two examples, and they are very clear. This is not optional and by having no form of protection Godot is ruled out of using any assets from these stores. We all know people rip assets from games all the time but it does not matter in the slightest, you have to meet the requirements of the license agreement.

There is a desire and a utility to protecting game assets from casual piracy. It isn't a protection for the assets themselves, though. It is meant to protect the game developer from litigation of a third party. If there is a license agreement to use some kind of protection, and the developer (the licensee) fails to comply with this requirement, it is they who will be attacked in court. The transgressor (the person who pirated the resource) will most likely be out of reach, unidentifiable, or just a poor financial target. However, the licensee/developer is likely to be a good target.

The reason for wanting the protection is that it is a safeguard against lawsuit-happy people. And it is a real concern.

Well, Godot stores assets in a .pck file, which I think would be considered "a proprietary Product format" as per the cg trader rules. I mean, I was not able to open it in a text editor or zip archive manager. I assume it's a binary format that is proprietary to Godot.

I don't believe the data is encrypted but it would not be a simple thing to extract. I imagine there would be a way to figure it out for a dedicated attacker, but I think that would fall under "reverse engineering" and thus meet the standards of the turbosquid license (for compiled games).

WebGL would be more tricky since they specifically only allow certain engines (which is strange) but I did not find an easy way to extract the data using standard browser debugging tools. I know there might be some ways to do this, but it is not simple or obvious (it still looks like a .pck file, not individual assets).

So honestly I think it's probably fine for both counts (well except turbosquid and WebGL).

I have come to the conclusion that if I ever need to use some kind of obfuscation, it might mean making it myself.

Normally I wouldn't see that as a big deal, but it might mean having to implement it on a per-platform basis. :expressionless:

Still, I don't have an issue with Godot not having the encryption. What I do want to see is some hooks built into it to make it possible to build a plugin which will work with Godot in a future-proof manner. That way the work put into such a plugin would not be wasted when a new version of Godot comes out.

These 'hooks' could be as simple as override-able methods for accessing protected resources on the run-time core and similar ones for the development side.

Perhaps they already exist and I just haven't foudn them yet? Maybe not...

Yeah, I think you can do this with a tool. Granted, I've never tried this before, but this page seems to indicate you can create custom resource loaders (maybe doing on the fly decryption).

https://docs.godotengine.org/en/stable/classes/class_resourceloader.html

I can take a look later today, I don't think it would take long to at least verify it's possible (adding encryption is probably like a small project though). Even then, you need to store the keys somewhere and that is the weakest link. I don't know too much about this, I'd have to investigate.

@cybereality said: Well, Godot stores assets in a .pck file, which I think would be considered "a proprietary Product format"

I would assume it isn't proprietary, but to be honest I don't know. Can .pck files be opened with Godot editor in anyway, and if so how simple is it? When I looked up proprietary format, the following is what I based my assumption on:

A proprietary format is a file format of a company, organization, or individual that contains data that is ordered and stored according to a particular encoding-scheme, designed by the company or organization to be secret, such that the decoding and interpretation of this stored data is easily accomplished only with particular software or hardware that the company itself has developed. The specification of the data encoding format is not released

I'm not sure if an open source project can ever meet this definition? I wouldn't like to risk it though personally. I've read mentions of using a passworded zip, since godot can use these instead of pck, perhaps this would meet the definition? In the CGTrader case I would think so, not sure about the wording for Turbosquid. GDScript can be encrypted so the password could be stored there.

Yeah, the nature of open-source is that anyone can see the code, so it's definitely not a secret. However, AFAIK, the .pck files themselves are not an open standard even if the code that writes and reads them are.

There is a desire and a utility to protecting game assets from casual piracy. It isn't a protection for the assets themselves, though. It is meant to protect the game developer from litigation of a third party. If there is a license agreement to use some kind of protection, and the developer (the licensee) fails to comply with this requirement, it is they who will be attacked in court. The transgressor (the person who pirated the resource) will most likely be out of reach, unidentifiable, or just a poor financial target. However, the licensee/developer is likely to be a good target.

The reason for wanting the protection is that it is a safeguard against lawsuit-happy people. And it is a real concern.> @cybereality said:

2 years later

There are secure encryptions for other programming languages like C++ that I use with VisualStudio for Godot.

Right, but you are sending the files to end-users, which means you also have to include the decryption key with the encrypted files if you want them to be able to play the game. Of course, it is a little more secure and requires more sophistication to hack, but it's like putting two locks on your apartment door, someone can still kick the door down, pick both locks, or break the window.

I think the only really effective solution would be custom hardware. That would be expensive and drastically reduce the number of people who would want to play the game. It would only be practical on a large scale.

There has never been a 100% secure software, however it is no reason for you to leave everything exposed.