Store
Subscribe
BAC and Post-launch Memory Modding Exploits
Heyo, new thread for this since the other one is for quite a different strain of technical on-goings.

I want to state my concerns over the potential for bypassing BAC measures by using RAM snapshots and memory mapping/modding techniques to effectively "Hot-Plug" loaded mods.

A generic memory mapping tool(Such as Cheat Engine) can track and determine offsets for programs injected into the Minecraft(Or in this case, forge, boot. This can then be used in conjunction with the creation of small mods in normal Forge to determine where certain mods begin and end.

An example of this would be by loading normal forge, installing 2 arbitrary and 2 special case mods. The special case mods would contain specified memory changed by triggers which could be used in Cheat Engine or equivalent to find their offsets in the JVM. Then, you can try to reshuffle the loading order until you can willingly manipulate mod order and locate offsets.

Then by taking mods from the Client and finding their sizes or noticeable differentials - you could effectively create a map of mods in the Client. All previous steps could now contribute to a C program capable of determining mod offsets in a given launch.

Now, an "illicit" mod which has been bulked with junk data to the size of one of the other mods in memory can be constructed.

Then, you can take a live memory dump of a Badlion Client instance run with a slowed or disabled JGC and replace the desired offset and size.

The result is a Badlion instance with a mod which has been loaded after BAC checked the system and has effectively bypassed it.

To prevent this, add lots of "scramble data" to disguise the differentials with identical differentials at completely different offsets to prevent any such memory mapping from occurring - therefore preventing this exploit from working.

It is entirely possible such a system is already in place in which case ignore this post.
 0
PM Link