How safe is godot right now?

Hmmm, so I live, very comfortably, in a small village with nice neighbours. The strange thing is none of the houses have any real locks. “Hey, people, should we talk about locks!!!” I shouted one day. And this is what I got:

  • Who needs a lock, not me, if a thief is determined enough, he will always break your lock.
  • My aunt has a lock. Her house was broken into last week.
  • That is just silly. if someone is skillful enough to break your lock, he is also skillful enough to build anything you have in your room. That is just common sense :stuck_out_tongue:
  • Instead worry about locks, maybe you should concentrate on building more stuff?
  • Nah, locks no good. If you want real security, what you actually need is xyz.
  • Hmmm, are you sure what you have is good enough for a lock? haha, just saying.

Jokes aside, I think the real issue is do we want our game open source or not. And I wish that is a decision each of us can make for him/her self. It is a regretable fact that Godot does not offer that basic choice.

Once upon a time, people did think code security is important, so the encryption feature was added. It is a flawed design especially since godot is open source and obfuscation is probably the better way to go.
But now, it seems, many of us and certainly the godot team don’t want to talk about this anymore. I am somewhat curious, what has changed? The arguments for and against it have not, so it is something else?

But I am grateful for what Godot is now. There will always be some feature one of us want but is missing. So lets enjoy what we have now and hope Godot gets better and better with each new release.

2 Likes

Godot offers this very feature, I see you didn’t really feel like reading the posts before you put up yours. Godot offers an encryption feature, and even the whole “bUt ItS sToReD iN tHe ExEcUtAbLe” excuse is mute because, as you said yourself, Godot is open source. It’s quite easy to change how said encrytpion key is stored, making it not at all trivial for some random person to get it back.

3 Likes

:smiley: quote=“tibaverus, post:42, topic:120653”]
I see you didn’t really feel like reading the posts before you put up yours
[/quote]

Hmmm, I wonder how you know what I feel like or not. :stuck_out_tongue:

Actually your anwser is, if you have read my post, mentioned in my “lock” analogy:
“Nah, locks no good. If you want real security, what you actually need is xyz.”

And certainly most feature request can be denied by saying “why don’t you learn to do it yourself”. Look man, I am not your enemy, just disagree with your on this. That’s all.

This issue did come up a few times in the past, there was a certain lengthy discussion on reddit which played out almost exactly the same way. Obviously the request is an old one, so are the arguments against it. I just do not think the arguments are that convincing.

That many engines do have obfuscation may not mean it is perfect, but it certainly prove many people think it is a good idea. So I don’t understand why there is such resistance to it.
Well, there is always C# :smiley:

1 Like

BS. Totally so. There are decompilers and disassemblers around for any and all exe formats in the wild.

If you can run it on a local machine, you can crack It. Period. The amount of time needed might vary.
To a varying extent, anything running on a public faced server can be attacked and exploited, from DoS to 0 day vulnerabilities.

A whole industry of black, grey and white hats exists around those issues : cyber security and cyber warfare.

Nothing is safe in the modern computing world, not even that air gaped server at NSA, as that can be gotten at with social engineering, the oldest trick in Intelligence work.
More worries about making and shipping games, and as we use to say 20 some years ago : my game just got cracked, so cool :smiling_face_with_sunglasses:
Cheers !

5 Likes

Your posts read very disingenuously to me. You started by telling a fable that in my opinion, made you sound like you were trying to be a jerk without picking a fight. But I’ll assume you were just trying to lighten the mood.

To @tibaverus 's point, your first post obfuscated the fact that you’d read his. Saying encryption isn’t a solution is disingenuous. It’s just a solution you don’t want. In your fable analogy, it is the lock. Which is why I was confused.

But here’s why I think your posts are disingenuous. It sounds like you’re continuing a long-held argument from another forum, and bringing all that baggage with it, instead of engaging with us here. They you state:

So I looked into that statement. As far as I can tell, the only two engines that matter in this context (Unreal and Unity) do not have any obfuscation built-in. You have to use third-party tools for that.

You’re right. I went to the Godot Proposals Repo, and there was more than one.

Ultimately, we are all just users here and the team has been pretty clear they’re not adding it.

Another point was made in a couple of those posts. No matter what you do to obfuscate your code, when the game is running, all that is undone so the game can run in memory. A memory sniffer can be used to read all your running code.

I get that this is a long-running sore subject for you, so I want to be sensitive to that. In the future, if you are going to make claims like “many engines have obfuscation”, it would be helpful to provides links to, or even names of those engines.

Finally, regardless of what we discuss here in this thread, this isn’t the place for the discussion if you want something to change. The Godot team rarely reads/responds these threads. The place for discussion if you want change is in the links I posted to the Godot Proposals Repo.

