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 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.