Standalone build has files for cheating

Found in Unity 2020.2.3f1

After the Standalone build is complete, you can find the RuntimeInitializeOnLoads files in the Data folder.json ScriptingAssemblies.json

The engine crashes when deleting the ScriptingAssemblies.json file

RuntimeInitializeOnLoads.json as I already understood loads classes from the assembly by calling a static method

Code (CSharp):

1.  
2. [{"assemblyName":"Assembly-CSharp","nameSpace":"","className":"CheatUI","methodName":"_init","loadTypes":1,"isUnityClass":false}
3.  

And here is the class itself which was embedded in the assembly using dnSpy

Code (CSharp):

1. public class CheatUI : MonoBehaviour
2. {
3.     private static void _init()
4.     {
5.         GameObject gameObject = new GameObject("s");
6.         UnityEngine.Object.DontDestroyOnLoad(gameObject);
7.         gameObject.AddComponent<CheatUI>();
8.     }
9.  
10.     private void Update()
11.     {
12.         Debug.Log("RuntimeInitializeOnLoads");
13.     }
14. }
15.  

You can do without embedding the code by simply specifying the assembly name in the Scripting Assemblies file.json, and then specifying the static method name in RuntimeInitializeOnLoads.json

 

I'm not sure what your point is? Those files are obviously required by Unity, no surprise that the game can crash if you delete files from the build.

You could argue that Unity makes it too easy? But then again, this already requires quite a bit of knowledge and there are many Unity modding frameworks out there, which will reverse-engineer whatever obfuscation Unity can put in.

Using IL2CPP will make things a bit harder and you can add integrity checks yourself. But client code will never be secure against someone determined to crack it.

 

The fact is that in previous versions these files were not present and the information about the attributes [RuntimeInitializeOnLoad] was packed in the bundle globalgamemanagers.assets, and now the files are open and anyone can edit them.

 

The information is a bit easier to access but it still requires compiling a custom assembly or patching the existing ones. Even before the json files, it was simple to get one of the Unity modding frameworks and inject custom code into Unity games. I don't feel that anything really changed with some information being a bit less obfuscated.

Your best bet is to file a bug report and see if Unity is willing to change this. The chance of the right developer seeing this here in the forums is pretty small.

 

In the Standalone IL2CPP build, there are also ScriptingAssemblies files.json and RuntimeInitializeOnLoads.json
I am sure that this will allow the creators of cheats to embed code in the game without injectors and other manipulations...
If this is how unity developers open up the possibility of modding games, then why not add a check mark to the editor?

 

Will Unity developers just ignore it?

 

They must. It's not possible to stop hackers from modifying data on machines they own.

Every second you spend thinking about it and every second Unity spends engineering something that is logically not possible (aka "making an untrusted computer safe"), is time wasted.

Read more about trusted computing to understand the issue at hand and the security perimeter. If you fail to understand that you will continue to insist that doing something is possible.

 

Why did you write that? This post is about the fact that the Unity developers left files that give a few more opportunities for code injection by cheaters. Why did they add these files? There is no explanation for this anywhere ...
Previously, information about builds was packaged in a bundle (globalgamemanager.assets), which could not be simply rewritten (at least, I do not know about programs that can do this)

 

You could have the world's most secure bicycle lock. Someone who really wants to steal your bike, will steal it.

It doesn't matter if it's now "easier" to inject code in your game as someone who wants to do it will just do it even if you use obfuscation, encryption, quantum entanglement or pagan witchcraft. Anyone with enough determination will eventually break through it.

People cheat in online games that have dedicated teams working on security you really think you could stop them from cheating in a game running locally?

 

Aa.. good... Let's see how your game will break even when it is obfuscated and compiled in il2cpp...

Before you respond with metaphors read all the messages

 

Some people here are clearly missing their intellect check on this subject, arguing that no lock is ever safe, when the problem is that your locksmith has added without informing you a simple knob to circumvent the need of the key or any lockpick system, making it easier while taking extra time !
No idea how to summon an official, won't bother, it looks like yet another weird and infuriating move from Unity.

 

There is no lock. There's only security through obscurity. The door has always been there, open for anyone who knows how to use a search engine. Unity never built in any protections, the files and formats are simply there for technical reasons.

I'm not arguing that security by obscurity is totally useless or that how easy things are does not make a difference. I'm arguing that the ScriptingAssemblies.json file is a red herring, its presence or absence doesn't actually make hacking/modding any more or less difficult, considering the wider context today. Anyone who's knowledgable enough to make use of the file is also knowledgeable enough to modify a Unity game without it.