4 Likes

Are we on the topic of how to secure our game? If, then my last sentence would be make a fan base and showcase it on every social media, every reddit forum(about game development obviously)
That’s the way to prevent your game getting a new title…

3 Likes

Hmmm, disingenuous? I don’t think I was hidding anything.
I was using the lock analogy to show how ridiculous some of the arguments are.
And you are of course right, I was trying to lighten the mood.
If you don’t like the way I expressed myself, it’s ok. I can do it in other ways.

I am not saying encryption is not a solution, I am saying obfuscation is a better solution.
Instead denying people any access the the code, it is enough to make it hard to understand and modify. That is what the OP was talking about. As far as I understand it is also easier to implement and therefore more cost effective. (If it is not the case, then I am wrong)

So I want a lock, instead you suggest a home security system. Just because the security system serves a similar function, it is a lock? No.

Ok, I did open the door by mentioning discussions in the past. To be honest, I never posted anything about this issue till now. And yes, since I am using gdscript for my current project, it is something which bothers me. And I am not apologizing for that. :smiley:

So unity and unreal only have obfuscation as “third party”, ok, I stand corrected.

The question still remains, is obfuscation useful or not. be it third party or not.
And my anwser is yes.


I think I have contributed all I have on this topic. Sorry if I have offended anybody.

A final question to you @dragonforge-dev, since we are all game dev:

When you release your game, it is a commercial game I presume, will you use encryption or obfuscation in any form?

As for me I will probably forego the encryption but most likely try some form of obfuscation.

I’ve worked on at least a half dozen shipped titles : one had copy protection in the sense it was a AAA Xbox 360 title.
The rest, and all the cancelled projects I worked on (only paid work included) never thought about obfuscation, much less about encryption, as we all knew that if they have a copy they can crack it.

The amount of work (roll your own encryption or obfuscation) needed for this to deter any half competent cracker is ressources better spent in making your game better : more content, better assets, optimization, QA, localization are all way more worthy of spending limited ressources on.

Plus, in the indie space, you often get bonus points for being open, moddable, etc.

The examples of stolen games to be resold for non negligible profits exist, but they got targeted because they were perceived as small and defenseless legal wise, and in a different country, targeted Fromm countries where copyright law enforcement is non-existent.

A Godot encrypted build would not deter them, neither would obfuscation.

If you want to go that way, learn from the pros : always online game that validate legit seats through an encrypted transaction, validate whatever they feel needs validating, and basically don’t trust the client.
But even that, can be cracked

For Indies, the general wisdom is you’re wasting limited ressources that would be better used on more man hours on programming, content, testing, etc.

Not worth it.

Keep making better games !
Cheers!

5 Likes

Saying it doesn’t make it so however.

Well, to be clear encryption of builds is already implemented by the Godot team. Obfuscation is provided by third party tools, just like for Unreal and Unity.

So the question is: For whom are you claiming it is easier and more cost-effective? The Godot team already did the work. It’s open source, so it’s free for the end-user.

As far as in-engine obfuscation, the cost to the Godot team and users is high. It would cause all sorts of problems, outlined in the very long discussions I linked in my last post.

I don’t know that you’re wrong. You may be right. I do not know what you are comparing.

I think the metaphor has gotten confused. Encryption is in fact more like locking the house because you need a key to unlock it. It’s even called a key. Obfuscation is more like hiding the valuables where the thieves won’t think to look.

Both metaphors fail because in this case the hacker has their own copy of the house they can dismantle piece by piece.

I’m not asking you to apologize. What I, and others, have been trying to tell you - and the others with concerns on here - is that you are worrying about something that you cannot control. It’s a lot of extra effort. If you want to do it, go ahead.

But to be clear, this is a forum where people come for answers. When people find this thread in the future, there are a number of us who want to be clear about what we are saying. You are the first person to whom we are addressing our comments - not the last.

And so does Godot.

That is absolutely a valid opinion, and you should absolutely do what feels safe for you. You got the response you got from myself and others though because it seemed as though you were trying to say that we were all wrong and that your answer was the answer for everyone.

You do you.

No worries. We are all here to learn and contribute to make everyone’s games better.

Depends on the game and the intended platform.

If a client requests it, I will encrypt a game. @OleNic already gave a nice long response to this, so I’ll try not to repeat what he’s said.

I have worked at a number of companies that had all sorts of crazy ways to implement DRM. Ultimately, I personally believe that DRM is not worth the money. There’s a reason Apple went hard in on it with music and then gave up.

