I know some games will actually release modding tools, but if I had to guess I would think those are the exception, not the rule.
Thanks in advance!
I do this quite a lot myself.
Beside the games that do officially support it via modding APIs, or older games that are just naturally extensible like Unreal Engine games that ship with an editor; it is usually done by the way of code injection.
Think of code injection like a manually placed interrupt - you modify the flow of execution at some point to execute your own code.
For this, you need something known as an entrypoint - place where mod code begins executing. Usually, at the entrypoint, the mod code bootstraps itself further.
To obtain an entrypoint, you have 2 options:
- On supported OSs, you can abuse dynamic library loading and make a library wrapper which masquerades as the original library. When its execution begins (on Windows this is usually very early in the importing stage, on Unix/Linux you need to swap functions), you can bootstrap your mod(s) further.
- On other systems (game consoles, embedded, etc), you have to modify the game executable directly. Either via the way of memory injection of another tool or direct binary modifications. Depending on the platform, if it supports loading of libraries, you would either load your mod as a library or, if not, inject the mod elsewhere into memory (slack/unused space).
How do you figure all of this mumbo-jumbo out? Well, you use tools designed to disassemble the game binary into machine language. Most popular examples are IDA, Ghidra and Binary Ninja.
You usually won’t have any information on what’s what, but if you know a bit about code design of games, you come to realize that a lot of them follow similar principles/patterns (depending on the era and platform), so you can probably figure it out once you’ve seen a few games. Especially if the game is using the same game engines as others, then you can cross reference stuff.
However, if you’re lucky, you can obtain something known as debugging symbols which have all of the information about the generated binary. Ideally, it’d be for your executable that you’re working with directly, but if it’s not, you can usually just cross reference it by either binary pattern matching or simple deduction (same execution flows). This will give you a nice map of where’s what in your disassembler tool.
Thanks to standardization of binaries, ABIs (Application Binary Interfaces) usually allows you to match the types as they’re defined originally and have them work directly in your bespoke code. This means, for example, that if a function takes 3 arguments, those 3 arguments will be passed in the same way (depending on its calling convention), so you can expect to receive them in your own code the same way.
And, ideally, you would be working with code directly and not with machine language, but some lower level stuff will need it inevitably.
Usually, in your mod source code, you would work with a library that is specifically designed for code injection. This is effectively a JIT compiler which emits machine code instructions which are needed to redirect the flow of execution to your own modded functions. (Usually is capable of memory editing and making branch instructions)
There are 2 ways to perform a code modification:
- Inlined code - this means you write your own code in the middle of another game function. Usually, this is done via lower level assembly and a branch instruction to put it in. Requires decent knowledge of the target CPU to use it (to not corrupt any stack or registers)
- High-level function hooks - this usually means that you interrupt a function call/branch with your own equivalent. Your equivalent function will have to do the job of the original usually, but depending on the case, you may replace it outright or simply pass the call onto the original function. Thanks to ABIs, this is possible.
With all of this being said, you need to have the knowledge being able to read machine language of CPUs. This isn’t too difficult once you realize RISC CPUs are mostly very similar at a glance which helps out a lot.
But, in order to be able to read it, you have to first obtain it and, as we all know, DRMs, executable packers and anti-cheats/tampers protect this, so you may need to get your hands dirty a bit to bypass that (e.g. memory dumps). A lot of the same tricks that security researchers use in their rulebook apply to modding as well.
I hope I’ve explained enough. I’m aware I used a bunch of terms that may be foreign, so I hope you will get the gist at the very least.
Nemo@slrpnk.net 20 hours ago
Sometimes they reverse engineer enough of the code to modify it.
Or sometimes they leave the code alone and just modify data files.
But often, even without tools, there’s a modding API that tells would-be modders how to interact with the game as a black box.
CallMeButtLove@lemmy.world 20 hours ago
Oh interesting, I never knew about modding APIs. I have almost 1,000 hours in Kerbal Space Program, all modded. But I just assumed it was so moddable because people are really familiar with Unity.
cecilkorik@lemmy.ca 19 hours ago
Yes, that’s a big part of it. Unity-based games generally follow most if not all of the framework that Unity defines, and since Unity itself is very well understood mechanically, that makes it very easy to find the right places to inject mods directly in between the game itself and the Unity DLLs that the game calls to act as a middleman or even completely replace the functionality that one side or the other would otherwise be implementing, and with that you can either create a mod on your own, or create a reusable modding API/framework for other mods to connect to. It’s not quite as straightforward as modding a game that is intentionally designed to be moddable, but in general, it’s pretty trivial once the basic setup work has been done and it’s almost the same for almost any Unity-based game so it’s not hard work to repeat on new Unity-based games either.
schipelblorp@sh.itjust.works 20 hours ago
I guess this is the real question. What is this process exactly? I always imagined it was looking at what variables were in memory, manipulating them to see what changes, making an educated guess as to what the variable represents, and then creating a seperate EXE to constantly monitor and manipulate those values… but this might be my fanciful imagination, but it would at least explain why so many anti-viruses HATE mods.
TheKracken@lemmy.world 20 hours ago
All software breaks down to assembly so you can reverse engineer it. What’s lost is function names, variables etc. github.com/mytechnotalent/Reverse-Engineering
cecilkorik@lemmy.ca 18 hours ago
That’s possible in some cases but pretty rare realistically. DLL mods are much more common. Windows (and most operating systems) have the concept of what they call dynamic link libraries (DLLs) which are basically modules of reusable code that a program (like a game) can use. Now these are not the same as game mods, but its their inherent modularity that makes them useful for game mods. It’s also a big part of what triggers anti-viruses, as this is also a very virus-like behavior.
The trick is, anyone can trivially look at any DLL and see what functions are in it, and you can easily trick the game into calling a different version of any DLL file you provide, and the game won’t realize there’s anything different about it, it’s just expecting the same function names to be there but it doesn’t know if they’ll do anything different than it expects (this is often how viruses work too). There are many common well-known DLLs like Unity or DirectX or SDL that a game will often be connected to and calling into constantly in a very deep and profound way and this provides a great starting point for a modder to gain access to the game logic. Once you have identified a DLL like this for a particular game, you can replace that with your own DLL that either has the same functions, or (more practically) simply stands in front of the real DLL and hands all the functions directly to the real DLL as soon as they are called while also providing a branching point where modding code can start to develop.
Once you have direct access into the code paths that the game is calling, you can run your own code instead of, or in addition to, the real code it is calling, and from there it’s pretty much open season for modding. Once you’re changing or replacing the running game code in any form, that’s a mod. And usually the first layer that gets built at the DLL level is not a mod itself but rather a mod loader that instead of making any significant changes on its own, it’s only job is to intercept as much of the game’s logic as it can, then load other mods/DLLs to activate each one and pass control to them when needed or requested. This way, you don’t need every individual modder to be able to figure out the exact places to do all this DLL interception which would almost certainly conflict with each other since everyone would do it in a slightly different way and in different places. Instead modders can just follow the documentation of the initial mod loader/framework and have access to everything in the game that the mod loader is already intercepting for them.
This is what’s involved in making a game moddable. Sometimes developers do this work themselves, designing these access points into the game itself and provide their own mod loader and modding API. Obviously this saves a lot of work on the part of the modding community, but either option leads to pretty much the same place. These are what we sometimes call “code mods” or “core mods”.
There are also games where some or most of the game logic and graphics functions are modularized into datafiles. In this case, you don’t even necessarily need code mods for many things, depending on how much has been modularized into data, and how easy to acess that data is (often defined in text, XML, json, or other easily modified formats). You can also have mods that are just “data mods” where no game code is even changed at all, only the data files like swapping a 3d Model for a different model, or changing a texture to look different, changing the stats of an enemy or a weapon, or even adding content and whole new levels or areas purely with game data, and completely reusing and building on top of the existing code without modifying it.
Code mods and data mods like this are by far the most common modes of modding games today, but which methods exactly depends on the game and what is most suitable for it. Memory-access mods like you’re describing are typically the most challenging to develop, the most fragile to maintain, and usually the hardest to detect, which makes them most suitable for cheating but rarely suitable for genuine modding. Trainers, cheat engines, aimbots, overlays and other automations often take advantage of memory access, and likewise tend to flag on anti-viruses and anti-cheats for obvious reasons. It’s definitely possible to use them for legitimate modding but it is uncommon.
exist@sopuli.xyz 19 hours ago
Basically yes, you find which values in memory are changing when you do actions ingame, and you can also figure out which functions run etc. Then you can for example replace the function call with your own function. I can’t do this myself and it is very time consuming, you can watch tutorials on IDA or Ghidra to get a gist.
But often it is not that hard, c# or java dont get compiled into machine code and usually keep more metadata about the code, sometimes basically the original source code. Unity, Godot and UE all have some level of support (or reverse engined knowledge) for modding even if the game iteelf doesnt explicitly care about it. Of course it is much easier is the game is made with modding in mind though.