71

I was curious if anyone had any experience/knowledge about aim bots in online FPS games such as Counter-Strike. I am curious and would like to learn more about how the cursor knows how to lock on to an opposing player. Obviously if I wanted to cheat I could go download some cheats so this is more of a learning thing. What all is involved in it? Do they hook the users mouse/keyboard in order to move the cursor to the correct location? How does the cheat application know where exactly to point the cursor? The cheat app must be able to access data within the game application, how is that accomplished?

EDIT: to sids answer, how do people obtain those known memory locations to grab the data from? EDIT2: Lets say I find some values that I want at location 0xbbbbbbbb using a debug program or some other means. How do I now access and use the data stored at that location within the application since I don't own that memory, the game does. Or do I now have access to it since I have injected into the process and can just copy the memory at that address using memcpy or something?

Anyone else have anything to add? Trying to learn as much about this as possible!

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
user105033
  • 18,800
  • 19
  • 58
  • 69

6 Answers6

76

Somewhere in the game memory is the X,Y, and Z location of each player. The game needs to know this information so it knows where to render the player's model and so forth (although you can limit how much the game client can know by only sending it player information for players in view).

An aimbot can scan known memory locations for this information and read it out, giving it access to two positions--the player's and the enemies. Subtracting the two positions (as vectors) gives the vector between the two and it's simple from there to calculate the angle from the player's current look vector to the desired angle vector.

By sending input directly to the game (this is trivial) and fine-tuning with some constants you can get it to aim automatically pretty quickly. The hardest part of the process is nailing down where the positions are stored in memory and adjusting for any dynamic data structure moving players around on you (such as frustum culling).

Note that these are harder to write when address randomization is used, although not impossible.

Edit: If you're wondering how a program can access other programs memory, the typical way to do it is through DLL injection.

Edit: Since this is still getting some hits there are more ways that aimbots work that are more popular now; namely overwriting (or patching in-place) the Direct3D or OpenGL DLL and examining the functions calls to draw geometry and inserting your own geometry (for things like wall-hacks) or getting the positions of the models for an aimbot.

Ron Warholic
  • 9,994
  • 31
  • 47
  • So someone uses DLL injection, now how exactly do they know what memory to access, trial and error process until they find what they are looking for?? – user105033 Nov 17 '09 at 15:36
  • 11
    Using memory readers/scanners, attaching a debugger, using specially built tools, or a number of other tricks you can watch values in the process's memory as they're changing and pause execution to examine the actual code that's executing. Typically to find a specific address you can take a snapshot of the processes memory, manipulate the one variable you want to read (such as moving your player), take another snapshot of memory and look at the values that have changed. – Ron Warholic Nov 17 '09 at 15:42
  • You don't need DLL Injection to access a programs memory. DLL Injection is used to execute code in the same address space as the target process. You can then use it to call upon functions that are internal to that process or trap certain calls. – mmcdole Nov 20 '09 at 04:15
  • however, isn't it probably possible that you need to write/read the memory of the process from inside it's address space as it might block other programs from doing so? – user105033 Nov 20 '09 at 19:35
  • @RonWarholic Can you please elaborate on the method of address randomization? I could not find any articles about it. – VSZM Jan 24 '14 at 00:29
  • All of the major OS's now use [ASLR](http://en.wikipedia.org/wiki/Address_space_layout_randomization) as an additional technique to prevent an attacker from using the known layout of memory to write malicious code to a critical point. With ASLR the attacker must first find the block of interesting memory they wish to attack before modifying memory. – Ron Warholic Jan 24 '14 at 14:58
  • @RonWarholic how come "reading memory" of game process still works? I understand this worked in Windows 95, but now we have process memory protected from each other. Reading memory of process from another process would require being a kernel. Is it done using debugging API? I don't know about Windows, but similar to Linux `ptrace`? Is there no way to ask kernel to forbid debugging of a process? – Michael Pankov Nov 29 '17 at 13:32
  • 2
    @MichaelPankov While I don't write cheats after talking to some colleagues it appears you can still access the memory in another process so long as you obtain sufficient privileges. Obtaining them just requires launching the process with the token set and having the user (running the cheat) confirm it. See https://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx – Ron Warholic Dec 01 '17 at 20:59
  • What would be the most effective way to prevent cheating? In the end, I came up with the idea that all calculations (player positions, hit calculations, etc) should no longer be carried out on the client at all, as this would always result in the possibility of reading/manipulating (game process, network packets, etc). If everything is executed on a server, and only the video signal goes to the client, and input device events are sent to the server, many cheats should no longer be possible - at least until similar effects with real-time image recognition can be done. What do you think? – Grimm Feb 05 '21 at 10:50
  • Most games already put as much as reasonable on the server side including things like just sending delta-compressed values and culling based on viewable objects. Most of these games have shied away from sending a pure video signal because there is a lot of additional latency involved. Cloud gaming is something of a different topic but it avoids cheating (and has other advantages) at the cost of latency and ownership. Look at Google Stadia or Xbox cloud gaming for examples of this. – Ron Warholic Aug 13 '21 at 19:14
