Many games today are prereleased in an alpha/beta state and instantly overwhelmed by "hackers" downloading programs manipulating the game itself to become overpowered.
I guess they make injections into certain memory addresses in runtime but I have no clue of how to go about to create a program like that. Also, how do you prevent it?
Any suggestions of how they do this are greatly appriciated.
The more details, the better!
Your question is really broad. I can tell you about how I did in one instance, for fun, in a small arcade game several years ago. This should make you gain some educational insight, but won't help you much otherwise, I'm afraid.
I simply had another program running in background, scoping the memory of the arcade game.
I started playing, and then I lost one life. Hit both shift keys -- and a snapshot of the memory was saved to disk unbeknownst to the running arcade. Then another. BAM another snapshot. A third, and a fourth. And then game over and I exited the arcade game.
Then I just compared the snapshots, looking for a memory location that changed from one snapshot to the next, either increasing or decreasing by exactly one. I remember finding some twenty of them. I could have checked all of them, but I spotted immediately that one among them, and only one, had value "five" at the start of the game, and became "four" on my first death. And I had started with five ships. Now that's interesting...
So I wrote a small program that would look for that memory address, recognizing it by its distance from other pieces of code and strings that didn't change, checking its value every few seconds, and just poking back "5" into it as soon as it became anything less:
: install
look for string 'COPYRIGHT ACME GAMES'
add 1138
is it a five?
no, abort, something went wrong
yes. lie in wait.
: wait
is it still a five?
no. Set it to five.
sleep for a couple of seconds
goto wait
Sure enough, the next game, I died - and an instant later, my four remaining starships became five again. For the heck of it, I discovered that I could get up to seven 'lives' with this method (eight crashed the game).
By using a "debugger" it would also have been possible to stop the program as soon as the location was modified, thereby seeing which instruction had done the deed. Then you would just blot out that one instruction from the assembler code. Or you could follow the program flow in reverse, and discover where, for example, the collision check was made between your player's sprite and the enemy missiles'. Thwart that check, and the enemy missiles no longer affect you (possibly, also yours no longers affect them; it's a tricky business).
I expect the techniques to have matured and progressed a great deal in these years, but I'm confident that basically the idea is still the same - spot the change you don't like, then either defang the code causing it, or patch the code so that the damage is undone as soon as it happens.
To make things more difficult one could devise strategies to make the changes stand out less, or make them seemingly random. Add "chaff" or "dummy" variables that change just as if they were useful. Use them as telltales - if all variables don't tally, it means that someone is trying to hack.
In the end, however, you can't beat a determined and experienced hacker. All you can do is try making the deed not worth his while. There are code obfuscators, code protectors, code encryptors, debugger detectors, anti-virtualization techniques...
There are several attack vectors for an online game.
Automation
Some games, especially from the more grind-oriented MMORPG spectrum, have methods of advancement which are extremely simple. All the player needs to do is press the same sequence of buttons or do the same mouse clicks over and over again. Such a gameplay mechanic is an invitation for an automatization using a simple macro program which emulates keyboard- and mouse input.
But in most games, the player needs to pay at least a little bit attention. That means the makro program needs to know what's actually happening in the game. This can be done by examining the memory of the client application (Iserni has already covered this aspect in his answer) or by examining the netcode.
Reverse engineering the netcode
The client and the gameserver communicate with each other by sending and receiving network messages. There are programs like Wireshark which can be used to monitor this network activity. When you can monitor that activity, this gives you electronically readable input for your macro.
But it might also give you information the player isn't even supposed to have. The servers of most first person shooters, for example, tell the client about the positions of all other players and then rely on the client to only render those which are actually visible to the player. When the hacker finds a way to visualize this information to the player, this can give them a great advantage.
Tools which can read network traffic often also allow to inject messages into the network data-stream. This can also be used as an advanced form of automatisation.
Hacking the client
So far we were only using external means and didn't touch the client. But it can be much more comfortable for the player to put the automation and information disclosure directly into the client software so it gets better integrated into the game. Hacking executables is a very wide and complex field. People have written whole books about the subject.
But basically it boils down to finding points in the program where the flow of execution jumps from one section of code to another. The hacker would modify this jump-instruction so it doesn't jump where they are supposed to jump but jump into the hackers program code instead. After the hackers code got executed, program flow jumps back into the original game code and it continues as if nothing happened.
Writing your own client
Modifying a compiled executable without access to the original sourcecode is a very complicated and uncomfortable way of doing software development. When you want to develop more complex features, it could be easier to start from scratch and just develop your own game client.
So the hacker would write a new program which implements the network protocol of the game. When that program communicates with the server in the exact same way the original client does, there is no way for the server to detect that. The hackers client would of course not focus that much on an immersive game experience but only on maximizing the success of the player by visualizing all information available and automatizing everything which requires skill (or is just boring).
