Protect Game Resources #19790
Comments
|
I know you can encrypt the script bytecode by compiling godot from source with the Line 30 in 8bf5b50 |
|
Related to #8614. |
|
BTW, I'm not sure why this is much of a problem. It's not exactly easy to extract a PCK if the person in question is not aware of Godot. And a dedicated person would be able to extract them no matter what you do.. |
|
And even if you are able to extract them, all the scripts are (at least by default) compiled, and any scene files are converted to .scn which itself is binary. Not only that, I'm not sure why it matters that people can access the files. Anyone who wants to cheat will cheat, and anyone who wants to mod a game will mod. After they download the game, that copy is theirs to screw around with, and generally do whatever with (within the bounds of fair use, of course). When they do that, it's their own fault if the game screws up, or if they get banned from that game (if online) for cheating -- not the dev's fault. |
|
Relax 😄 What's up guys? Just reported the fact that the pck file displays the source code as plain text and the most resources are extractable. For example with the Dragon Unpacker Hyper Ripper. Have a nice day. :) |
I just checked. Exported
Resources exported by Unreal Engine, Game Maker Studio, and Unity are also all extractable. Also, just tried this Hyper Ripper myself, wasn't able to extract any scene or source code files. I could extract my application's icon (the only graphic I had in my project) however -- but people have been extracting sprites, models, textures, and sounds from games for years.
So are Game Maker Studio projects. I believe Unreal Engine works the same too? Unsure about Unity. |
|
Ok, you're right. My fault. The I checked this again. In my case I have a script with a lot of exports to adjust parameters of a node. I have a bad feeling about these public sources in the package file. The editiable scenes in exported projects. It's like ini-files or settings you never provided. You can close this issue if you want. Or focus to the open scenes and resources. And protect it by obfuscating, hashes or an encryption. Just to reduce the hackers. Nothing is safe. That's right. But is this a reason to give up? The gaming industry should remove DRM and other protecting software, because people will hack this. Right? 😄 Update: Thanks for your time. :) |
|
3.1 will have an experimental option to convert all text resources to
binary on export
…On Wed, Jun 27, 2018 at 8:46 PM Dominik Geng ***@***.***> wrote:
Ok, you're right. My fault. The .gd scripts are not stored in plain text.
Sorry.
But in my opinion there are too much plain text in this file. And the
assets too.
btw. the Hyper Ripper only extract known formats like png. It can't
extract Godot formats like scenes or scripts.
I checked this again. In my case I have a script with a lot of exports to
adjust parameters of a node.
It looked like script sources. 😄 Now I see it's the scene indeed.
But I be able to change some parameters, store the file (pck) and see the
results. It works. You can change anything in the scene including
parameters provided from scripts.
Ok, you can say, I don't care what people do with my software. Change the
sources whatever. They could use a Trainer (cheating). It's not completely
wrong. In multiplayer games, the developer must never trust the client.
Whatever ...
I have a bad feeling about these public sources in the package file. The
editiable scenes in exported projects. It's like ini-files or settings you
never provided.
I just wanted to report this issue after viewed the file and found some
plain text ressources like the scenes and other resources like meshes (e.g.
PoolVector3Array) and other assets.
I think it's ok for amateur projects. Maybe for a tiny indie-game too. And
AAA-Studios maybe never use Godot. Unfortunately. But in my opinion it's
not a bad idea to protect as much as possible. Why to provide editable
sources? I think this is a topic for proprietary commercial projects.
You can close this issue if you want. Or focus to the open scenes and
resources. And protect it by obfuscating, hashes or an encryption. Just to
reduce the hackers. Nothing is safe. That's right. But is this a reason to
give up? The gaming industry should remove DRM and other protecting
software, because people will hack this. Right? 😄
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#19790 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF-Z21AgTVlYBM0NTg6I0lT8cSYBDStZks5uBBlCgaJpZM4U4iQ1>
.
|
|
If you're worried about piracy, this kind of obfuscation won't help you. You'd need some actual DRM protection, which Godot won't provide (since there are many ways to do it, and it's not a vital thing). So you need a third-party tool for this. If you're worried about copyright, the law enforcement might be a better bet than trying to obfuscate the assets in your game. It's not a matter of open/closed project. Any dedicated person will be able to extract the assets and change the base game. Some companies use this to their advantage (see Counter-Strike and Team Fortress for example). The mod scene is quite big and many players might buy your game just to apply the mods. Suppose we provide support for encrypting the assets. The key must be stored in the executable, since they need to be unencrypted to be used by the game. Considering that Godot is open source, anyone can check out what is the encryption algorithm and where such key is stored. With that information wouldn't be so hard to break through the encryption anyway. You could change the Godot source to modify the algorithm/key location (but then, you already can change the source to add this). I agree with binary conversion (and that was always in the plan) since it makes everything faster to load. But in terms of protection there's not that much gain, only a false sense of security. Obfuscation is not really security. I think this is an overreaction and other engines might not offer that much protection you're thinking they do. |
|
That's absolutely correct. But this is not exactly my intention. I just don't like editable plain text in built applications. For example the scenes. As shown on the gif of my previous post. If I am still alone with this opinion, it is regrettable. But maybe I'm not able to articulate correctly in english. I see many confused- and laugh- emoji without a text message about the reason. That's pity. |
|
@domske I don't think that it is that it is not wanted, but rather that this is as impossible topic. If the resources have to be used, textures unpacked into memory, models transferred to the GPU, etc... etc... then there are always ways to get at the information since it is already local. The top end DRMs for games run the entire things in virtual machines with layers upon layers of obfuscation and slowdown and they still get broken. It is an impossible thing if the resources are needed to be used at all. |
|
I know. This is a never ending story. A cold war between a publisher and pirates. 😄 But a necessity. |
|
I understood what @domske said. |
Not really. "Uglifying" the code is used to make it more compact, reducing download time / bandwidth usage. It's not very hard to undo it (just put in a code formatter, like the browser console provides).
It is not shown if you exported without debug.
Sure, and using binary resources would be enough for that. I don't know why @domske has such a pessimistic view considering that's already established that this will be done. |
|
@volzhs Thanks, you understood me. 😃 @vnen Of course "minifying" is for download and bandwidth optimization. But also for obfuscating. That's why the word "uglifying" is also used for this. There are different modes to do this. A strong mode removes variable names and comments, etc. Do not see this in an extreme contrast. "Secured": YES or NO. It's more about "Secured:" NO, ABIT, BETTER, ALMOST, RESERVED. And the pck-file has the state ABIT and the goal is BETTER. 😄 I have no pessimistic view on this. I don't know the changes of Godot in the future. I only reported the actual state. That we all can consider about this issue. If this is already established, that's great. |
|
I'm closing this since DRM won't be added and conversion to binary is already tracked by #12452. |
|
I don’t know how we pointed to DRM. 😄 Maybe my fault. This wasn't the topic. Ok, I missed this ticket #12452. It's related to this issue, that’s correct. What a misunderstanding of my ticket. ^^ Ok, not for all. Whatever ... I‘m look forward to version 3.1. |
|
I agree with @domske on this one. I've run some tests, and:
These are both very surprising. I don't understand why local variable names (variables that are defined within the body of a function) affect the size of exported .gdc files. Comments affecting the size of exported .gdc files is even more mind boggling. I'll get back to these, but first: A hacker will hack, yes. I used to hack games when I was 14, to make heroes invincible, levels impossible to fail, etc. But the code I hacked was never in plain sight in front of me; the variable names were never visible, and I never saw the name of a single function. All that was visible to me was machine code -- disassembled assembly code to be precise -- with addresses for variables. So, I wouldn't have been able to extract any of that code and repurpose it without spending more time than it's worth (not that I would have regardless, but there are lots of people in the world who would). Even if some of you disagree, I see a lot of value in having the same level of "protection by obfuscation" in the commercial products that I create. In other words, I don't want my algorithms to be visible in their original form after Godot loads them into memory. Some of you say converting to binary is enough for that, but I disagree. Even if it Godot weren't open source (which makes the dissection of any generated binaries much easier), my 14 year old self would have been able to see all that content using a basic debugger. I sure won't be releasing any commercial software that allows easy access to my class, function, and variable names, let alone my comments. And I also respectfully disagree with the "law enforcement might be a better bet" comment. What indie developer has the time or resources to sue someone across the world? Would you even have the time to dissect competitors' code to see if they stole from you? Even if you were to win a lawsuit, what do you think are your chances to successfully collect the money for the damages from an individual on the other side of the world? Prevention is your best bet. This is not about whether someone can hack and modify your code. It's about protecting your algorithms and intellectual property, such that the time and effort required to reverse engineer would be so high that the people with that skill wouldn't waste their time trying to understand your obfuscated code. In other words, make it difficult enough so that the people who have the skill would find it easier to build their own thing than to steal yours, and the ones without the skill would be limited to minor hacks. Such minor hacks are fun for the kids who can do them anyway, and have no financial harm to the developer as long as they don't distribute a version of your code that bypasses its copy-protection mechanisms. And pushing competitors to come up with their own algorithms is better for everyone, including users; more ideas and more innovation results in more interesting products. Acknowledging the problem is the first step. Once the problem is acknowledged:
The solutions can be discussed, but the first step is to acknowledge the problem with a more open mind, without dismissing the problem and deferring it to law enforcement. P.S. As a bonus, obfuscating identifier names should also help improve performance. For identifiers that don't need to be looked up by dynamically created strings (i.e. most identifiers), making their names as short as possible should speed up any code that does look up things by name (i.e. gdscript and Godot in general). |
|
In GDScript, everything is dynamic, so 2 doesn't apply. |
|
Good news; I did another test this morning, and it seems the size increase due to comments is just a bug. From what I can see, comments are always converted to the same binary content; when I change the content of the comments without changing their size, the created .gdc file remains the same, which means the information within the comments is lost. So scrap item 1 from my list for the purposes of this discussion, as it needs to be a different issue entry on its own. Item 3 remains. |
i just tested this actually. i opened my .pck file in visual studio code, and it had over 100k lines, but i searched for a variable that i had in my script, and the entire script was in there lol maybe once this is merged, and you choose |
|
Game asset sites also require their assets to be sufficiently protected when incorporated into an app. So we are legally required to provide reasonable protection of any purchased assets we use. I still don't understand why this is issue is closed, and disagree with the cheered obfuscation is not protection, etc. comments above. By the same logic, do you not put locks on your house doors because people who are willing enough will find a way in anyway? I don't know about you, but I like to lock my doors, and I am legally required to do so for the assets I use. In summary:
|
I don't think the comparison with locks makes sense, as locks are not necessarily unfair. You could see it as a parallel to encrypting your own files for privacy's sake. |
|
Wondering why this has been closed. As far as I understand it, #24582 only partially fixes this issue by only encrypting scripts. Scenes and assets are still not encrypted - this is not strictly a matter of DRM, as @ArdaE has pointed out this could prevent the use of a good number of assets (even some otherwise freely available ones) with Godot. This isn't DRM; merely allowing Godot to extend legally-required (minimum) protections when necessary. If people want to use an actual DRM scheme ala Denuvo, then the onus of implementation (and licensing etc) is on them. |
|
What is your definition of DRM? I think a common one is "technical measures to prevent unauthorized or undesired use of some work". Under that definition, what you describe is DRM, since it is a technical measure (encryption) to prevent the independent use of game assets. |
|
@raymoo, note @Sslaxx's use of "strictly" and "actual" to qualify his uses of the word DRM. "Digital Rights Management", is a measure to manage your "rights" -- as the name suggests -- to content you've purchased. In its common use (and the only type I've seen), it applies directly to content you've purchased (a song, a game, etc.) by attempting to prevent you from redistributing it while allowing you to use it freely (how well it achieves that is questionable, as the attempt to prevent redistribution usually interferes with your legal use rights, but that's the topic of another discussion). Now, when you purchase a game, you don't purchase the rights to the assets within the game; you purchase some rights/license to the game. I wouldn't use the word DRM, in its strict form, to refer to the protection of assets within a game, because you have no "rights" to those assets; the game does. You only have a right to play the game. So in my opinion, and in the common use of the DRM technology, there's nothing to manage for DRM when you have no "right" to start with (as far as embedded assets are concerned). One way to protect resources you have no right to is to modify them in irreversible ways that still allow a game to use them while making their extraction in their original form impossible or very difficult. I wouldn't define that as DRM. If it were, merely compiling a C++ program would have to also be defined as DRM. We can go down this rabbit hole and discuss until the end of the world what DRM is, and I'm sure you can come up with a hundred different creative ways to rebuke what I just wrote, but I don't see how any of that is beneficial to this discussion. Whatever the accepted meaning of DRM (or our understanding of it as individuals) is, the issue remains. |
You can protect assets by encrypting And you can protect encryption key stored inside exported executable (by default it's quite easy to extract it) using "actual DRM ala Denuvo". This part should be left for third-party tools. |
|
It's definitely not the main purpose of this discussion, but it appears like sslaxx is arguing that because it wouldn't actually. be DRM, it's not as bad. I was trying to refute that particular (implicit) point. I might have been wrong about that implication. For my definition, I just used that which the GPLv3 is based on (technical measures to prevent use unwanted by the copyright holders or authors). I can make one based on expanding DRM as an abbreviation too, though (like you did). The rights it refers to are the copyright holders' "rights", not the users. This is how I usually see the term described by others (including pro-DRM people). In that case restrictions on the use of a game is DRM because it is managing the LICENSOR's "rights", not the licensee's. In the case of licensed assets, it is the "rights" of the copyright holders of the assets. |
|
FWIW, I agree 100% with ArdaE: assets need to be reasonably protected & scripts need to be obfuscated. I've been evaluating Godot, and this is a deal-killer for me personally. I am only writing this because business owners (like restaurants, for example) rarely get feedback that tells them why people are not coming. They'll get negative feedback from existing customers, but they never find out why people don't come in the first place. One thing that is often mentioned about Godot is that it doesn't have as 'sexy' a gallery of Godot games that some other engines have. I'm not going to say it's all because of obfuscation, but serious game developers and artists -- the kind who create games that make great videos -- do care about it. I hate to write a negative comment, because there is really a lot to praise about Godot. I would love to use it. But if "locking my front door" is next to impossible, I simply can't. |
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). |
it's not about CAN or CANNOT, it's about how much steallers have to pay. easy or hard is different to different person, "not much encrypt" to you, but a lot of learning time and knowledge (or money) have to pay, for thieves. You don't feel it's hard because you already have that knowledge, after years of learning. another easy to crack step of encryption, means 90% fewer thieves have that ability. in some country like China, laws not work for ordinary people. almost all company and the whole government are waiting to steal from all over the world. steallings like tradings, even the richest government want to steal your project, if it cost more than payback, they won't do it. so it's not about CAN or CANNOT, every lock CAN be broken, but every house have it. Laws can't replace Locks. |
|
You seem keen to tell us that a lock would be effective. Tell us, then: How would we implement such a lock? If we implement it into the engine, then people can examine the source code (which is far easier than you're making it out to be for anyone who's even slightly determined) and figure out how we store the key, how to access it, and what encryption method(s) we use. You might call it hard to crack, but I guarantee you that if we were to implement it into the engine proper, it wouldn't take long before someone copies the decryption code from the engine and uses it for a "Godot game decrypter"... making the lock effectively useless. You are much better off learning C++ and implementing your own asset protection system, than us doing the work for you. Then, they would have to figure it out from scratch because the code wouldn't be public. |
|
In my country there is a saying "Locks from kind people". Any lock can be broken, it's a matter of time, but every house has a lock. The fact is that the better the lock, the longer it takes to break it, and the time and effort may not pay off. Therefore, thieves are more likely to steal things from poor houses with bad locks than from rich houses with good locks. If you implement the ability to encrypt all files as scripts are encrypted now, users will be grateful. And in general, if this is a project and with the source code someone can make such a plug-in for Godot and all that remains is to implement it into the project. I would, but unfortunately I don't know C ++. |
This may hold true in the real world, where you don't see the locks and tumblers within a real lock, making it hard to know how to lock-pick -- but Godot is open-source. That doesn't work here. That's a problem, because it's the equivalent of a lock being transparent -- if you can see how far you need to push each pin up, you don't need to worry about whether you've pushed a pin too far up or not. You know the key to that door now -- you can just create your own copy of the key. See, Godot being open-source means that if Godot were to include some sort of resource protection, it would need to have that code included with the engine's source code. The source code being openly available (you don't even need to login to GitHub to download a copy), means that anybody could search the code-base for the part that encrypts/decrypts resources, and reverse engineer it. Then they can use that knowledge to build a program that will automatically search out the encryption key -- and use that to decrypt the resources. All that might sound hard, but I'll be honest: It's really not. It's really, genuinely, not that hard. Honestly, it's harder coming up with how those locks would work, than it is to break the locks. And even if it were hard to break the locks, all it takes is one person offering that decryption program to the world -- now everyone could buy a machine (or build their own) that looks through those transparent locks, and spits out a key that can be used to open that lock. I'm not trying to say that we aren't sympathetic to developers wanting to protect their game's resources -- we are! But we can't include resource protection within the engine, unless game developers are okay with the drawback that someone could access the game's resources anyways... and I think that drawback effectively negates including resource protection in the first place. |
|
I think this issue goes beyond security, it is also about keeping original source code as secret. Having comments removed from the compiled code do basically nothing to protect original source code. Well-written source codes are designed to be as readable as possible by programmers, this mean having a good architectural design of classes, variables and methods, and of course, names of those things, because they need to be declarative enough. A well-written source code will be substantially easier to read and understand even without comments provided you have the original variables, classes and method names. Source codes have intangible value for companies. Released commercial games source codes are extremely rare, because almost always they are kept as secret. So actually releasing a compiled game where its code is basically the source code without comments, is almost the same as releasing the source code, with the barrier of the decompiling task. The main problem with godot, and I think its the main reason on why main Godot engine developers refuses to implement some kind of obfuscation, is because all variables and methods can be referenced with strings, and that feature surely breaks with a compiler that mangles function and variables names. |
I am very disappointed with your answers. This is a very irresponsible behavior. You believe that there will be thieves invading your home, so it doesn't matter if there is no lock, because locks cannot prevent others from invading. |
|
It's not exactly "easy" to obtain source code because PCK contrary to what you seem to think does NOT contain pure source code (at least not in 3.x). If you state that Godot can not be protected, well, the same applies to UE4 and Unity... therefore no engine is "responsible" or "safe" to you |
Why do you mention unity and ue, which are related to this matter? |
As I said, it's not the case, at least in Godot 3 pck does not store plaintext scripts |
I don't use 3.0, I use 4.0, and all I'm talking about is 4.0. And if 4.0 doesn't provide any protection and only 3.0 doesn't display clear text scripts, do you mean to let everyone abandon advanced features and return to 3.0? Isn't that a step backwards in history? Why can't 4.0 use the same approach as 3.0? As I said, it is clear that GODOT does not care about these content, and 3.0 is also easy to extract content because it is open source. There are no exceptions. |
|
3.x bytecode is not protection in any form, it is a one-to-one representation of the script that is easily converted back to the source code in one click. Protection features remain similar: 3.x had encryption support for scripts only, 4.0 have support for full PCK encryption - see https://docs.godotengine.org/en/latest/contributing/development/compiling/compiling_with_script_encryption_key.html, (in case of Android, enable APK expansion to use it). |
|
@bruvzg I know bytecode can be easily converted back, but it's not plaintext source as such, which is what the person seems to have implied |
Closed-source is not much better, because then you're relying on security through obscurity - a technique that is far less protective than it may seem. To explain, let's return to your analogy about having locks on one's home: Closed-source would be the equivalent of having a new key shape for your lock. It does not necessarily change the lock's resistance to picking, though! Perhaps some key-way shapes are harder to pick open than others - but all it takes is one person with enough spare time to develop an appropriate tool once, and suddenly everyone can pick it. In the same token, you simply cannot expect that closed source = completely secure. The experts who make encryption/hashing algorithms know this, which is why they actually focus on making it hard to break even if you know the recipe. It's why some password managers (for example, KeePass) are open-source - you should be able to trust that your passwords are safe even if the attacker knows exactly what algorithm is used to protect it. It's why we have folks who actively attack the big encryption algorithms, to try to figure out their weaknesses, so that we can make even better algorithms in the future. Assuming that closed-source is a one-size-fits-all solution to making your game assets secure, is the same as assuming that adding 1 to every byte in a Google Document constitutes encryption. Sure, they'd have to know what you're doing to the document in order to revert it (you're adding 1), but that doesn't make it secure. |
|
Thanks everyone for sharing your opinions. There is no point in discussing the merits of open source for a game engine, because that's not something that will ever change for Godot. Having source available does, of course, allow for an easy introspection of the codebase, but indeed closed source projects are being decompiled and reverse engineered all the time, it's not exactly a hard endeavor. So we don't see it as a weakness of the project. As for source availability of your game and its assets, Godot implements encryption that you can enable and use. But remember, that you are making a project that is supposed to run on the end user's device. By definition it will be unpacked and decrypted before the execution, in the environment fully controlled by somebody else. So any form of protection has a very limited effect here. Still, if there are some actionable ideas, proposals are welcome. Feel free to share and discuss suggestions there. |
Godot version:
3.0.4
OS/device including version:
Windows 10
Perhaps all supported platforms.
Issue description:
Protect the source code and resources of the game.
Currently it's easy to "decompile" / extract all resources including scripts.
Update: GD-Scripts are binary in pck-file. But the scenes are stored in plain text and editable.
Steps to reproduce:
e.g. Export as Windows Desktop (exe). Tested with the classic Godot (not mono)
You'll get following files:
The same issue may affect all other platforms. Including Android and iOS. All assets and scripts are visible to anyone with a little knowledge of files.
The text was updated successfully, but these errors were encountered: