• 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.

    •  sus   ( @sus@programming.dev ) 
      link
      fedilink
      7
      edit-2
      3 months ago

      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)

    • 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 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.

    •  nous   ( @nous@programming.dev ) 
      link
      fedilink
      English
      13 months ago

      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 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?

  • 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

      • 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

        •  dev_null   ( @dev_null@lemmy.ml ) 
          link
          fedilink
          2
          edit-2
          3 months ago

          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.

    • 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.