yukieiji
commented
4 days ago This isn't a bug. As the error states, it just failed to create the cache, but the UE has been loaded.
Seems like the same bug as #22 Will other mods work?
Closed Max5923 closed 3 days ago
yukieiji
commented
4 days ago This isn't a bug. As the error states, it just failed to create the cache, but the UE has been loaded.
Seems like the same bug as #22 Will other mods work?
Max5923
commented
4 days ago I have been able to load my own mods. The game I am attempting to load UE on does have anticheat, but I do not think that the anticheat is triggering the crash, as when trying to load mods while not disposing of the anticheat, it first starts and runs a loading screen, then reopens the game and once it reopens it crashes. When disposing anticheat and running UE, it crashes immediately on startup.
I assume this is a different bug than #22 as in their error log the mod does not load, but like you said, the mod had loaded in on my log.
One thing I am curious about is "at UniverseLib.ReflectionUtility.CacheTypes(Assembly asm) in F:\Documents\VisualStudioProject\AmongUs\UnityExplorer\UniverseLib\src\Reflection\ReflectionUtility.cs:line 121". Why does it reference AmongUs at all? Another curious thing is the usage of the D and F drive, when I only have a C drive, although I'm not sure if that is normal.
Another thing I've just noticed from the log is that it seems to be UniverseLib that is failing to initialize, and not UE.
Max5923
commented
4 days ago Sorry, misclick. Still getting used to using github issues.
Max5923
commented
4 days ago My bad, I found out that I was actually using net6preview and not CoreCLR in the first post. I got confused with which version I was running, as I had tried to run all of them, and assumed they gave the same error. Looking into their errors, they seem to give their own respective errors. The regular non-CoreCLR/non-net6preview seems hopeful, as it just gives an error saying its missing a dll and boots up without crashing: Latest.log Attempting to insert the missing dll in UserLibs unfortunately just gives a similar error to the net6preview that had the F drive AmongUs error, but this time does not crash the game: Latest.log Trying CoreCLR out just gives the same error log as the first post, as well as crashes the game: Latest.log Retrying net6preview to see if I did anything now interestingly gave the same error log that the regular non-CoreCLR/non-net6preview gave, instead of the error log in the first post. It also did not crash the game: Latest.log Attempting to insert the missing dll on this version seemingly gives a different error log compared to the non-CoreCLR/non-net6preview error when reinserting that missing dll, and does not seem to reference the F drive or the AmongUs folder. It still gives an error though, and UE does not work, but it does not crash the game: Latest.log
I also tried installing a different fork of UniverseLib, by Baydock (version 1.5.4.1), on the net6preview and instead it gave me a different error, which instead of pointing to an AmongUs folder in the F drive, it points to someone's personal BTD6 folder on the C drive: at UniverseLib.ReflectionUtility.CacheTypes(Assembly asm) in C:\Users\xande\Documents\Documents\Btd6 Mods\Mod Projects\UniverseLib-NewML\src\Reflection\ReflectionUtility.cs:line 124 (Note: My windows user is not xande) Latest.log I'm going to attempt to install other versions of UniverseLib later to see if it will make the mod run. I might also try to build the UniverseLib dll, as I assume that is the dll that is giving trouble, as it seems to have a file path inside it that points to a specific personal file instead of a generic file. If I do, I'll attempt to find and change the path that it's searching for to my own path, and see if that makes UniverseLib not error, and subsequentially make UE run.
yukieiji
commented
3 days ago One thing I am curious about is "at UniverseLib.ReflectionUtility.CacheTypes(Assembly asm) in F:\Documents\VisualStudioProject\AmongUs\UnityExplorer\UniverseLib\src\Reflection\ReflectionUtility.cs:line 121". Why does it reference AmongUs at all? Another curious thing is the usage of the D and F drive, when I only have a C drive, although I'm not sure if that is normal.
The path you see here is the path to the folder when I build with C# and has nothing to do with the behavior or error. It just references the folder on my PC when I build UE locally. Originally it was created and released in GitHub actions, but due to a mistake, it was just released in my local version (either way, it just changes the path to start with C:\a).
This is the result of embedding the line in the file where the error occurred so that the C# side can easily identify the error.
I have been able to load my own mods.
Can you access game objects instead of anti-cheat disabling mods?(https://github.com/yukieiji/UnityExplorer/issues/22#issuecomment-2342849437 )
It's important that mods that access game objects work, not mods that change behavior (UE accesses game objects by its nature, so if it fails to do so, it will not work).
For example, GameObject.Find (“Hoge”) works after the game starts.
The regular non-CoreCLR/non-net6preview seems hopeful, as it just gives an error saying its missing a dll and boots up without crashing: Attempting to insert the missing dll in UserLibs unfortunately just gives a similar error to the net6preview that had the F drive AmongUs error, but this time does not crash the game:
It doesn't work in v6.0+ of MelonLoader as stated in the README.
Retrying net6preview to see if I did anything now interestingly gave the same error log that the regular non-CoreCLR/non-net6preview gave, instead of the error log in the first post. It also did not crash the game:
As stated in the README, this type is for v6.0 alpha of MelonLoader and will not work otherwise.
I also tried installing a different fork of UniverseLib, by Baydock (version 1.5.4.1), on the net6preview and instead it gave me a different error, which instead of pointing to an AmongUs folder in the F drive, it points to someone's personal BTD6 folder on the C drive: at UniverseLib.ReflectionUtility.CacheTypes(Assembly asm) in C:\Users\xande\Documents\Documents\Btd6 Mods\Mod Projects\UniverseLib-NewML\src\Reflection\ReflectionUtility.cs:line 124 (Note: My windows user is not xande) I'm going to attempt to install other versions of UniverseLib later to see if it will make the mod run. I might also try to build the UniverseLib dll, as I assume that is the dll that is giving trouble, as it seems to have a file path inside it that points to a specific personal file instead of a generic file. If I do, I'll attempt to find and change the path that it's searching for to my own path, and see if that makes UniverseLib not error, and subsequentially make UE run.
As I mentioned above, it's just a different path.
This error is just a failure to create the cache, not a failure to load UE and UniverseLib. In fact, the UE is displayed as “[00:05:29.190] [UnityExplorer] Initialized UnityCrashPrevention for: Canvas.get_renderingDisplaySize” and the initialization process is complete.
Max5923
commented
3 days ago My mistake, error logs always get me caught up in assuming the wrong problem.
I have been able to access GameObjects, and have called functions inside of their components. Also, the "AntiCheatDisabler" was actually my own dll, I just used that as a dummy name that I never changed.
Good to know that the CoreCLR type is the correct one to use, I was lost on which to use as the README links to the correct one, and I downloaded the types through the releases instead of the link. Really, it was my fault for not just looking which was the correct one to use, though.
So if I am understanding this correctly, the problem is that the game is when UE/UL attempts to cache a dll, with the dll being Il2CppRewiredCore? Or is the error from attempting to cache UE/UL? Whichever one it is, it attempts to cache it, which to my knowledge means inserting it into the games memory. When it tries to, it gives an error stating that what it is trying to cache is in an incorrect format. Does this mean that there is an error in what it is trying to cache? Google searching the error appears to show me that this error is due to a conflict in trying to either load a 32bit dll into a 64bit machine, or load a 64bit dll into a 32bit machine. I checked using notepad++ and found that the dll was a 32bit dll, and I have a 64bit machine. I'm going to assume this is the error, and I will attempt to build both UE and UL on my machine as a 64bit dll.
yukieiji
commented
3 days ago I have been able to access GameObjects, and have called functions inside of their components. Also, the "AntiCheatDisabler" was actually my own dll, I just used that as a dummy name that I never changed.
What code did you run?
So if I am understanding this correctly, the problem is that the game is when UE/UL attempts to cache a dll, with the dll being Il2CppRewiredCore? Or is the error from attempting to cache UE/UL? Whichever one it is, it attempts to cache it, which to my knowledge means inserting it into the games memory. When it tries to, it gives an error stating that what it is trying to cache is in an incorrect format. Does this mean that there is an error in what it is trying to cache?
This error log that UL tried to get the namespace from the type information at that time, but MelonLoader could not find the dll with its type. C# namespace is just a string and doesn't affect the behavior.
I think this game has anti-cheat or some kind of protection because it is a game with multiplayer content. UE is a well-known reverse-engineerable mod, which is why it is detected at startup and crashes, isn't it?(As in #22 )
Max5923
commented
3 days ago I found out that my method of finding whether the dll was 32bit or 64bit was flawed, as all .net binaries read 32bit. I confirmed this as all the dll's that I have built, working ones or not, gave the same readout. It was worth a shot, though.
The code I was able to run that accessed game objects was
if (Input.GetKeyDown(KeyCode.F)) { GameObject playerBall = GameObject.Find("PlayerBall"); GameObject playerCamera = GameObject.Find("PlayerCamera"); playerBall.GetComponent<BallMovement>().m_ballJumping.DoJump(playerCamera.GetComponent<Transform>().rotation * flingball * shiftDown, BallJumping.Jump.Default); }
This error log that UL tried to get the namespace from the type information at that time, but MelonLoader could not find the dll with its type. C# namespace is just a string and doesn't affect the behavior.
Does this mean that this error is not what is causing the crash?
I think this game has anti-cheat or some kind of protection because it is a game with multiplayer content. UE is a well-known reverse-engineerable mod, which is why it is detected at startup and crashes, isn't it?(As in https://github.com/yukieiji/UnityExplorer/issues/22 )
The specific anticheat used is CodeStage's anticheat-toolkit. The documentation for their cheat detector is here.
Out of these, it seems to be that these are the only classes used:
It seems like the only thing that's detecting any modifications would be "ObscuredCheatingDetector", in which I have disposed of it before it would get a chance to detect UE, as my mod is initialized before UE initializes through this code
public override void OnInitializeMelon() { Il2CppCodeStage.AntiCheat.Detectors.ObscuredCheatingDetector.Dispose(); LoggerInstance.Msg("Initialized."); }
I'm confused on the inner workings of this cheat detector though, as it doesn't seem like something that would be able to detect any dll's based off of the description, yet the game will crash on loading just the regular dll without disposing of it. The ObscuredCheatingDetector is described as
"Detects CodeStage.AntiCheat.ObscuredTypes cheating.
It allows cheaters to find desired (fake) values in memory and change them, keeping original values secure. It's like a cheese in the mouse trap - cheater tries to change some obscured value and get caught on it.
Just add it to any GameObject as usual or through the "GameObject > Create Other > Code Stage > Anti-Cheat Toolkit" menu to get started. You can use detector completely from inspector without writing any code except the actual reaction on cheating.
Avoid using detectors from code at the Awake phase."
Which seems like it would only detect a cheat if one of their obscured types was changed? Yet it will crash the game when just loading in an empty dll.
On further inspection, it seems like my dll doesn't crash the game if you don't dispose of ObscuredCheatDetector. It also seems to run more "smoothly", as loading in and out of a level several times would cause a crash, but now it doesn't. I'm going to attempt to add UE back and see if the game will allow it.
Attempting this is still resulting in a crash, unfortunately.
It could be an internal anticheat detector then, possibly? I'm going to look through the Assembly-CSharp in dnspy and see if I can find anything that may cause it. It's unfortunately hard to read though, as it's in IL2Cpp.
Further inspection on the unity addon page for the anticheat shows three things of note
yukieiji
commented
3 days ago Does this mean that this error is not what is causing the crash?
That's right. It is working even in an environment with these errors. And even if this error prevents the cache from being created successfully, it's still a dictionary key error that occurs, and I highly doubt it would cause a crash.
It seems like the only thing that's detecting any modifications would be "ObscuredCheatingDetector", in which I have disposed of it before it would get a chance to detect UE, as my mod is initialized before UE initializes through this code
Is it possible that the anti-cheat is enabled again before the dll loading comes in at game startup? If it is working as if the memory address isn't modded before this anti-cheat is enabled, then it would be consistent with the behavior you mentioned.
Also, UE has patches that change the behavior of some games to make them work, and those patches may have been detected and crashed.
Max5923
commented
3 days ago Is it possible that the anti-cheat is enabled again before the dll loading comes in at game startup? If it is working as if the memory address isn't modded before this anti-cheat is enabled, then it would be consistent with the behavior you mentioned.
I think the anticheat detector I "disabled" wasn't actually doing anything, as I double checked to make sure and found out the game would launch without crashing with just my dll.
Also, UE has patches that change the behavior of some games to make them work, and those patches may have been detected and crashed.
I think this is likely the issue. I've found running code like
GameObject[] allObjects = UnityEngine.Object.FindObjectsOfType<GameObject>(); string allObjectsOut = ""; foreach (GameObject obj in allObjects) { allObjectsOut += (obj.name) + ", "; } LoggerInstance.Msg(allObjectsOut);
Will cause some variable to be set such that it makes the game crash on the next loading screen. It's very likely that this is what is causing the crash upon startup, the same detecting engine is causing a crash. Unfortunately, I don't think it will be as easy as disposing of a CodeStage anticheat class, as it is likely self-implemented in some class. I'm not sure if the CodeStage anticheat obscured the dll, or if it's just il2cpp, but the code has been very hard to read through dnspy. Here is an example, I'm not sure if this is normal for il2cpp games.
I'm going to attempt to see if Ghidra will work better.
Since I have seemed to make a conclusion on what caused the crash, and what is required to stop the crash, I'm going to close this thread unless anything else comes up. Thanks for your help!
Are you on the latest version of UnityExplorer?
Which release are you using?
MelonLoader IL2CPP CoreCLR
Which game did this occur on?
The error occured on the game "Golf With Your Friends".
Describe the issue.
When I attempt to run the current version of the mod, I receive an error in the command line stating that
Can't cache type named UserData Error: System.BadImageFormatException: Could not load file or assembly 'Il2CppRewired_Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format. File name: 'Il2CppRewired_Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' ---> System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.I've tried to transplant another version of the Il2CppRewired_Core.dll from generating the binaries of another game, and it still caused the same error and crash. I've opened Il2CppRewired_Core.dll in dnSpy, and it seemed like it was obfuscated, which I am unsure of if that's the reason for the crash, or if it is being caused by another issue. Here is a list of the types in my Il2CppRewired_Core.dll I found under - in dnSpy:
// // // Types: // // <Module> // ADSKVxZJSFkDyMGJKnlKUBorZhuD // apEvzhCxScCyCSOHWwpxJiwGvlOo // bizhSGSkbYKHLUAwUjJldBHmyZwq // BlhfMSqWdxGGmkrOLnhytYOWBVcP // BxbbvKXhLYllwMlNukVwsgZhBIs // dFGwIisbtfHayiNXiRBRWpMCngGv // dpvxMMmJEhBJrUwdSFTnDVVoyLgw // dstOEBNmmscQlBZCGAeCouKxcgRQ // DXYiJElpUHxcPboaihvPaElwMWxMA // ETACFlGzLpkmJUgQBNxlitBebFfv // fltsBxmjXaFeMfcWglOfHGHvtAQsA // GNnLMzlpRKtFyJlexoafWNjfiSkf // gQqXfkghDzUgcWaoRfIdjveCqyDU1 // gQYWqRhlmkWRkkrRpWjcmQltnfCL // HRAHJFkTwSqevhcmQwYIThdxMwDV // HuFUPnVcilGVsLkOQFTNYtvJAVLr // iFznRwzhmJipMjcfRBhjJauAXkUOA // KGyXcQaLGGZtNCDwgVDdxdqugFiH // KpZHreySesbtLKuRdoZrwgpLSyTA // LjmiwQfcsmzrgAYaHEMKGLaOgKjY // lnDNmgCdAUoldOfPbHChIcFoEfFjb // lwbDySfvDdBYvtcCsmSJyxKynhnkA // mBIXidehYIjLbvtFXjheYIRokVnD // NhrfGoMHswTOhjaTEzxQNlazmLzs // NOmcgiGIPdinZrJCvEdthFVCcmsfB // NzUoNPoCfhLLQcCzMeSoVLbTCJUZ // OEuVELDCsRumlPkXSwgznDfnuYZm // OHBxQeqzwpSOXtKiahobKGuCdFjeb // ozJCNCgYiYUtKitDXELFzszuhHbtA // OzuwuQspMvDmFgaYlkFgVUjXOREyA1 // PfGsjQeDIWurWNVMIWGjsffAaCvbA // QIWwagBAXYMCADTyurJfrujRcSdb // qmEcFrQmpjkfExHMGEuMliRmNVKH // rAPtcpHLzzLbzFhqkNsLlgjZFneJA // RfFMKuqZhISUwrYUdqXdXiowfWsg // rTFRhglKgUYuRjbuHfpVdAGUmulr // sEFlMWgexWIvWAvMGQUwmUTmbxg // SqcPYTpnQyvIBscTNAfMBNAZXxSE // sQUhNuelsgdElREOuzBUnZbPDjkc // SZQINXtHteyLWtnGxgZphVQOpmrib // tGuhVMgjQuttsfzYtqPAxiAztnUe // TWLwCilJIoPozLulqzpoQBubYmDC // uwbgviXXIJPMnGJRVuzdFTgToYVv // UWIIAtBOdpDpfAgqZwbpKxabtOzhA // xaijMTONWGaQwpgcGMXwxXYSGTBf // xExZPlwOYSQiIkFqHDDyWovrVnsK // xfYwdkRYAVrddGoiGqMNEgTVIqto // xiZMFJaKprrLjxtEMQahBCVGvYER // XTAWmQhXpkHzzvqvLihzDrWEQCIv // YCtNtFhGhsVodFBjxRMexOEjLQUl // YPEGKdGlyEszNjScuARgURDzbRAc // zbJLZSTqDWgGDxfpkJCsEboqOzbu // ZCUdBedUUjmCBSWhOAJNcgvTbdyn // ZdahRlzMRHmytynTlBGzlbkkdrOo1 // Module // PrivateImplementationDetails `Everything else in the binary doesn't seem obfuscated, so it could be that it was incorrectly generated by MelonLoader. I attempted to get the binary using Il2CppAssemblyUnhollower off of the Il2CppDumper dummy dlls, but it uses the same generator called Mono.Cecil that MelonLoader uses, and it generated the same dll.
Relevant log output