13

Interesting question - not exactly your answer but I remember in the early days of Counter-Strike people used to replace their opengl32.dll with a botched one that would render polygons as transparent so they could see through the walls.

The hacks improved and got more annoying, and people got more creative. Now Valve/Steam seems to do a good job of removing them. Just a bit of warning if you're planning on playing with this stuff, Steam does scan for 'hacks' and if any are found, they'll ban you permanently

genesis
  • 50,477
  • 20
  • 96
  • 125
  • Ive just looked it up on their forum. It used to be one year, then two now its permanant. –  Nov 17 '09 at 18:47
  • Wrote one of these a while back. Had whitewalls + wh + a basic wireframe overlay to increase visibility :) And no, steam still does not detect it, if you replace your system's opengl32.dll – toster-cx Jan 07 '16 at 12:13
10

A lot of "Aim bots" aren't aim bots at all but trigger bots. They're background processes that wait until your reticule is actually over a target and fire automatically. This can be accomplished in a number of different ways but a lot of games make it easy by displaying the name of someone whenever your target goes over them or some other piece of data in memory that a trigger bot can pin point.

This way, you play by waving the mouse at your target and as soon as you mouse over them it will trigger a shot without your having to actually fire yourself.

They still have to be able to pinpoint that sort of stuff in memory and have the same sort of issues that truer "Aim bots" do.

Drew
  • 15,158
  • 17
  • 68
  • 77
  • 1
    That explains why I have seen some aimbots just shaking the cursor randomly around really fast, must be looking for names to pop up so it knows when to fire – user105033 Nov 17 '09 at 15:46
  • 4
    Nope...Screenshaking is caused by a "NoSpread" hack. NoSpread consists of reading from the game's "bullet spread randomizer", and immediately compensating for it. What this means is that the bullets will always go right where the hacker is aiming, and "there is no spread" (thus the hack's name). Similarly, there is "NoRecoil" hack, with compensates, or, more recently, nullifies (literally overwrites the game's recoil code with "do nothing" code) the guns recoil, maintaining the bullet spread, but making it a lot easier to aim. – CosmicGiant Apr 30 '12 at 19:39
10

Another method that has been used in the past is to reverse engineer the network packet formatting. A man-in-the-middle attack on the packet stream (which can be done on the same system the game runs on) can provide player positions and other useful related information. Forged packets can be sent to the server to move the player, shoot, or do all kinds of things depending on the game.

Alan
  • 4,897
  • 2
  • 24
  • 17
6

Check out the tutorial series by Fleep here. His fully commented C# source code can be downloaded here.

In a nutshell:
Find your player's x y z coordinates, cursor x y coordinates as well as all enemies x y z coordinates. Calculate the distance between you and the nearest enemy. You are now able to calculate the x y cursor coordinates needed in order to get auto aim.

Alternatively you can exclude enemies who are dead (health is 0) so in this case you also need to find the enemy's health address. Player-related data is usually close to each other in memory.

Again, check out the source code to see in detail how all of this works.

BullyWiiPlaza
  • 17,329
  • 10
  • 113
  • 185
5

Edit: I know this offtopic, sorry But i thought this would help out the asker.

The thing the hacking industry haven't tried out, but which I've been experimenting with, is socket hijacking. It may sound a lot more than it actually is, but basically it uses the WinPCap drivers to hook into the process' Internet connections via TCP (Sockets), without even going near the process' offsets.

Then you will simply have to learn the way the TCP Signals are being transferred and store them into a hash-Table or a Multiplayer (Packet) class. Then after retrieving the information and overlay the information over the Window (not hooked), just transparent labels and 2D boxes over the screen of the windowed game.

I've been testing it on Call of Duty 4 and I have gotten the locations of 4 players via TCP, but also as Ron Warholic has said: all of the hacking methods won't work if a game developer wrote a game server to only output the players when the current user should see the player.

And after cut the transmission of that player's location as for the X Y Z and player will no longer be stored and not rendered there for stop the wallhack. And aimbots will in a way stall work but not efficiently. So anyway, if you are looking into making a wallhack, don't hook into the process, try to learn WinPCap and hook into the Internet signals. As for games, don't search for processes listing for Internet transmissions. If you need an example that utilizes this, go search Rust Radar that outputs the player's location on a map and also outputs other players around you that is being sent via Internet transmissions TCP and is not being hooked into the game.

Callum
  • 725
  • 6
  • 17