How can I completely hide and protect strings from the player in Unity?

Question

I have been using Unity to create a 2D game which will be completely offline (which is the problem), the game-play needs you to enter certain strings at certain levels and Unity compiles to DLLs, which can be easily reverse engineered, so is there a way to protect those strings (the game is offline so I can't retrieve from other source)?

The game relies heavily on those strings, and yes I'm aware of Obfuscation but I want something more robust. And I know that the easy way out would be doing everything online from a data-source but I was wondering if it's possible.

It can be decompiled like this:

Answer 1

Do not store those strings, store the (cryptographic) hash of them.

A (cryptographic) hash function, like encryption, is a way to turn a string into "gibberish" (called hash), but unlike encryption, you cannot get the original string from this hash (unless you can brute-force it or the hash function is broken). Most (if not all) hash functions takes a string of arbitrary length and returns a string of a constant length (depends on the function).

How do you check that a string that the user has entered is the correct one? Since you cannot get the valid string from the hash, the only thing you can do is to hash the user's guess and compare it to the correct hash.

Warning (by Eric Lippert): DO NOT USE the built in function GetHashCode as such a function - its result can differ between different .NET versions and platforms, making your code work only on specific .NET framework versions and platform.

Answer 2

What you are trying to do is both futile and pointless.

It is futile because there is no way to properly hide information which is on the user's machine. Anyone dedicated enough will find it. You can make it harder, but you can never prevent it. If you encrypt it, then you need to store the encryption key and algorithm somewhere. No matter how many layers of encryption you add, the outmost layer will always need to be unencrypted in order for your game to run.

It is also pointless, because we are living in the internet age. When your game becomes just remotely popular, then those passcodes will be posted all over the web.

All you can do is trust the player to not ruin their own game experience by looking up information the game isn't supposed to tell them yet. The vast majority of players will not start reverse-engineering your game anyway. And if the few who have the necessary skills do this, then it's their own fault.

Answer 3

If such a thing is really desired, then instead of hashing, you might consider building the strings from a numeric input value at runtime.

The advantage is that as pointed out by @Philipp, it is somewhat pointless to try and hide codes in the executable if you can expect them being posted on the internet anyway. Hashed or not, the same word found on the internet and entered into the game will give the same hash and will work either way.

Except... except if someone else's code doesn't work for you. Which you can trivially do -- not 100% tamper-proof but reasonably hard to work around for the average user. Anything as simple as the "Online Elven name generator" will do (can be arbitrarily simple, really doesn't need much of a markov text gen engine, pulling 4-5 syllables from a random list is good enough).

Just generate a somewhat user-specific or machine-specific number, it doesn't even have to be perfectly unique or very tamper-resistant. Something that is likely different for most people, and unlikely to change regularly, e.g. the computer's network name, the MAC address, or the GUID of the system disk drive, whatever (the GPU serial number might be a very bad idea since users are likely to upgrade GPUs). Add to that the numeric code the unlock code refers to, and feed that into your word generator. But be prepared to answer support queries when players use two computers or change their network card (which is unusual, but not impossible). It might be a good plan to only generate the random ID once, and store it with the game's settings. That way, at least it doesn't break existing installations on the same machine if something changes.

Or, you might just use the game's serial number which is unique and will work if the user changes hardware (ironically, however, this might promote pirating since shared unlock codes work for pirated serials but not for legitimate customers!).

Note that preventing users from cheating is not necessarily a good thing. In an offline (i.e. non-competetive game) it's usually no problem if the user cheats and gets the codes from somewhere rather than from playing. He is only cheating himself. Who cares.
On the other hand, getting too much in their way if they really wish to cheat is a great opportunity for completely pissing off paying customers.

So... before you do something that way, think very thoroughly whether you really want that, and what you want. Quite possibly, having human readable strings (or trivially made "unreadable" with xor) is just good enough and indeed preferrable.

Answer 4

If you don't need to show the strings, then the hashing idea is probably the way to go. If, on the other hand, you do need to show them to the user, there are some other ways you could avoid them showing up in your DLL directly.

One way to deal with this besides encrypting or otherwise obfuscating the strings is to break them up. Maybe just a have an alphabetically sorted dictionary of all the possible words from all the strings in the game. Then have an array somewhere that allows you to piece together the words into the string you need by indexing into the array of words. This way you don't have the complete strings anywhere in the game. There's no master key needed to decrypt the strings. And the data that tells their order could be all over your source, if, for example, each function that used a string just had an array of indexes local to the function. I'm not sure how practical that is in your specific case, but it's one way of doing it.

You might even have string composed of a few words, but they end up put in different orders. For example, you might need the following 2 strings:

1. A bear walked through my house
2. My house protected me from a bear

Your list of phrases would contain both "a bear" and "my house", but you'd have a large list of other phrases that could be put in between them, so figuring out which one would be just as hard as actually figuring out the puzzle in the game (or whatever). For example, the action phrases could be "walked through", "burnt down", "pushed over", "protected me from", "separated me from", "magically produced", etc.

You could work this into your game by making the indexes be based on something the player has collected or done. So there'd be no master list of indexes anywhere inside the game. They would be generated by the player playing the game.