How can I prevent players from reading a puzzle solution out of the game's code?

Question

I'm sure you know of the part in Five Nights at Freddy's 3 where you input the reverse of the hex code for purple into a wall and something happens (I forget what).

I want to implement something similar in a game I'm making, but I'm worried about people looking at the code for the game or hacking into it to figure out what to do.

I wonder whether fnaf somehow prevented people from just decompiling the code and seeing what code to enter. How could I do something similar?

Answer 1

The first step is managing expectations.

Remember that "the client is in the hands of the enemy" — if you're making an offline game, then you're giving your attacker both the lock and the key. If the game is able to verify the solution to the puzzle, then a skilled attacker can use that verification routine to determine the solution to the puzzle.

You can make it somewhat more challenging, but for the sizes of solutions that are comfortable for a player to deduce and enter through play, it's still likely to be computationally tractable to brute-force.

The only way to make it properly impossible to work around is to take the key out of the client entirely, putting any secret information on a server you control, and restricting access to it (say, no more guesses per hour than a player could execute by hand)

That said, there are things you can do to make finding the secret less trivial — hopefully to the point where playing the game seems like a more fruitful and enjoyable way to solve the puzzle than hacking at the code. I wouldn't invest a lot of effort here, since as pointed out above a determined adversary will win, but we can raise the bar to block "mildly curious" adversaries cheaply enough, if they're all you expect to face.

One simple route is using a cryptographic hash function.

You take your puzzle solution, add some extra characters to it (a "salt"), then hash the combined text. What you get out is some blob of random-looking bytes that isn't your solution anymore, and should (for a well-designed hash function — use a well-studied one, DO NOT invent your own) resist decoding it to reveal the original input.

You put this hash value and its salt into your game data. When your game wants to check if the player entered the right solution to the puzzle, it takes the text the player entered, adds the salt to it, and hashes the result. Because you're using the same salt and same hash function, the output will exactly match your saved hash value if the player entered the right solution.

So now your game can check the solution to the puzzle even without the literal solution being present in the code or data.

(This is how websites and other software verify your login credentials without storing your password where a bad actor could easily find it)

This can still be defeated, of course. An attacker can build a program that exhaustively runs each possible answer through this salting and hashing process until they find a match, but at least they can't just glance at your binaries and read the answer in plain text, or look it up in a rainbow table.

(What they might do instead is just replace your check function with bool IsAnswerCorrect(string answer) { return true; } and skip the puzzle entirely to just find out what's on the other side — but again, you can't stop this unless you hide all that stuff on a server out of their reach)

So while it's not ironclad, this hashing approach is reasonably quick and cheap to do with standard components, so at least you're not going down a rabbit hole fighting a war you won't win. You can hack this up in half an hour or less, feel a bit better that your puzzle isn't completely trivial to cheat, and move on to other features that have a bigger impact on player experience.

Answer 2

1)Scan for dll injections.

2)Scan for memory hooks.

3)Check compiled source code memory pages checksum sometimes.

Its 3 most popular ways to hack.