Considering it’s being published and promoted by a huge YouTube video game channel it’d never be likely to stay under the radar.

… you work in offensive security and… game development

Are you … Thor ? 😁

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.

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.

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?

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

Most of the costly algortihms I know of are still reasonably fast, i.e you can try thousands of checks per second, so it would definitely help, but you would then still have to design a puzzle that has a large number od possible answers or combinations - which I still think really limits what you can create with it.

He could design a check/hash that would take a lot longer than common algs like bcrypt, but then theres a risk of someone reverse engineering it and simplyfiing it, or even finding a vulnerabilty that makes guessing the key easier. Because its suprisingly really difficult to make a hash that is matematically ok and doesnt have side-effects. Especially since crypto is dealling with some obscure advanced math, and some of the vulnerabilities in existing algorithms are pretty mind-blowing - especially since the more math you stack up, the more chances are there of you unknowingly using some kind of obscure math laws that can be used to simlplyfi or predict the results of your algorithm.

For a really bad and simple example (that kind of illustrates the point) from the top of my head, if i was just multipliing the input by 2 to get the key, and i did it 1000 times, it would mean that 1) the attacker could make it faster by multiplying it just once by 2^1000, and 2) the result would always be even, so now he knows he only has to bruteforce half of the keys, since it cannot be any odd key.

Most of cyphers have some kind of decryption key, mostly between 256 to 4098 bits long. That means the (256 bit) key is 256 ones or zeroes (where order is important), so there’s 2^256 combinations you have to try. To quote a stack overflow question about it:

You’d expect to find it after going through (on average) half of the keys, so average expected number of attempts would be 2^255. This is a Really Big Number. If every atom on earth (about 1.3 * 10^50 atoms) was a computer that could try ten billion keys a second, it would still take about 2.84 billion years.

But, remembering and imputing 256 ones or zeroes (or one number between 0-2^255, if you convert it from binary to decimal, which is around 78 digits) is really difficult and infeasible in practice. Due to that, when you want to encrypt something for example with a password that is easier to remember, you somehow have to generate the 256b key from the password, usually using a hash function. Because hash functions are designed to convert mostly any input into a 256b (or other size) bit keys, while making sure that the 256b are randomly distributed - so if you for example change one letter in the password, the hash will be absolutely random (but still the same for the same input), with no way to tell that it has anything in common with the hash of the previous password.

However, this introduces a problem - if for example you only used 4 digit PINs for the password, all anyone needs to do now is to 1) figure out how you generate the 256b encryption key from the PIN (which is usually doable by reverse-engineering the code), and 2) try every 4 digit combination, generate a key from it and then see if that key decrypts the data. That’s only 6561 combinations, and can be done pretty quickly. So, by using the password that’s limited to 4 digit PIN, even though you are using a 256b key for encryption, you have reduced the number of keys that can be valid - because there’s only 6561 valid passwords, which only map to 6561 encryption keys out of the 2^256.

EDIT: I’ve realized that I’ve explained something you didn’t ask for, I’ll just keep it up for others, I didn’t read your question properly, sorry about that :D

For the game development, assuming the author wants to use AES, it would mean that either there is some kind of “password”, be it having to input a number, interact with game objects in certain order, or do some actions in order, out of which the key is generated. But then the answer has to be really complex (super-large number, or interacting with tens to hundreds of objects, or a long string), so the number of possible answers is large-enough that it can’t be brute-forced - which would make for a really hard puzzle. Even if you for example required the player to input a text password of some kind, it could get frustrating, since it would have to be pretty long to not be bruteforcable.

The other solution I was thinking about is that you would have 256 objects or puzzles, where represents one “digit” in the key. If you solved the puzzle, the digit would flip to 1. However, it would be easy to check from code which puzzles are connected to the key - because that’s what you are generating the key from. That would mean that unless you want the key to be all 1, some of the puzzles that are connected would have to be unreachable by the player (which can also be data-mined with some effort) or intended to NOT be solved, which does add more complexity and makes the puzzle even harder - those would be the red herrings.

could the game designed in theory put those 256 bits of key into 256 puzzles - with several hundred more puzzle pieces being red herrings?

Not exactly, because if you wanted to generate the key by solving 256 puzzles, it would mean that either the key is 256 ones, or each puzzle has a value - one or zero - it adds to the key. If that’s the case, then you can simply take the values from the puzzle code and generate the key like that. Having more red herrings wouldn’t help, because in code (which you can dissasemble and reverse-engineer with enough skill), there will have to be a function “UnlockSecret(key)”, and probably something like “key = CreateKey()”. And in the CreateKey function, you have to have only the puzzles that are not red herrings - otherwise the code has no way of knowing which puzzles to use for building the key. So a dataminer would just check the CreateKey function, and then check what exact puzzles are used for the key. That’s why the only option in this case is to have a 256 puzzles, where each is either completed (1) or uncomplete(0), and out of the 256 puzzles, some are red herrings that should not be completed (and stay at 0), and some that should be - and those add 1s into the key.

However, now that I think about, just having some kind of a cypher puzzle which gets you a password of 10-20 characters (that’s 10^29 options) would probably be enough. But then again - that’s not that much fun, and it greatly limits what you can actually design.

If you sell it, don’t expect people to abide by your wishes.