How do target bots work in fps games?

I was curious if anyone had any experience / knowledge about target bots in online FPS games like Counter-Strike. I am curious and I would like to know more about how the cursor knows how to block the opposite player. Obviously, if I wanted to cheat, I could download some cheats, so this is more of a training thing. What is everyone involved in it? Do they grab the mouse / keyboard of users to move the cursor to the right place? How does the cheat application know exactly where to point the cursor? A fraudulent application must have access to data in a gaming application, how is this done?

EDIT: The answer to the question, how do people get these famous memory cells to capture data? EDIT2: Lets say that I find some values ​​that I want in the 0xbbbbbbbbb location using a debug program or some other means. How can I now access and use the data stored in this place in the application, since I do not own this memory. Or now I have access to it, since I injected it into the process and can simply copy the memory to this address using memcpy or something else?

Does anyone have something to add? Trying to find out as much as possible about this!

+62
c ++ c hook
Nov 17 '09 at 15:21
source share
6 answers

Somewhere in the game memory there is an arrangement of X, Y and Z of each player. The game must know this information so that it knows where to depict the player’s model, etc. (Although you can limit how much the game client can know only by sending him player information for players).

Shooting can scan known memory locations for this information and read it, giving it access to two positions - the player and the enemies. Subtracting two positions (in the form of vectors) gives the vector between the two, and it is just from there to calculate the angle from the vector vector of the current player to the desired angle vector.

By sending the input directly to the game (this is trivial) and fine-tuning with some constants, you can make it automatically aim quite quickly. The hardest part of the process is that the positions are stored in memory and adjusted for any dynamic data structure that moves players around you (for example, rejecting a truncated cone).

Note that they are more difficult to write down when address randomization is used, although this is not possible.

Edit: if you are interested in how a program can access another program memory, a typical way to do this is through DLL injection .

Edit: since this is still happening with some hits, there are more ways the Telibots work, which are now more popular; namely, rewriting (or fixing in place) a Direct3D or OpenGL DLL and examining function calls to draw geometry and insert your own geometry (for example, for wall hacks) or to obtain model positions for an aim sight.

+67
Nov 17 '09 at 15:29
source share

An interesting question is not exactly your answer, but I remember that in the early days of using Counter-Strike, people replaced their opengl32.dll with unsuccessful ones, which would make polygons transparent so that they could see through walls.

The hacks improved and became more annoying, and people became more creative. Valve / Steam now seems to be doing a great job of eliminating them. Just a little warning, if you plan to play with this material, Steam checks for “hacks”, and if they are detected, they will constantly ban you

+13
Nov 17 '09 at 15:31
source share

Many "Aim bots" are not targeted bots at all except launch bots. These are background processes that wait until your reticule actually exceeds the target and automatically fires. This can be achieved in several ways, but many games make it easy to display someone’s name when your target views them or some other piece of data in memory that the trigger can indicate.

Thus, you play by waving the mouse on your target, and as soon as you hover over them, you will launch a shot without having the ability to shoot.

They should still be able to pinpoint this material in memory and have the same problems as the real "Aim bots".

+10
Nov 17 '09 at 15:36
source share

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

+9
Nov 17 '09 at 18:34
source share

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

In a nutshell:
Find the coordinates of the player xyz, the coordinates of the cursor xy, as well as the coordinates of all enemies xy z. Calculate the distance between you and the closest enemy of the closest . Now you can calculate the xy cursor coordinates needed to achieve the automatic goal.

Alternatively, you can exclude enemies who have died (health is 0), so in this case you also need to find the address of the enemy’s health. The data associated with the player is usually close to each other in memory.

Again, check the source code to see how it all works.

+3
Oct 20 '15 at 11:01
source share

Edit: I know this offtopic, sorry, but I thought this would help the asker.

What the hacker industry has not tested, but with which I experimented, is socket capture. It may sound a lot more than it actually is, but it mainly uses WinPCap drivers to connect to the Internet Connection over TCP (Sockets) process, without even getting close to the process offsets.

Then you just need to find out how TCP signals are transmitted, and store them in a hash table class or multi-user (packet). Then, after extracting information and superimposing information on a window (not connected), only transparent labels and 2D windows on the window game screen.

I tested it on Call of Duty 4, and I got 4 players places via TCP, but also, as Ron Warholick said: all hacking methods will not work if the game developer wrote the game to display players only when the current user needs to see the player .

And after the transfer of the location of this player was cut out, as for XYZ, and the player will no longer be saved and will not be shown to stop Wallhack. And the sights will work, but not efficiently. One way or another, if you are creating a wallhack, do not connect to this process, try to study WinPCap and connect to Internet signals. As for games, do not look for a list of processes for webcasts. If you need an example that uses this, go to the Rust Radar search, which displays the player’s location on the map, and also displays other players around you who are sent via TCP webcasts and not connected to the game.

+2
Aug 04 '14 at 12:42 on
source share



All Articles