- Home /
Does code wrapped in #if UNITY_EDITOR appear anywhere in builds?
Hi all,
Does code wrapped in '#if UNITY_EDITOR' appear anywhere in builds in a way that could be reverse engineered and discovered by malicious users?
I know that the code itself would not be executed, but I'm wondering whether it would appear anywhere at all in the final build (as plain text, for example).
Thanks!
Theoretically, anything in the build can be reverse engineered. Someone with enough patience can always analyze the binary inside the file and figure out what your code is.
However, there is a difference between the build and the source. The source code contains human readable code which is easy for programmers to develop in. The build contains machine language, which the machine can run. Because the machine can't use source code, it wouldn't make sense to put it in the build, since that would be a waste of space.
When you have something like #if SO$$anonymous$$ETHING, and SO$$anonymous$$ETHING isn't defined, you can think of the enclosed text being physically removed from the file before compilation, but your source code won't be in the build either way.
A more practical use for this is to decrease file size in the final build. You don't need $$anonymous$$ac code on the Windows version or Windows code on the $$anonymous$$ac version, so using #if will help reduce the size of each build.
Answer by Pharan · Sep 18, 2015 at 05:45 AM
No, it's not included in the build. None of your C# or js code will appear in the build as plain text. Everything is compiled into Common Intermediate Language (IL for short). IL is a translation of your code that's faster for the runtime to read and execute. It's much less readable, but it can still be translated back into C#. There are tools that can make your code more difficult to read even if it is translated back. (read up on .NET obfuscators)
But regarding #if UNITY_EDITOR. The #if check happens at compile time and if the condition isn't met, whatever is inside it won't be included in the compilation. It won't be turned into IL. It won't be in the build.
So reason why "the code would not be executed" is because it won't be there at all.
@BMayne poses a good question though. What are you doing in there that's so dangerous?
I'd like to add that if you are storing passwords as string literals and they get compiled, it's easy to recover them even if the code is obfuscated. (You can't really obfuscate a string literal.)
A more secure way to include passwords in the build is to hash them beforehand. Here is a website that hashes a string: http://www.sha1-online.com/
When you type in the string "Hello" into the box, you'll get this string back: "f7ff9e8b7bb2e09b70935a5d785e0cc5d9d0abf0"
The idea is to implement (or find an implementation of) a hashing function and store the hash of your password. For example, if your string is "Hello", you will store "f7ff9e8b7bb2e09b70935a5d785e0cc5d9d0abf0" in the code.
Then in your code, ins$$anonymous$$d of checking if what the user types is equal to the password, you take what the user types, put it through your hash function, and then compare the result to the hash that you stored.
In pseudocode (if your password is "Hello"):
bool matchesPassword(string whatThePlayerTyped) {
return myHashFunction(whatThePlayerTyped) == "f7ff9e8b7bb2e09b70935a5d785e0cc5d9d0abf0";
}
Answer by BMayne · Sep 18, 2015 at 02:17 AM
Hey there,
When you say "can be discovered by malicious users" what do you mean? Do you have passwords baked into the preproc?
Cheers
Thanks B$$anonymous$$ayne. I think Pharan covered the answer.
Answer by Dave-Carlile · Sep 17, 2015 at 10:30 PM
This is called "conditional compilation". That symbol isn't defined when doing a build, so the code inside of it can't appear in the build because it doesn't exist.