Closed ronjam1337 closed 1 year ago
There are a few reasons why this might occur: If you are injecting with a native manual mapper it will fail to inject the module as the cheat is a .net assembly, While inheriting the name as a DLL it actually doesn't hold a dllmain function to be loaded by Windows. Therefore requiring another managed function to initialize it into memory. You should move to an injection method either involving a mono stub to initialize a native call to load an assembly in the mono library and call a function such as monoruntimeinvoke with the correct parameters.
If you are using a mapper that maps a native mono stub into the game then there are 2 possible issues: 1) You are trying to inject with Battleye enabled while your mono injector can't establish a handle to the process. In this case, just disable Battleye. 2) You are initializing the wrong function. The correct function is Hag.Loader.Load()
Another potential issue is a new update within the game has changed the assembly properties of a linked assembly which could cause it not to run, normally a clear exception is thrown.
If you're struggling with Battleye interfering, you can move to Linux where the module is probably still just a heartbeat system to support compatibility. The last time I tried to mess with Battleye on Linux they lacked integrity checks on all their games, lacked vm checks, and lacked handle restriction systems. It was just a 15kb heartbeat library.
There are a few reasons why this might occur: If you are injecting with a native manual mapper it will fail to inject the module as the cheat is a .net assembly, While inheriting the name as a DLL it actually doesn't hold a dllmain function to be loaded by Windows. Therefore requiring another managed function to initialize it into memory. You should move to an injection method either involving a mono stub to initialize a native call to load an assembly in the mono library and call a function such as monoruntimeinvoke with the correct parameters.
If you are using a mapper that maps a native mono stub into the game then there are 2 possible issues:
- You are trying to inject with Battleye enabled while your mono injector can't establish a handle to the process. In this case, just disable Battleye.
- You are initializing the wrong function. The correct function is Hag.Loader.Load()
Another potential issue is a new update within the game has changed the assembly properties of a linked assembly which could cause it not to run, normally a clear exception is thrown.
If you're struggling with Battleye interfering, you can move to Linux where the module is probably still just a heartbeat system to support compatibility. The last time I tried to mess with Battleye on Linux they lacked integrity checks on all their games, lacked vm checks, and lacked handle restriction systems. It was just a 15kb heartbeat library.
had the same issues, looked at logs, cheat isnt loading dependency's
I forgot that you have to import the Sharpdx libraries. You will need to add the nuget packages(https://www.nuget.org/packages?q=Tags%3A%22SharpDX%22): "Sharpdx", "Sharpdx.direct2d1" and "sharpdx.dxgi"
How you map them into the game is up to you. Unlike normal dependencies, they can't be loaded in the managed folder if you wish to play on a Windows system with Battleye. MSDN states that the assembly.load function will load external references. So no matter their directory relative to the game they should be loaded. This is good to note if you plan to deal with Battleye and don't want to touch the manifest at runtime. For use without Battleye just throw the sharpdx dlls into the managed folder and the cheat will load them.
Hopefully, that fixes the issue.
How do I implement it into the game. I knocked it down, but when injecting it there is not showing