Game Development

Stuff like this isn't there to stop people with lots of resources. It's to stop people who are lazy, will see encryption and go, eh, I guess I'm not doing that after all.

It's the baseline, make it annoying enough that most people won't even bother wasting their time.

Anti viruses won’t care as it won’t be injecting executable code.

How do you know parts of the encrypted stuff isn't executable code? Like is he has secret levels with secret functionalities then part of whats encrypted might get executed, or interpreted and executed or something like that.

If he's going out of his way to hide and encrypt secrets, I wouldn't be surprised if parts of his gameloop are obfuscated as well. And if Anti viruses detect high levels of obfuscation, that just raises flags as probabilistic malware

It sort of looked like you'd construct the key by input. Like an old school password entry screen or something. I wonder if you could correct horse battery stapler it enough to have a respectable key length.

The only way is to hold that secret key on your server until the day of content release. But that is basically a lite version of always online DRM.

Anti viruses won’t care as it won’t be injecting executable code.

When I first started working on malware for my offensive cybersec job, I felt pretty at loss about how the fuck are you supposed to execute anything, if you simply have to 1) allocate memory with READ_WRITE_EXECUTE, and then 2) execute the memory.

I thought that's something that legit programs don't have any reason to do - why would you ever need to allocate RWX memory? I've never done that in my entire programming career, and every bit of your code is already loaded into memory once you start the program - at a special, protected part of memory. There's no reason to ever allocate anything manually. And I spent a lot of time trying to figure out how to deal with this issue when writing malware, since I kind of expected that once you try to allocate RWX memory manually, and god-forbid execute it the AV will simply not allow it and flag it as highly suspicious.

Well. It turned out that actually almost everything I've ever written does use this call. A lot. That's when I learned what "JIT compilation" means, and that I've really misunderstood the basic concepts of C#.

So, surprisingly, most of programs you run (that are in C#) actually inject executable code at runtime. Although, I'm not sure if Unity actually doesn't compile into something that's not JIT C#. I guess only if you use ILL2CPP?

the key to unlock them will not also be buried in the code.

“You have to sort of input it through playing the game, to the credits and some later sections,” he said.

With luck, that means no one will crack it until someone plays to the point of figuring it all out.

To decrypt AES you need some sort of a secret key or certificate. So the game will have to have it bundled.

If the Dev were to take, for example the x,y position of the player and convert that to a key, then there would not be any bundled key. This could allow specific conditions to be met without specifying the key or solution. Truthfully though, I don't know much about AES to know if that's possible.

Not really - "Everything is open-source if you know Assembly" - Look at Ghidra for example.

If code isn't obfuscated you can do an analysis what kinda stuff closed source software does. In C# (so if his game is written in Unity) you can even get very close to the original source code (IL code reversed back to C#).

That's why I mentioned anti-virus isn't going to be happy about it. You can easily google examples: examples[1] example[2] example[3] - that obfuscating is a red flag to a lot of anti-virus