https://www.gamefile.news/p/indie-developer-has-a-plan-to-keep
Plus: Why another game creator is daring to make his game solvable in four minutes.
Unfortunately we all know what happens when you tell hackers that something's going to be very hard to break into.
I understand that they were excited about the idea and wanted to share it with gamers, but if they actually wanted to give the system the best chance of success, they should've kept their mouth shut.
at least it probably saves you from the worst fate: that nobody cares about the game enough to try to discover the things
(I'm fairly sure that datamining is not that common outside highly popular games, well assuming the data isn't neatly in plaintext)
Considering it’s being published and promoted by a huge YouTube video game channel it’d never be likely to stay under the radar.
It was a really interesting food for though, especially since both cybersecurity and game development are my main areas of focus (I work part time in offensive security, and part time as game dev). I has actually motivated me to start considering that I might give data-mining this game a try, because I'm really interested in how he wants to solve the many issues present.
I'm betting it would probably be mostly leaning into "security by obscurity", but if that's the case, throwing a gauntlet like this wasn't a good idea. Because every technically sound solution I came up with was a nightmare from game design standpoint, and I couldn't came up with any puzzles or secrets that wouldn't be extremely complex, mostly because you just require a really large problem and input space for it to not be brute-forcable at any of the reverse-engineerable stages.
Also, I have a soft spot for clever marketing tactics, and this one is amazing.
I was always aiming towards just being a gamedev, but since there weren't many Bachelors degrees at the time focused on that, I went for Software Engineering, and then Masters in gamedev. However, experience working for alongside school in QA for a bigger gamedev company has kind of made me realize that corporate and AAA gamedev isn't really art, and you're basically the same code-monkey as you would be anywhere else, just for a lot less money. And since at the time I just played Watch Dogs 2 and was running a Shadowrun campaign, I was pretty into hacking at the time, solving CTFs and generally researching into it, which was prompted by one optional class on pentesting.
So I decided that since working in gamedev will probably leave me burnt out and with lot less money, I just applied for part-time cybersecurity job so I could finance my hobby gamedev career that's not limited by the fact that it's my livelyhood and I have to make money - and that makes every kind of art so much better. I still went for Masters in Gamedev, though. And after several years, the cybersec company started to turn more and more corporate, and I was offered a job at a small indie studio made of mostly friends, so I switched from full to part-time, and took another part-time for a lot less money but with an amazing work environment.
Besides that, Red Teaming is basically just LARPing Shadowrun, it sounded like the perfect job, just trying to talk and hack you way into banks and corporations, I couldn't say no to that :D
Basso is at least confident that data miners can’t brute force their way to discovering his encrypted secrets. He’s using industry-standard AES encryption. ”It's pretty secure, unless we get quantum computers or there's some giant vulnerability,” he said.
It's a fun idea, I guess, but I don't know how happy anti-virus kinda services are with having loads of very encrypted and obscured blocks of data.
It's a bit of a "trust me bro" situation where he claims he's just hiding secret levels and stuff - and isn't also secretly side-loading malware or something like that
Anti viruses won't care as it won't be injecting executable code. But the whole idea won't work. To decrypt AES you need some sort of a secret key or certificate. So the game will have to have it bundled. Thus anyone with enough skill will be able to extract such key or certificate and decode resources themselves. Encryption will not provide any protection.
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.
I bet you that the whole thing will be decrypted and sent to torrents during the first hour of the game's release just to teach its developer a lesson.
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
Modern CPUs and operating systems have distinction between data and code in memory. Usually only privileged processes have the right to make data executable. If you load some random stuff into memory and tell your CPU to execute it as a code, you'll get nuked by OS.
Usually only privileged processes have the right to make data executable.
Not true. Only kernel can mark memory page as executable, but any process can request to kernel to do so. This is why JIT compilers work.
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.
You still need
It's a bit of a "trust me bro" situation
i mean, the same could be said of literally any closed source software.
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
All your examples are obfuscating executables. None of which is happening here. Every software that connects to the Internet handles encrypted data and there is nothing suspicious about it.
If code isn't obfuscated you can do an analysis what kinda stuff closed source software does.
And what does that change in it being a "trust me bro" situation? Nobody does that. Are you reverse engineering all software you use, don't use any software that has an ability to update, and compile all software you use yourself? Because otherwise you are trusting the developers.
We are talking about a video game. The vast majority of games on PC are released through launchers like Steam which keep updating them. You'd have to spend months reverse engineering a game to know for sure it doesn't do anything you don't like, and disable updates. Nobody does that.
I don't know how happy anti-virus kinda services are with having loads of very encrypted and obscured blocks of data
As happy as with any other file. Would be pretty silly if preloading a game on Steam pre-release would trigger AVs.
I can't really imagine how would this work in practice. While "I'm using industry standart AES encryption" may mean the cypher and the key itself will not be breakable, the bigger issue is how to get the 256b key from the player. Does he expect them to actually figure out and manually input 265b of data? That would be a pretty hefty game design challenge to make something like that possible.
I'm betting there's probably something that generates the key from a vastly smaller player input, i.e what gameobjects you interacted with, in what order, or what did you press/place somwhere. But that also means that the entropy is probably in the bruteforcable range, and once you find the function that decrypts the secrets, it should be pretty easy to find the function that generates the key, and the inputs it takes.
The only A solution to keeping data from data-miners I can imagine would require just storing the key on the server - which could generally also be bypassed, since then you probably need a way to request the key, which could be data-mined and faked, so you're back at step one - how to validate requests for the key.
Or just make the secret puzzles so difficult, that they can't be brute-forced and the result really is 256b or more of data. Thinking about it, having specified 256 inputs you either have to make or are red-herrings that shouldn't be interacted with isn't really that much, but then the data-miner can just check the location of each one and filter out the inaccessible, and bruteforce the rest. And if all are accessible, it would make for a really difficult secret to discover properly.
I'm betting there's probably something that generates the key from a vastly smaller player input, i.e what gameobjects you interacted with, in what order, or what did you press/place somwhere. But that also means that the entropy is probably in the bruteforcable range, and once you find the function that decrypts the secrets, it should be pretty easy to find the function that generates the key, and the inputs it takes.
When handling passwords, it is standard practice to use an intentionally costly (in CPU, memory, or both) algorithm to derive the encryption key from the password. Maybe the dev can reuse this? The resulting delay could easily be masked with some animation.
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.
Ultimately you can configure these however you want. On my 5600X, I easily got one full execution of scrypt to last 34.6 seconds (--logN 27 -r 1 -p 1 in the example CLI), and one full execution of bcrypt to last 47.5 seconds (rounds=20 and the bcrypt Python library).
This kind of configuration (ok, not this long, but definitely around 1 second per execution) is very common in things like password managers or full disk encryption.
I apologise as I know next to nothing about how this all works - so ELI5 please:
Based on what you explained here, could the game designed in theory put those 256 bits of key into 256 puzzles - with several hundred more puzzle pieces being red herrings?
But were you making the point the data miner could just then target the thing that accepts those puzzle pieces and reads the key from them?
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.
Great explanation (including the pre-edit bit ha) - thank you!
When you say the cypher puzzle wouldn't be much fun - why not? Surely you could have a set of puzzles through the game that each yield a keyword (seemingly plot relevant, but still pretty random when combined with the others) and the player has to combine all of them via clues in game in the correct order to yield the correct key. That doesn't sound unfun on the surface?
I am guessing it will just be sharded and hidden throughout the code in areas that get triggered as you play though the game.
The only real question is if it is quicker to find it in the code or to play though the game. IMO that is all a bit pointless as once it is cracked it will be cracked. All this does is maybe buy a few hours after launch (assuming the game files are not predownloaded before then) at best before all the info is available online. And now they have announced this quite a few will take it as a challenge and I doubt it will really slow anyone down.
I hope people respect this until parts of the game have been found.
This is a better reason to encrypt parts of a game than any anti-piracy measure
Dude is effectively open challenging data-miners. Regardless of how people feel about them, this is going to motivate them to try.
Even if this one game limits them until things are found, the techniques likely won't work again as the data miners will then look at how they could have discovered the keys given knowledge of how to find them.
This is what is meant by it being an arms race.