!nostupidquestions is a community dedicated to being helpful and answering each others' questions on various topics.
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rule 1- All posts must be legitimate questions. All post titles must include a question.
All posts must be legitimate questions, and all post titles must include a question. Questions that are joke or trolling questions, memes, song lyrics as title, etc. are not allowed here. See Rule 6 for all exceptions.
Rule 2- Your question subject cannot be illegal or NSFW material.
Your question subject cannot be illegal or NSFW material. You will be warned first, banned second.
Rule 3- Do not seek mental, medical and professional help here.
Do not seek mental, medical and professional help here. Breaking this rule will not get you or your post removed, but it will put you at risk, and possibly in danger.
Rule 4- No self promotion or upvote-farming of any kind.
That's it.
Rule 5- No baiting or sealioning or promoting an agenda.
Questions which, instead of being of an innocuous nature, are specifically intended (based on reports and in the opinion of our crack moderation team) to bait users into ideological wars on charged political topics will be removed and the authors warned - or banned - depending on severity.
Rule 6- Regarding META posts and joke questions.
Provided it is about the community itself, you may post non-question posts using the [META] tag on your post title.
On fridays, you are allowed to post meme and troll questions, on the condition that it's in text format only, and conforms with our other rules. These posts MUST include the [NSQ Friday] tag in their title.
If you post a serious question on friday and are looking only for legitimate answers, then please include the [Serious] tag on your post. Irrelevant replies will then be removed by moderators.
Rule 7- You can't intentionally annoy, mock, or harass other members.
If you intentionally annoy, mock, harass, or discriminate against any individual member, you will be removed.
Likewise, if you are a member, sympathiser or a resemblant of a movement that is known to largely hate, mock, discriminate against, and/or want to take lives of a group of people, and you were provably vocal about your hate, then you will be banned on sight.
Rule 8- All comments should try to stay relevant to their parent content.
Rule 9- Reposts from other platforms are not allowed.
Let everyone have their own content.
Rule 10- Majority of bots aren't allowed to participate here. This includes using AI responses and summaries.
Our breathtaking icon was bestowed upon us by @Cevilia!
The greatest banner of all time: by @TheOneWithTheHair!
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.
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.
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.
Sometimes they reverse engineer enough of the code to modify it.
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.
All software breaks down to assembly so you can reverse engineer it. What's lost is function names, variables etc. https://github.com/mytechnotalent/Reverse-Engineering
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.
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.
To be more exact, usually games additional dlls, and they will first try to load ones from the same folder as the exe, so you can modify or add a dll and whrn the game calls it make the modifications you need. So no need for a secondary process that monitors the game, but it is kind of hacking the game.
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.
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:
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, same data, etc). 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. (This is what we call code reflection - you can reflect the game's types in your own code. If you're using the same compiler as the original, even better!)
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:
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.
As an extension to this, many games use interpreted languages, essentially another language before it gets made into machine language, which makes decompilation much more easy and readable since you're already working with a higher level programming interface.
Mostly with Unity games or games that use lua scripting.
True. But even in this case, the same code injection logic can apply (depending on where you make the changes). The IL itself can simply be seen as yet another platform.
A great example is Android - you can patch the .dex class files with Lucky Patcher (in cases where apktool smali changes cannot help you).
IL obfuscations may also be worked around by patching the IL code directly too, which depends on the use case again.
The gist always is - carve out a space for your own code. No matter the language, a computer program is a computer program.
Many moddable games are made in Unity and C# which is trivial to decompile and modify.
Also the fact that most games use one of the mainstream engines and are made using standard tools and practices makes this easier.
For mono Unity stuff, I'll use dnSpy (by way of the dnSpyEx fork) to decompile the game, test changes by editing the DLL directly with it, then port everything over to BepInEx in some form or another.
The hard way. Exactly how hard depends on what tech the game is built on. Easy access to code and assets is typically lost when "building", but you can often decompile things at the cost of losing names for things, comments or whatever. A trained eye can still tell what's going on in the resulting mess, and make any desired changes. Some projects intentionally try to make it harder in various ways, with obfuscation and attempts at tampering detection.
A similar exception (because it can get pretty complicated) is the modding API Nemo mentions. You implement an interface (contract outlining what your code can do) and the game calls your code at what it decides is appropriate times, like updating every frame or when it's time to draw custom stuff. This can help make sure different mods don't instantly conflict if they try to mess with the same part of the game.
Decompiling. Use ILSpy for games coded in .NET for example. You take a .dll for the game that you think contains the code that controls the behaviour you want to change. You decompile it. You change the code and recompile it. Then you replace the original .dll with your new one.
Sounds easy, but the tricky thing is that decompilers only parse what the code does, and if the code was compressed of obfuscated, it usually doesn't provide what the coder called the variables and functions to indicate what they were for. So a function that was coded as:
function damagePlayer(characterRef *Player, int damage) {
*Player.health = *Player.health - damage;
}
It will look like this after decompilation:
function func238(objRef *var4748, int local1) {
*var4748.param35 = *var4748.param35 - local1;
}
So a lot of the effort is interpreting what these functions actually do then replacing the generic names. The hints come from when they are called (if the game can be debugged, you use breakpoints to pause the program when that code is called).
If there is a common engine or way programs are compiled, people develop libraries that work for many games, and all you have to do is have the library hook into the spots of each game where it does the common things like load resources or manage global variables, to have them loaded from a separate additional files rather than replacing everything (See BepinEx for example). Then that saves people work from having to compile and replace files themselves, and they can get right to changing the code where they want to. Then more modding tools make the earlier modding tools easier to use, so on and so forth.
Sdks
Plug in architectures
Api
Dynamic loading libraries (DLL) static can work too with the right version patch
And if you're really adventurous? Inject code into that process and you're not going to have access to the source code but you're going to have access to the assembly/machine language and get a really good idea what it's doing and now to manipulate it!