Before people stealing your concept/code was an issue, people pirating your game and giving it away for free online was an issue. You will lose out on a percentage of sales because people steal your game or ideas. In retail, it’s called shrinkage. The best way to deal with that is to just understand you cannot control it and focus on making your game so good that people know you came up with the idea and are loyal because your game is better.

Sometimes, no matter what you do, your game will fail. Maybe quickly. Maybe slowly. You do a postmortem, learn from the things that didn’t work, and you make the next game better.

My conclusion is the same. You’re better off making your game good.

Having said that, I will likely encrypt my own games, because all it requires is a few extra steps, and if you’re publishing your game commercially, the first thing you want to do is take out the 2D or 3D parts that you’re not using to save space. So while you’re in there, make an AES key and add another command line argument.

4 Likes

I don’t think it is so much about how difficult or easy it would be to crack something as how much someone wants to crack it.
Very few would want to spend a lot of time and energy on cracking a game that would not have enough earning potential. Most basic measures will not be good enough for an anticipated AAA-game but that doesn’t mean they won’t be good enough for a small indie title, like the one linked to before.
Like the lock to my house. Its good enough for me but put it on one of those armored vehicles transporting money and suddenly its horrendous. Should I not use that lock because “even those armored vehicles are not protected enough to really prevent theft”?
I don’t see why so many people get upset over your concerns.

1 Like

No. If I give you an executable written in C++, Java, or C# and ask you for its code you won’t be able to retrieve it at all.

This is absolutely hilarious to me as a former Minecraft modder and big figure in the wider MC modding community - we’ve basically single-handedly driven Java decompiler development for nearly a decade, resulting in tools like VineFlower, Enigma, and more. To my knowledge, C# has similar deobfuscation tools , and C/C++ of course have Ghidra.

At the end of the day, there is no silver bullet for protecting your code - especially as an indie dev, folks just aren’t gonna put in the effort to pirate your game at scale because getting it directly through Steam and Itch is just so much more convenient. Go ahead and encrypt your pak, and if you wanna require that folks at least put in a modicum of effort to cracking write your code in a GDExtension using a lower-level language rather than GDScript or C#.

Another big thing to keep in mind if you’re worried about people making clones or copies of your game is that they don’t need access to the code to do that - your best defense against that is putting more effort into game design and polishing than they’re willing to.

6 Likes

Just keep your game entangled in it’s own mess and no one will bother to pick at it.
…Humor aside, this is a very important and most interesting conversation.
I am looking at all the measures there are to take, any and all things to do concerning the -rather rightful and just- intention of protecting a work of love…
Small and big, projects done with Godot are mostly “passion work” and they sure deserve some decent method of protection.

Indeed, I’ve been thinking and keep trying to come up with ideas towards this, within the reasonable range and beyond.
One unorthodox step, which I plan to do is to ship the game within it’s own edition of LINUX.

Now that one is ofc not really ideal for example to release on Steam…

…But that and maybe a one-time login, a “please register your game, this isn’t data collection” prompt or similar may land within said range of sanity.

Pre-promo work and decent documentation, proper licensing measures and stressing here -PRE- work could also ensure some level of protection. Finding (and funding) legal preparations and “paper work” is an extra but, again, reasonable on a larger project.

My take and humble opinion is to really think out of the box, while most of us cannot afford lawyers or a contract with a publisher - the “hacking against cracking” is probably over there, in the boring ‘legals’.

Apart from these, how about also using different compression methods within the project, I mean, how about making all images the dreaded avif and more obscure formats? Like taking further building Godot from sauce? Wait that doesn’t matter cause we hand “the reader” over, right?

Sorry for the craziness but I am honestly invested in this…

None of these solutions are solutions. As soon as a game launches, it’s assets CAN be ripped. As soon as a texture or 3D object is loaded into your GPU, it CAN be ripped. Nothing you can do about this, at all. Not even making your own Operating System for your game (lol).

The only method that might work is if your game runs entirely inside your own server that you operate, and your players must connect to your server to play your game, and the “game” you ship is nothing but a client that essentially just displays a video streamed to their PC from your server. That way the game only ever runs on your server / machine, but obviously this isn’t really a solution for ANY indie developer, keeping a server like that up and operational costs way too much money.

Long story short: Just focus on making a good game. Do some basic things to make it slightly more difficult to get your assets, but don’t stress yourself over it. There’s literally no point.

6 Likes

I’ve been writing games since the 1980s on commodore 64. They thought it was possible to protect games back then. Tape multiloaders, entering a word from a page on a manual. Then people just copied the memory, compressed it and made it load faster… End story 40 years later it is still impossible unless as stated you are behind a server setup that no indie dev can afford. The juice is not worth the squeeze.

7 Likes