How to make cheats

Thread: How to start making CS:GO hacks

Thread Tools

Display

How to start making CS:GO hacks

Since many users on here have no idea how to code a simple bunny hop or trigger bot hack, let alone any C++ or C#, I am going to make a thread for any of you who wish to start CS:GO hack/cheat programming

First thing you must know, if you are learning C++/C# for the sole purpose to learn how to make a cheat you are wasting your time. I suggest you do this if you are thinking about taking up a career in any sort of computer programming related profession or hobby. This would most likely be the best position for you to be in if you want to take up this sort of thing in your free time and possibly a side-job. I suggest you really think about what you are getting into, are you going to use this some time later in your life or is this going to be a hobby? Job, or hobby? That is what you must ask yourself. There are two approaches to this depending on which you are going to do. If you want to take it up as a profession, this isn’t for you and I suggest you go pick up a C++ book or watch some tutorials on line from someone like thenewboston.

Now here is something I’m going to go over really fast before we get into anything more: Releasing your cheat publicly.
Releasing your cheat publicly sounds like something awesome, everyone loves you and you get a lot of respect, right?
No.
Releasing your cheat also gets you a lot of hate. «copypaster» «skid» «omfg im vac banned i fuoking hate u1!!»
Even if you aren’t a «copypaster» or «skid» they will still give you hate about it until the end of time.
If you really want to release it publicly, know it is going to get VAC detected in less then 3 hours. Happens to every hack on here.

If you don’t know how to use sendinput or mouse_event look up some examples online. Stackoverflow usually has people who ask questions and people usually respond with a good example.

Now this is all in CS:S, and you want to do it with CS:GO right? Well.
Its basically the same. Lots of people dump the offsets for the new updates on to MPGH, so sometimes you can get away with being lazy and not have to find the offsets yourself.
If you need to get them yourself, it should be the same process. Things might be called different in ollydbg but thats about it.

I hope this helps some of you, and for the people who read this entire thread congrats, you have the patience required to start doing this stuff.

How to make cheats

CS:GO Cheat Making 101

NOTE: This guide is still a HUGE work in progress. You can use the GitHub repo to push commits in order to modify and update this guide. Your help is important! *CLICK*

Structure of the guide: (prone to changes)
Chapter 0

Welcome to CS:GO Cheat Making 101! The requirements
Chapter 1

Explaining CS:GO
Chapter 1.1

Brief introduction to the Source Engine
Chapter 1.2

Different types of cheats
Chapter 1.3

Talking about VAC: Ring0 and Ring3 (OPTIONAL)
Chapter 2

External Cheats: The starting point
Chapter 2.1

Brief introduction to WinAPI
Chapter 2.2

Managing CS:GO memory: RPM and WPM
Chapter 2.3

Getting CS:GO module info
Chapter 2.4

Building a memory management class
Chapter 3

Offsets
Chapter 3.1

Using our class and the offsets to make our first bhop
Chapter 3.2

Netvars
Chapter 3.3

Getting offsets dynamically: Pattern Scanning
Chapter 3.4

Getting netvars dynamically: Netvar Managers and recursion
Chapter 4

Internal Cheats: The advantages
Chapter 4.1

Calling exported module functions
Chapter 4.2

CreateInterface: Getting those interfaces
Chapter 4.3

Hooking methods: VMT hooking
Chapter 4.4

A look at the Source SDK
Chapter 4.5

Common functions to hook
Chapter 4.6

A look at CreateMove: Making our first internal bhop
Chapter 4.7

Drawing using ISurface

Chapter 0
Welcome to CS:GO Cheat Making 101! The requirements

Hi and welcome to CS:GO Cheat Making 101, a «all-in-one» guide for CS:GO cheat making! Please notice that this guide is still a huge work in progress and it is prone to changes. Since I’m not really pro when it comes to CS:GO cheat making, I’d like you guys to help me building this guide and expanding it as large as possible. I’ll cover a lot (but not all) of aspects of CS:GO cheats and I’ll try to be as clear as possible.

Now, let’s take a look at the requirements for this guide. I see many people here trying to approach CS:GO cheat making (in various languages) just to make cheats for them. I mean, that’s great, you want to learn, but that’s not the right approach. If you have absolutely 0 knownledge of programming in general, following this guide will be really difficult, so from you I want to at least know one programming language and being able to think in terms of programming, you know what I mean.
Some people here even learnt a programming language by making CS:GO cheats, still it will be really difficult if you don’t have a certain «mindset» ready.

I’m not writing this guide with the purpose of showing my (near to no) knownledge about this stuff. I’m writing this guide as a starting point to many ppl out there trying to start in this sector. As I said some months ago, all I needed when I started here was a really solid base to learn from. In order to make this guide the best and the most complete guide about CS:GO cheat making, I need your help. The help of people with a real huge experience in this sector, that would be really great and you’ll sort of help this community.

Chapter 1
Explaining CS:GO

Counter Strike: Global Offensive (aka CS:GO), as many of you know, is a first person shooter game with a lot of focus on the competitive aspect. The game requires a certain set of skills and ability to pwn your enemies, and when it comes to skill we all know that. we’ll come to cheats! CS:GO is probably one of the most (if not the most) full of cheaters paid game, and the creators (Valve + Hidden Path Entertainment) can’t do anything for it. Throughout the various updates of the game, they’ve released several ways and workarounds to trying stopping cheaters (always failing), but in the end we all know that they won’t stop cheaters, for obvious money reasons. Getting a cheap CS:GO copy is really easy, as it is really easy to cheat. There are near to no protections compared to other paid games (well, don’t take me wrong, there are some cheap protections like untrusted checks but. ) and the community itself is full of cheaters. Just for example, this section of UC is probably one of the most visited and active UC sections (mods, get ready to prove the opposite).

But we are not here to talk about how full of cheaters CS:GO is, we are here to learn about making a cheat! This forum is full of references, tutorials, sources about how to make certain stuff for CS:GO, infact I’ll put at the end of each chapter a little list of reference links which I really recommend to read to get deeper on the concept explained in the chapter.

Brief introduction to the Source Engine

CS:GO runs on the Source Engine, a really famous game engine used to make a lot of games that we all know and love (a prime example is Half Life or Left 4 Dead).
The Source is well known for his great physics system (that we saw in action in HL) but in general it is a great engine to make games on. Another great advantage is his flexibility, which makes the life of modders way easier.

It is greatly documented on internet and here, and it’s (only in part) open source. This allows us to get a shit-ton of info about the game itself without needing to reverse it completely (don’t get me wrong, you’ll still need to reverse it on certain situations).
Since CS:GO is built upon the Source Engine, a large part of what we’ll do to modify the game (to get an advantage) is related to it, especially when we are going internal.

Different types of cheats

Before getting into cheat making, it’s important to know what are we going to do.
Usually (not only for CS:GO) there are 2 types of cheats: Internals and Externals.
The difference between those two types is huge:

An EXTERNAL cheat is an EXE which is able, through an HANDLE (think it like a bridge) to CS:GO process, to read and write memory. By reading and writing certain areas of memory we are able to make our cheats.
The main disadvantage of externals is the fact that we are not in sync with the game’s thread, which can lead to «unexpected» results (a prime example are external skinchangers, since they are not in sync with the game’s thread you won’t achieve consistency especially when trying to change the knife model).
We are also forced to read and write through specific functions (we’ll see later) that are heavy to call.

An INTERNAL cheat is a DLL which is injected directly into CS:GO and it is able to directly read and write CS:GO memory, through raw pointers. Internally, we can also get interfaces and call virtual functions, which makes our lives way easier. We can also hook some functions to kind of «redirect» them and make them doing what we want.

There is still an open discussion about what type of cheat is the most detectable.

There is another type of cheat, called «Internal/External», which is basically a DLL which is injected into any 32-bit process and from there it operates like a normal external. I think that we can consider this type of cheat external, because in the end all the operations we do are the same as external and we don’t do anything internal.

We’ll start with external, which are easier to learn but hard to master, while internal cheats are hard to learn. but easy to master!

Talking about VAC: Ring0 and Ring3 (OPTIONAL)

You can skip this chapter without any kind of problem.

(NOTE: I may say something wrong or bullshit in this specific section. VAC experts and kernel mode experts, help me! Chapter 2
External Cheats: The starting point

We’ll focus, for now, on external cheats, which you now know what they do (ref: 1.2 Different types of cheats)
Writing external cheats serves as a really good starting point in this sector because externals are way more documented than internals and they are way easier to code and understand.
However, once you get a really good grip on this type of cheat, you should consider switching internal which is (imho) fairly better. Still, you need the right knownledge.

As I already explained, the purpose of external cheats is reading and writing the CS:GO memory in order to edit it, gain info and get a huge advantage over our enemies in game.
An external cheat, however, isn’t forced to manage CS:GO memory. For example, you can write a really good recoil control system (aka RCS) without needing to read or write anything. Still, the most consistent results can be achieved only by reading/writing memory. For example, you can make a bhop script that spams the space key without reading or writing any sector of memory, still the hops won’t be consistent and the result can be shit. On the other side, by reading the memory to know exactly when to jump, you can achieve the consistency you want.
In the end, it’s all a matter of consistency.

Brief introduction to the WinAPI

I’ve stated multiple times that we need to manage CS:GO memory in order to achieve certain results with our external cheats. But how? The answer has got a name: The Windows Application Programming Interface! (aka WinAPI)

The Windows OS allows us to use the WinAPI, which (basically speaking) is a set of C functions and structs implemented in Dynamic Link Libraries (aka DLL). Don’t get me wrong, you can still mix your C++ code style with the usage of WinAPI.
There are, as you may know, three main groups of API: Kernel, Graphics Device Interface (aka GDI) and User. You can find more infos about those 3 types on the reference links I’m going to provide, if you want to get deeper.

Now that we know what we are going to mainly use in our externals, we can start talking about practically managing the CS:GO memory!

Managing CS:GO memory: RPM and WPM

We’re going to use a lot of stuff from the WinAPI to get the results we want, and for sure the functions that we are going to use the most are the actual functions to read and write process memory.
Those two functions are ReadProcessMemory and WriteProcessMemory (aka RPM and WPM).
Let’s see how we work with these two functions, I’ll start with ReadProcessMemory.
Based on the MSDN page of RPM, the function prototype is:

«_In_ HANDLE hProcess»

The first argument, the hProcess, is the actual HANDLE to the process we need to read memory from. Remember what I said in 1.2? In external cheats we use an HANDLE (like a bridge) to read and write memory.
In order to get this HANDLE you’ve got several ways.
The most used way is to loop through all the process through Process32Next (and Process32First), using the helper struct PROCESSENTRY32, then in the loop comparing the current process name with the process name we are searching for, if the names are the same then we use the WinAPI function OpenProcess to open an handle to this process. Notice that, in order to be able to read and write, we will put the flag PROCESS_ALL_ACCESS in order to gain full privileges.

REMEMBER! An HANDLE must always be closed through CloseHandle once it’s not used anymore!

This, however, is not the only way, of course. For example, if we are using managed languages like C# or VB.NET, there are way easier ways. However, I’ve explained the most common one.

The other arguments are already well explained on the MSDN page, and we’ll later see how we’ll use the second argument with module base addresses and offsets.

WPM has got the same arguments, the only difference is that the third argument is a pointer pointing to the value we want to write, while in RPM is a pointer pointing to the variable that is gonna receive the value read from memory.

RPM and WPM are not the only way to read and write process memory, it’s just the most common one, since it’s well documented and already implemented by the WinAPI itself. CS:GO doesn’t detect WPM and RPM since a lot of legit processes use them constantly, and the anticheat (as I already stated) wants to avoid false positives.

Getting CS:GO module infos

One of the most useful things we can do in CS:GO memory is grabbing infos about a specific module (a DLL, like client.dll or engine.dll, but also others). When we’ll get into offsets, you’ll see how important is to know some stuff about different CS:GO modules. But how can we grab this useful info?
As always, there are several methods, one is really similar to the method that I’ve explained previously about opening the process handle. The only difference is that instead of using PROCESSENTRY32 and related funcs like Process32First and Process32Next, you have to use MODULEENTRY32 to store info and Module32First/Next to loop through the module list.

Another way is to use the MODULEINFO structure and GetModuleInformation function, really handy when it comes to this kind of stuff.

Now that we got the info that we want, we can use the base address of the module to access specific things (using offsets) in that module (we’ll see, for example, grabbing the local player, or the local player health value).
Another useful thing to know is the module size, we’ll see his importance when we’ll talk about pattern scanning.

Building a memory management class

(NOTE: This section is going to get really practical, with a lot of commented pieces of C++ source code. But no problems, it’s optional! You can skip this if you really want it Chapter 3
Offsets

One of the most important topics to know while learning about memory hacking is the purpose of an offset. In these chapters, I’ll try to explain what an offset is and how to use them to access our values in memory. I’ll then move into explaining netvars and then I’ll talk about how to grab offsets and netvars dynamically.
But first, what is an offset?

An offset is a value that describes how many bytes we should move to reach a certain area of memory. Refer to this basic image to understand the concept:

As you can see, we’ve got a base address located at 0x0000, a local player’s pointer located at 0x004C and the local player’s health which is located at 0x007E. Our objective is to read out the health value of the local player.

So, for example, specifically for CS:GO, the current offset for the local player is 0xA323E4, while the module base of client.dll will be dynamic, so we can’t give a certain value for it (that’s why we use that algorithm showed on previous sections).
By doing RPM(base address + 0xA323E4) we get the local player. 0xA323E4 is an offset, it tells us how many bytes we must move if we want to reach something in memory. Other examples of offsets are entity list (0x4A4FCA4), force jump (0x4EE5114) and many others.

Be careful! The current offsets are static values which means that if there is a little change to the code the addresses set will modify, modifying the values of the offsets. On each update, the offsets will be most likely outdated. You have to re-grab them using an offset dumper, or just implement pattern scanning (we’ll cover that later on).

Is m_iHealth (0xFC) an offset? Kinda yes, because we use it like the normal offsets, but it’s more specifically a netvar. We’ll cover them, also.

Using our class and the offsets to make our first bhop

(NOTE: This section is going to get really practical, with a lot of commented pieces of C++ source code. But no problems, it’s optional! You can skip this if you really want it Netvars

Before jumping into pattern scanning, I’d like to talk about netvars. A Networked Variable (aka a netvar) is, as the name may suggest, a variable which is networked. A first example of a netvar would be m_iHealth (0xFC) or m_iTeamNum (0xF0) which are variables that ofc need to be networked in order to make the whole multiplayer thing to work you know.

These special variables are used exactly like any other offset: for example, m_iHealth is a member of DT_BasePlayer (DT stands for Data Table, notice the m_i hungarian notation prefix which Valve uses a lot). There are many data tables like DT_CSPlayer, DT_BaseViewModel, etc.

So, let’s say we want to grab the amount of matchmaking wins of a certain player on the server. The first thing that would come in our mind if we don’t know anything would be «There must be a netvar that holds this value!» and that’s true, it’s called m_iCompetitiveWins, it’s an integer value as the convention suggests and yes it’s exactly what we want. You try to do smth like RPM(entity base address + m_iCompetitiveWins offset) BUT the result is really fucked up and not exactly what we want. That’s because you didn’t notice that m_iCompetitiveWins isn’t a member of DT_CSPlayer or BasePlayer! Hence why we can’t read it as we do with other netvars which are members of that data table. Rewatch the netvar dump carefully and you’ll notice that m_iCompetitiveWins is a member of DT_CSPlayerResource! So we need to read it differently from what we usually do. So since it’s CSPlayerResource it will hold 64 values for each client connected to server, meaning that we need the entity index of the player we want to read the wins from. We’ll do smth like RPM(player resource base + m_iCompetitiveWins + i * sizeof(int)) where i is the index of our entity, and since each member of the array is an integer, we do i * sizeof(int) (we could just do i * 4 but ayyyy).

Basically, if we want to grab something from a certain player or the local player itself, remember that there will most likely always be a netvar that holds the value we are looking for. Really, there are a shitton of netvars so just take the right time to search through the dump and you’ll find what you want in most cases. See how a really basic netvar dump can be really really useful? In the next section we’ll cover pattern scanning, then we will cover how these dumps are made, involving recursion. will be really cool stuff indeed!

Getting offsets dynamically: Pattern Scanning

Started from the bottom now we are here: we are going to talk about pattern scanning. This is an important step to take if you want to take your externals to the next levels, simply because the only purpose of pattern scanning is to completely eliminate the hassle of updating offsets on each update on the game.
For example: the offsets I’ve used previously in the example codenz some weeks ago are already outdated now, because of CS:GO updates. In order to make your external more consistent and reduce the work you have to put on it to mantain it, you can implement the infamous pattern scanning.

Still this guide is aimed to completely noobish ppl I don’t really want to get any kind of deeper in pattern scanning (like WasserEsser did in his awesome guide, which I recommend reading after you grasp the concept). I just want you to understand how it works and how to implement it in your fantastic ez external cheaterino.

So, the concept behind pattern scanning (basically speaking) is to «build the offset» we are going to use later on in the cheat code. Each CS:GO module (like client.dll or engine.dll) is composed of bytes (raw bytes) which can be seen when reversing a module in OllyDbg or any other reversing tool. The offset we need is of course lying through these bytes, because the game itself uses offsets internally to access certain areas of memory (like we do with our externals!). We just have to grab it without forcing it, but how? The answer is quite simple: we use the sorrounding bytes of the offsets. See this image taken from WasserEsser guide:

FC 00 00 00 is m_iHealth (stored in little endian system), a common netvar we know to grab the health of an entity. In the image, the sorrounding bytes of the offset are highlighted in gray (so you can see them). These bytes are going to compose our pattern. Using OllyDbg specifically, we can simply use the SigMaker plugin, or if you are really brave you can make the sig on your own just by looking at the bytes (SigMaker just simplifies the process).

In this specific case, the signature is «\x75\x09\x83\xB9\xFC\x00\x00\x00\x00\x7F\x2D». We see that the current offset is lying in the pattern, and we don’t want it to be there so we nullify it (by just modifying the xFC to x00 in this specific case). Now, we have got the pattern we need. The mask is just derived from the pattern: it’s a string describing which byte is known and which byte isn’t known. In this case:

So the final mask is «xxxx. xx». Simple, huh? With the pattern and the mask in our hands, we can proceed to make our pattern scanning implementantion in C++ code.
To understand how the algorithm is going to work, just look at this picture:

This horrific thing made on paint in 2 mins represents how the pattern scanning is going to work with module bytes. Basically, in the image we have got 4 possible places to place our pattern. We loop through all of the possible places until we find the only one that fits our pattern (the third one obviously). Now, you may ask «What if I encounter a fitting place but it’s not where my offset is lying?». That can happen (but it’s really not that likely. ) and that’s what we want to make patterns as unique as possible. Also, we don’t want them to be too long or too short, because a too long pattern will get outdated in less time than a good sized pattern. In the end, it’s way better than hardcoding offsets.
That’s also how the offsets dumper we commonly use to grab offsets work, each one with a different kind of implementation. Just like with MMC (Memory Management Class, remember?), the code style possibilities are really wide, so my commented implementation will be just a small example to let you understand, nothing more.

In order to do pattern scanning, I commonly use a class.

The members of the class are quite obvious and that’s all we need. The first step is to dump the module bytes, which means storing the whole module into a byte array. Yeah, that sounds crazy. It is, actually, considering that a module is really really heavy (just log the module size of client.dll or engine.dll). This means that we need to take care of memory leaks because if we leak this huge amount of memory, that’s not a good thing. At all. That’s why I’m using the STL type std::unique_ptr. It’s a C++11 thing that allows me to make a smart pointer, which will delete itself when it gets out of scope (when we delete a class instance, in this case). Kinda handy, huh? It will take care of avoiding memory leaks, hopefully, but you can do whatever you want honestly.

So what public functions should I expose to the final user of the class a.k.a the cheat coder a.k.a most of the time myself?
Ofc, we must setup a constructor where we pass the handle, the module base address and the size of the module. The implementation should be really obvious.

Then, we need a function to dump our module bytes to the huge byte array.
The function will look like this:

The function is really simple: if m_pModuleBytes (the byte array containing every single byte in the module) is nullptr (points to nowhere, still not allocated), then we can allocate the memory we need, which is exactly the m_dwModuleSize. So we allocated m_dwModuleSize bytes in the heap, using the special C++14 function std::make_unique, to setup the unique_ptr. This memory is now «managed»: it will be cleaned up upon object destruction.
This is basically C++ attempt at garbage collecting.

The other function we need is, ofc, the function to scan memory for a pattern.
There are several algorithms out there in order to do this, and there is even a thread which contains the fastest methods, especially the one from learn_more that nearly everyone uses in their internals.
The thread can be found by clicking here: *CLICK*

If you are interested, you can glance around in the thread so you can get inspired and write your own or just copy or improve other’s methods.
The implementation I’m currently using in my externals is ofc not the best or fastest one, but it works kinda good.

Ok. This can be a really though one to understand. Look at it slowly and you will notice that it makes sense. Now we just need to use this function:

The Search function will just use mask_check while looping through the whole module bytes. When the index is the right one (mask_check returns true), we can just assume that this is the right offset and return module_base + this offset.

Thinking about it, you can make the exact same thing using a string to represent the pattern
So little homework: Modify the function so you can pass the most commonly used string patterns, avoiding the hassle of converting the string into a usable std::vector.

Remember that you will need to dereference the address found and add some «offset bytes» to it in order to land on the right offset.

Getting netvars dynamically: Netvar Managers and recursion

Some could argue that since every single offset can be sig-scanned, netvar offsets can be sig-scanned too, and that would be more than true, but there is a way better and cleaner way to grab netvar offsets specifically: setting up a netvar manager!

A netvar manager, as the name would suggest, is a manager designed for netvars. It is usually a class responsible for grabbing netvars dynamically, dump them, and stuff like that.
We already spoke about what netvars are and how the game uses them itself, remember? (If not, see Chapter 3.2 «Netvars»).

We already know what netvars are, but how do these work exactly inside the engine?
Let’s look at the structure of a ClientClass inside the Source Engine

m_pCreateFn is a pointer to the function that gets called whenever we create a new entity of a certain class.
For example, some code needs to be run whenever the creates a new instance of class «CC4», or «CAK47».
m_pNetworkName is ofc the name of the class, specifically. It can be «CCSPlayer», «CCSPlayerResource» or even «CChicken». Notice the prefix ‘C‘ that stands for class.
m_pRecvTable we will get to it in a moment, this is what we really need to accomplish our netvar manager.
m_pNext is a pointer to the next ClientClass in the list. We can now understand that there is in the game a linked list of clientclasses and we can access it both externally and internally.

Externally, this is done by sig-scanning the offset for ClientClassHead, which is the head of the list. Using the head of the list, we can walk the whole list until we reach nullptr.
HazeDumper already gives us all we need, basically:

Or we can use the static offset which is *atm* 0x4F89EBC but it’s due to changes in future patches.

Internally, it’s even easier. We can just grab the base client interface and call the function GetAllClasses() directly. GetAllClasses() returns a pointer to the head of the linked list of clientclasses, which comes really handy. Externally, we need to grab the pointer returned by this function.

m_ClassID should be obvious: it’s the numerical class id to identify the class.
Simply by walking through the linked list of classes, we can easily dump and format every single class id, which is exactly how those class id enum dumps are done.

Returning to m_pRecvTable:

From this struct, we are really interested in only a few of these elements.

m_pProps points to the beginning of an array of properties.
An example of property is m_iHealth or m_iTeamNum.

m_nProps contains the number of elements in the array of props. It is useful when we want to loop over all the props.

Now let’s take a look at the struct that describes a property «RecvProp»:

Damn, that’s a lot of elements! Let’s analyze them a bit.

m_pVarName is kinda obvious. It’s a C-style string containing the name of the property. For example «m_iHealth» or «m_iTeamNum».

m_RecvType is the type of the property. It can be:

m_StringBufferSize is the maximum size of the string buffer in case the property is a string. To give a clear example, think about the property «m_szLastPlaceName» from DT_BasePlayer. It is a string that contains the name of the last map place visited by a certain player, for example «Long», «Pit», «Tunnel», you know. It can be max 18 chars long, so m_StringBufferSize = 18.

I guess you are not really interested in the rest of the struct variables, but two of them may sound interesting to you: m_Offset and m_ProxyFn;

m_Offset, as the name suggests, is the actual offset leading to the value contained in the netvar.
You may be happy now: let’s just do base + offset and we get the value! Nope. This value is relative to the base table. That’s why recursion is used in most netvar grabbers (even though some of them adopt another technique to account for tables within tables)

This guide, as I already said, is not complete and needs a lot of work. I’ll update it with new sections and chapters throughout these days. You can help me updating/correcting/getting better this guide using his GitHub repo.

How to make cheats

A major step in the path of an apprentice hacker (game hacker or not) is to go from learning a programming language to getting started in practical hacking, using this new knowledge in practice.
There are lots of material available, tutorials and guides, but we are then facing an information overload, a lack of clear path which can be felt like an impassable gap.
This is in my opinion one of the reasons why we see people knowing how to code asking in hacking communities what to do then from where they are.
This article has for objective to fill this gap and provide a clear path for anyone having learned to code to get started in (external) game hacking.
This will be a first experience of practical hacking so the reader understands the crucial steps of game hacking with a practical example.

The first part is essentially an RPM/WPM tutorial, very verbose, very slow paced for an inexperienced audience (e.g. people still trying to wrap their head around pointers and such).
The second part is an applied example of cheat development, including the reversing part.
The last part is devoted to an introduction to anti-cheat bypass.

I am devoting a lot of my spare time to this project and therefore I will release all this exercise by exercise and not in one go.

You are free to use the programming language of your choice, however, I will provide solutions to the exercises in C/C++ only.

Requirements / Target audience

External Cheats: Principle & Notions

An external cheat generically reads the memory of the targeted game/process to extract valuable information to get an advantage.
For example, retrieving the 3D position of your character and the positions of other players to display it on a radar or directly on screen like in an ESP cheat (Extra Sensory Perception)
The following screenshot shows a cheat with both radar (top left corner) and on-screen ESP.

This type of cheat is doable by being able to read the game’s memory exactly as we will do in the second exercise, obviously combined with additional code to draw the shapes and text (that I will cover in a another guide).
We can also overwrite the target memory to change values, such as maintaining your player’s health points to the maximum, giving unlimited ammunition, etc.
As you understand getting access to the game’s memory is the gateway to any sort of hack we want to do then, this is why most anti-cheat bypass techniques aim at giving you this access, and why this guide focuses on this task.

We call «External Cheats» any cheat that runs in a separate process than the game/program it hacks.
Oppositely, «Internal Cheats» are executed from within the hacked game/program, therefore, the methods used to read and write data to the hacked target differ between these two paradigms, among many other differences.
Microsoft Windows operating system provides a set of functions that allow us to read and write another program’s memory self-explanatory named ReadProcessMemory and WriteProcessMemory (abbreviated to RPM and WPM).
Using the RPM function can be imagined as asking your Operating System (OS):
«I would like to read X bytes of data at the memory address 0x12345678 of this process and put the result at the address 0x87654321 in my process memory»
Same thing for WPM, but instead you ask to write what is at a specific address in your process at an address in the other process.
Here’s an extra diagram in case this is not clear:

Note that this is not the only way and external cheat can read another process memory.
It is possible to read and write another process memory without these functions, for example by using a driver (functioning in kernel mode, a higher privileged mode of your operating system. Read Wikipedia’s «Protection ring» article for more information)
However, since the hack program still runs as another process, it is still by definition an external cheat.

Exercise «Dummy program»: Coding our dummy target program

This exercise has 2 objectives:
First, to provide us with a dummy minimalist program that we will try to hack, it will simulate our target game/program.
Second, it is filter for the audience: If you struggle during this first exercise, you should consider that you do not have the level for this tutorial, instead you should read more lessons of your programming language or get more experience with it first.
If you persist and try to force your way despite a lack of experience, you will most likely get frustrated and abandon your hacking adventure prematurely.

Here is the expected output by the end of this exercise (after having pressed enter once):

You may have issues when printing to console the process ID or the memory addresses since the process ID should be printed in decimal and the memory addresses in hexadecimal.
In addition to that, since I’m a bit OCD, I like my memory addresses to be in uppercase.
In C++ you can do like this to output in decimal:

This will output «In hexadecimal: 0xFF»
. And don’t forget «using namespace std;» after your #includes and #declares otherwise you can add the prefix «std::» (e.g. «std::cout Solution (C++)

Do not directly read the solution, you should succeed to write such a simple program.
If you have difficulties, do not hesitate to start over.
Code something satisfactory or spend at least 45-60 minutes trying before you decide to reveal the solution.
If you failed and had to look at the solution, read it thoroughly and then recode it yourself, you need more experience.

Now that we have this dummy program we are ready to start hacking properly speaking.
We are now going to read the values in of these variables in the memory of this dummy program from another program and overwrite them, just like you’ll be going in your game hacks.

Exercise «Read»: Reading another process’ memory

In this second exercise, we are going to use the function ReadProcessMemory to read some variables from our dummy program’s memory.
First, I want you to read ReadProcessMemory’s documentation page on MSDN to understand how this function works and what should be we give it as parameters.
Read the entire page carefully, trying really imagine how it works before continuing reading the next paragraph.

Okay, so let’s go over the parameters one by one, here’s the prototype so you don’t have to switch back and forth on MSDN while reading.

The first parameter _In_ HANDLE hProcess will probably be tricky for anyone not familiar with Windows API.
One of the numerous roles of your operating system, Windows, is to manage various resources, access, and permissions.
In our case, we need to request an access to our target program, with enough permissions to read and write its memory.
This is what this first parameter of type «HANDLE» is, it’s essentially an authorisation given by the operating system.
In order to avoid being confused just consider a HANDLE as an authorisation number given by the operating system.
To get this required HANDLE, we are going to use the Windows API function OpenProcess.
Once again, click on the link and read thoroughly the function documentation and try to understand how it works.

Here’s its prototype:

If you don’t understand what is the first parameter, you certainly didn’t click on the link to the process access rights, always follow these links to understand what to feed the function.
You should now understand what this is: It is the permissions we request.
Many permissions are available as you can see in the documentation, ranging from PROCESS_ALL_ACCESS (All possible access rights for a process object) to PROCESS_QUERY_LIMITED_INFORMATION (Required to retrieve certain information about a process) with many others, I encourage you to have a quick go through all these permissions, if you do not understand what some of them allow you to do, it’s fine, you are not expected to fully understand that today.
For the sake of simplicity, we are going to request all possible permissions on the target process with PROCESS_ALL_ACCESS.
A good practice is to limit the permission requested to the minimum useful, but we’ll take care of that later.

Okay, second parameter, «_In_ BOOL bInheritHandle».
This define is the handle (the authorisation requested) will be inheritable for child processes.
We do not really care about that, in short our program will request a handle, and if we set that to TRUE, all child processes of our program will also have this authorisation.
Since we won’t need that, we’ll set it to FALSE

Final parameter, «_In_ DWORD dwProcessId».
This is the unique process identification number, commonly abbreviated to Process ID or even PID, of the process we want to get an access to.
We printed it to console with GetCurrentProcessId() in our dummy program.

Otherwise even without that we could find it with this good old Task Manager or any administration software such as Process Hacker or Process Explorer:

We’ll then give it the PID of our dummy program.

If you read thoroughly enough OpenProcess documentation, you read that:

This way if you have an error, you will also have the error code returned by GetLastError() that will help you solve the problem.
In that case, simply go on MSDN error codes pages and look for your error code.

A «buffer» simply means a place in memory.
As a first task in our exercise, we are going to read just the first variable of type integer, the number 123456.
Therefore, we are going to declare a variable also of type integer initialised to 0 named «intRead» ( int intRead = 0; ) in our hack program that will read the dummy program’s memory and we will give the address of that variable (&intRead) as a buffer.
As a result if ReadProcessMemory succeeds, our variable intRead will then be equal to whatever value is the variable that we are trying to read in our target process.

Second to last parameter, «_In_ SIZE_T nSize».
This is simply the size to read.
In our first exercise we are reading an integer.
If you remember your lessons, an integer is traditionally of size 4 bytes, so we could give the function «4» but instead we’ll prefer giving it sizeof(int) which will give it the size of an int automatically.
If we wanted to read some text, like an array of chars for example, we would give it the size of the array, or the size of text we want to read.

The last parameter, «_Out_ SIZE_T *lpNumberOfBytesRead» allow us to retrieve in a variable of type SIZE_T the number of bytes read, as the function parameter indicates quite clearly.
We could therefore declare a variable SIZE_T named bytesRead initialised to 0 ( SIZE_T bytesRead = 0; ) and give ReadProcessMemory its address (&bytesRead).
This can be useful for error checking for example, however, to keep things simple, since this parameter is optional (as indicated in the documentation), we’ll just set it to NULL.
Anyway ReadProcessMemory returns a BOOL (TRUE/FALSE) that let us know if everything went well or not that we can use to check if the operation succeeded or not.

Okay we now have everything required to read our dummy program’s memory.
That perhaps seems a lot to learn if you are beginner, but trust me after this exercise, things should be much clearer.

Before starting this exercise, start our dummy program and let it run.

You are going to code a console program that will:
— Declare a variable of type integer named «intRead» initialised to 0
— Get a handle to our running dummy program (use OpenProcess and check that it succeeded with the checking code that I provided in the lesson, in case of error use the error codes to investigate the reason)
— Read the value of the variable «varInt» in our dummy program and store the result in our variable «intRead» (Use ReadProcessMemory with the handle you got, the memory address shown in the console of our dummy program and don’t forget to add the prefix (LPCVOID) to type-cast it so the function doesn’t bother you, store the result in our variable «intRead» by using it as a buffer simply by giving its memory address with &intRead, use sizeof(int) for the size, and let the last optional parameter as NULL)
— Print to the console the new value of our variable «intRead» ( cout nul»);

The expected output should simply be:

Your turn to play! Go ahead and code that!

It is important that you try really hard this exercise.
Please try really hard before reading the next supporting section «Troubleshooting» or the solution, instead prefer reading the lesson again.
You should try at least 1-2 hours before resigning to use the extra supporting materials that follow.
Even if you succeeded, I recommend reading the troubleshooting section, for your knowledge.

If OpenProcess fails:
Make sure your 2 processes run with the same privileges, if the dummy program is ran as administrator and not the other it might fail.
If you run the dummy program from directly from Visual Studio (or your IDE), try running it normally by double clicking the binary on disk instead.

If intRead is still equal to 0:
First make sure that OpenProcess succeeded.
Second, test the return of ReadProcessMemory, it should return TRUE, otherwise, if it returns FALSE, you can use GetLastError() to get the error code to get more information on the error.
Here is the some checking code you can use:

If intRead is not equal to 0 but is not equal to the expected value either:
You most likely read the wrong memory address or have requested permission to the wrong process ID.
Check the PID and memory address.
Make also sure that in both programs you declared an int.
Try to compile and run them for the same architecture (either both x86 or x64, even if it should work cross-architecture).

If it still doesn’t work, everything else has failed, and you really spent time trying yourself to solve your issue post your problem as reply of this tutorial with your complete code and the output you have.

One last time: Do not reveal the solution unless you have successfully written the program or have spent a substantial amount of time trying (1-2 hours minimum)
Using the solution without having succeeded is essentially a fail.

In this solution I prompt the user for the PID and memory address to read instead of hardcoding the values, here’s an idea to improve your program

Going further: Reading pointers, following pointer chains, reading text, and more

Reading a pointer
That’s something you will definitely need in your cheats, so I strongly advise you to do this one.
You are going to read the value of the pointer «ptr2int» in our dummy program, then you will read the int at the address pointed by this pointer, which will be our integer equal to 123456
Important thing to remember when dealing with pointers: x86 pointers are 4 bytes long (32 bits) and x64 pointers are 8 bytes long (64 bits) so adapt the parameter «nSize» or ReadProcessMemory depending on the architecture of your target program.

Following a pointer chain
You should have done the previous exercise first, now you can follow a pointer chain.
In most reversing topics in hacking communities, you will find offsets to valuable information in your games, such as the pointer chain to your health.
This will be written in the following format: BASE_ADDRESS ] + OFFSET1 ] + OFFSET2
In that syntax, «]» means dereference (read the value of).
This means that you should dereference (read the value of) the pointer located at BASE_ADDRESS, then add to this address the value of OFFSET1, dereference (read the value of) whatever is there, then add to this address OFFSET2 and read that address to get the value of health.
In our dummy program, there is no offset, the pointer ptr2ptr2 points directly where ptr2ptr is, ptr2ptr points directly to ptr2int, and ptr2int points to varInt
Our chain is therefore:
[ADDRESS OF ptr2ptr2] ] + 0 ] + 0 ] + 0
You can make a function that takes in input a chained list (a vector) containing the base address and offsets to follow (use a vector )
That will follow this pointer chain.
I am not satisfied with this exercise I will improve it later, if this confuses you, just skip it for now.

An OpenProcess malpractice
We requested all permissions for our handle with PROCESS_ALL_ACCESS as first parameter, but we don’t need that much.
Since we only use ReadProcessMemory, read the documentation of that function and request the minimum required permission in our OpenProcess call.

Another OpenProcess malpractice
With OpenProcess we request a HANDLE that the system give us, however if you read the documentation you’ll see that we should destroy it properly when we don’t need it anymore to avoid what we call «Resource leak».
Read the documentation again, find how this is done and include it in your code.

Read text from varString and arrChar
You should be able to read text from varString and arrChar.
To do so, you should adapt the size given as parameter of ReadProcessMemory and also have a buffer big enough to contain the read text.
The straightforward solution is to use an array of sufficient size, otherwise the C++ object string allow you to reserve memory with a method, you can try to implement that.

Make some errors!
Try to read a random address or address 0 in the target and see what ReadProcessMemory returns and the error code, go look it up on MSDN error code list and see if you would have been able to understand why that wouldn’t have worked.
Same thing with OpenProcess, what happens if you try to open an non-existing process ID? What error code do you get from GetLastError()? Can you make sense of it?
What happens if you get a handle with insufficient permissions? Let’s say you call OpenProcess with only PROCESS_QUERY_LIMITED_INFORMATION and then you try to use this handle with ReadProcessMemory, what happens? What does the error code say?

Pimp it up!
You can also modify your program output as you wish, prompt the user for the PID and memory address.
You could also ask the user what are we going to read: numbers or text and also ask for the lengh of text to read if the user wants to read text.

Exercise «Write»: Writing another process’ memory

We’re now going to write into our target process memory with WriteProcessMemory.
Good news: WriteProcessMemory is extermely similar to ReadProcessMemory.
Basically the only main difference is that it writes what is in the buffer to the address in the other process.

Obviously, you should have our dummy program running so we can write to it (duh!)
If you closed it after the previous exercise and have the PID and/or memory addresses hardcoded, don’t forget to update them.

Once this is done simply run the program, if you have no errors and see «Overwritten successfully» in the console as expected, switch back to your running dummy program and press enter to print the variables addresses and values again and you should see your varInt overwritten to the new value as shown on the following screen capture:

If you encounter problems, refer to the «Troubleshooting» section of Exercise 1, the same suggestions apply to the current exercise.

Again: Try genuinely and only look at the solution if you have succeeded or have spend a substantial amount of time trying.

Once again, in this code, I prompt the user for the PID, the memory address and the value to overwrite. You can implement it yourself before looking at the solution as a little extra task to get a little bit more experience, it never harms.

Overwrite text
You can overwrite the text in arrChar and in varString.
Since arrChar is of fixed size, you can overwrite a longer text, however, the object string of varString keeps the memory used as small as required, you might have a problem if overwriting it to a longer string of text (but you can try to see what happens, just for the lolz and the experience!)

Again:
You can apply the following subtasks from exercise 2 to this exercise: «An OpenProcess malpractice», «Another OpenProcess malpractice», «Make some errors!» ( do other errors, play with your code, you won’t break your computer don’t worry ) and «Pump it up!»

If you’ve made it that far, a big CONGRATULATIONS to you.
I encourage you to once again show off and show us your code here!

Exercise «Basic reversing»: Using Cheat Engine & ReClass on Assault Cube

If you are having a mouse problem (the camera going crazy):
You probably had the game already installed and this bug appeared with the Falls Creator Update of Windows 10, uninstall it and reinstall it from the installer of the official website, they replaced the SDL.dll file that was responsible for that in the new installer (they discuss that on the official forum).

So, did you like it?
It’s quite basic, but it can be fun to play with some friends, I’ll admit that it gets quickly boring against the AI.
There are still some people playing online, however I’ll ask you to please not ruin the experience for other players.
Okay, let’s continue.

First let’s define what is reverse engineering.
We call «Reverse engineering» the task in which we analyse a program (for which we generally do not have the source code) with various tools such as a disassembler, a debugger, a memory scanner, and many others to understand how the game operate internally.
In our case, we are specifically interested in the memory locations of valuable information such as our health, ammos, 3D position and other variables, the number of enemies on the map with their information, etc.

Well, let’s start by starting the game.
We are first going to locate where are stored our player’s information in memory using a memory scanner, in this tutorial I will be using Cheat Engine, but other memory scanners are available such as Cry Search coded by one of our talented members.
I intent to write this same exercise again with Cry Search to initiate people to it in the future.
If you have no experience in reverse engineering, the task can seem daunting:
«How the hell are we going to find in the whole memory where is the info of our player?»
Well, the memory scanning function of Cheat Engine will help us quite a lot.
A memory scanner basically allow you to look for specific values in memory and store them in a list, one it has scanned all the memory you can search for another value among the results that you found the first time.
This can be used to locate the number of bullets that you have in your magazine for example:
Let’s say that you have 20 bullets in your magazine, you scan the game’s memory for memory addresses equal to 20, it finds a whole load of addresses equal to 20, then you shoot a bullet, you now have 19 bullets in magazine so you scan among the addresses you located which one(s) are now equal to 20.
If you still have too many results, just shoot another bullet or reload to change the value and scan for the new value until you have isolated where the value is.
Sometimes you will be left with a few memory addresses and not just one, because sometimes the value is stored at several places, for example one is the «real» value and the other is just used for display, you can then experiment and test which one actually change your bullets in magazine.

Let’s do just that right now!
Start the game, or if you have it already started create a match without other players (press Escape then go to Single player > Empty map and select a map of your choice).
Take a second to give yourself a nickname in the game, if possible more than 6 characters long, you can do that by going in the menu (Escape) then Settings > Gameplay settings.
Now start Cheat Engine and attach it to the game by clicking on the color-changing button on the top left corner right below «File» then select the process of the game («ac_client.exe»).

Hey, little question for you: What do you think happens when you do that?
Which Windows API function do you think is called when we «Attach» to the game in Cheat Engine?
We used it ourselves!
. If you guessed OpenProcess congratulations, you’re right and you now understand more and more how Windows programs are made:
There is no black magic and even programs impressive by their complexity like Cheat Engine are coded with the functions that you are now learning to use!
And if you don’t believe me you can verify that in Cheat Engine source, but let’s keep that for later, when we will add a bypass to Cheat Engine

Okay now we are going to repeat the procedure that I described previously, we are going to look for the value of our ammos in the magazine of our assault rifle which should be 20 if you haven’t shot yet.
In Cheat Engine, we are going to search for the value 20, exact value and of type 4 bytes (integers are traditionally 4 bytes longs, not that some values could be stored in 2 bytes shorts, or 8 bytes uint64_t, etc. we sort of have to guess, but since 4 bytes is dominant, we start by that).
Leave the rest of the options by default, Cheat Engine has intelligent default values that work in most cases.
The scan will find you a few thousands results as shown in this picture:

Now go in the game, shoot a bullet (or 2 it doesn’t matter, just make the value of the currently loaded ammos vary).
Scan for the new value (press Enter or click on «Next scan», «New scan» actually delete the current results)
You should now have fewer results, in my case, I have only 3 results in the left pane.
Let’s repeat the operation, shoot or reload and scan for the new value.
You should be left with only 2 values, if that’s not the case, repeat the operation until you only have 2 values.
You will notice that the 2 values change every time you shoot a bullet, that means we have most likely found what we are looking for!
Double click on the 2 addresses on the left pane to add them to the list of saved addresses (shown in the bottom pane):

You can double click on «No description» and enter a more eloquent name, such as «Assault Rifle Loaded Ammos 1» & «Assault Rifle Loaded Ammos 2», take this habit so you know what you’ve found later.
Now how to know which one is the right one?
We can experiment and play with the values, for example, check what happens when you change one value but not the other (just double click on the value in the bottom pane and enter the new value) and shoot a bullet: the 2 values are decremented, that’s not really helpful.
You will also notice that one of the values doesn’t change the number of bullets on screen.
Okay let’s try to set the value stored at this memory address to 1 and shoot a bullet, which will set it to 0 and normally should make us reload automatically.
Go ahead and try: The weapon doesn’t reload and the value on screen shows the other value.

Okay now let’s have a look at what’s in memory around that value.
Right click on the address in the bottom pane and click on «Browse this memory region».
This will open the memory explorer window with as first byte the value at the address you right clicked on.
Can you see something interesting in the memory view, especially on the right side ASCII view?
Normally you should see not so far away your nickname:

That’s very interesting, the fact that these 2 pieces of information are so close certainly means that there is some sort of memory structure holding all our info.
Okay let’s save the address where our nickname is stored in the list of saved addresses, to do so, simply right click the first character of your nickname and select «Add this address to the list».

Pointer scanning: The theory
TODO

Okay now what are the 2 first Vector3?
If you want you can try to figure it out by yourself now it’s not hard, move around, see how they change, jump, crouch, do thing and see.

If you found what they both are congratulations.
Here is how I figured it out:
Both positions are the same with the exception of the Z, the first Z is always higher than the second one, but if you crouch then the difference decreases, and if you stand again, the distance increases.
This means the first one is the position of the head and the first one is the position on the ground! (Let’s say it’s the feet)
That is going to be useful for us to make an aimbot that always headshots or to draw rectangles around players (we can do that with only the position of the feet and head).

Another awesomely useful tool: ReClass
TODO

Okay once we have found everything we could and everything we want to code our cheat functions, we can transform all this into a struct that we will use in our cheat.
If you have reversed the game with ReClass this software allow you to directly export your structure to C/C++ code, however, I have made it by hand to make it very clear using the self-explanatory Windows types.
Here is what I have found put in a nice struct for you:

How to make cheats

Hellolo!
As there is loads and loads of people asking how to make hacks or how to learn C++, I decided to make a tutorial on how to start making hacks.
Also, English is not my main language, so sorry if something is misspelled.
What you will need:
A brain
Visual Studio or some other IDE.
Will to learn.

Bigger programs:
Challenge 1:1
Make a ‘bot’ that answers the users questions and asks them.
Hint(s): If/else, switch
Challenge 1:2
Make it store info if the user says wrong answer or something similar.
Challenge 1:3 (This one is very hard)
Make it remember stuff, learn, like a human.

NOTE: The best way of learning is through trial and error, so be sure to experiment.

Then we need to initialize ProcMem in our main.cpp file so we can use the functions from it:

Now you have a working triggerbot!
It is probably detected, but anyways.
Have fun with it!

The first function takes XYZ coordinates and translates it to XY coordinates. Basically, game coordinates to screen coordinates.
You will use this in both aimbot and esp, because we need to know where to set the mouse cursor, and where to draw the esp boxes.
The second function calculates the distance between your player and the enemy player(s).
Sooooooooo, let’s start with the actual coding!
First, we will need to read

Chapter 4: Making a menu, toggable hacks, DirectX.
Comming soon.

Chapter 5: Making an ESP
Comming soon.

How to make cheats

So, I’ve been searching a bit around and I don’t see out there really «for dummies» tutorials. With «for dummies» I mean really for dummies.
Then I’ve decided to make this tutorial, to get rookies (like me) a good point to start making cheats. A solid point is just what I needed when I started programming CS:GO cheats a month or so ago, and now I’m here with a lot more knownledge to share with rookies like me. Enough said, let’s start.

Why should I learn how to code CS:GO cheats?

If you are a programmer, the first thing that comes into your mind is «Why would I need to learn how to code CS:GO cheats? I’m a legit player!». I am a legit player too, so I can completely understand you. I really don’t like cheating, so why did I start?
I can’t tell you exactly, really. I just wanted to learn more and more about this, seeing a really high amount of cheaters in CS:GO servers.

If you are here, this means that you really want to code cheats. If not, go away.
Still here? Then I can tell you the requirements: if you want to code cheats you need a really good understanding of the C++ syntax. Why C++? Because it’s a really «flexible» language. I’m not saying that it is easy, I’m saying that it can communicate greatly with low-level stuff, it’s really our language of choice.
If you don’t know C++, my advice is to buy a book on that, to read a lot of tutorials and also to code a lot. When you’ll feel comfortable with C++, then you can start doing more complicated stuff.
Another really important requirement is a good knownledge of reverse engineering. You’ll need that a lot if you want to make even more complex cheats, you need an understanding of what is really happening in the game, so you should learn the basics of ASM and how to use Cheat Engine properly. In this tutorials I won’t talk a lot about it, because imho it’s really complicated stuff and can hurt your mind a lot if you are a really rookie (like me). But a basic understanding is highly suggested.

Different types of cheats

External cheats: how do they work

An external cheat, as said earlier, is an EXE which can read and write into the CS:GO process. How can the EXE do that? Because it creates and handle to the CS:GO process, from this handle we can call some helpful functions from the WinAPI that allow us to read/write and to have some fun withing the CS:GO memory.

How to start coding an external cheat

In order to read/write into the process memory, we need to create a class that handles all of that stuff. That’s the first step basically. I don’t recommend you copy-pasting a memory class (*cough* ProcMem *cough*), but I recommend writing your own memory class. In this tutorial, we will create a basic memory class, then we’ll move on and use that class to make our first cheat.

Got your keyboard ready? Create a new header into your VS project, call it «Memory.h», «MemoryManager.h», «ProcessMemory.h», «PleaseDontBan.h», whatever you want.
This will be the skeleton of the class:

Now that we’ve got the skeleton ready, we can proceed on some actual code inside the MemoryManager class.

These members are private because it’s really better to setup a getter to both of them.

These members are public because we want to quickly access the elements of MODULEENTRY32 struct, or quickly access the ClientDLL/EngineDLL base address of CS:GO. client.dll and engine.dll are 2 really important DLLs that are lying into the CS:GO process while it’s running, we need to get them in order to operate externally.
We now need to create 2 «must-have» functions: The function to get the process handle of CS:GO, and the function to retrieve the moduleentry32 struct for a CS:GO dll.
These 2 functions are really common here.

These 2 functions can seem a real monster to understand, but it’s actually easy.
The AttachProcess function converts the char array containing the process name (in our case «csgo.exe») into a wchar_t and then loop using do while until it finds a corresponding process to the process name. When it finds it, assign the process id and the handle to our private members, then returns true, meaning success.
The literally same concept is applied in the GetModule function. In this case, if no module is found, it returns a module entry with the module base 0x0.

After writing these 2 important functions, we need to write another 2 important functions: the read and write functions. These functions are gonna be templated so we can write whatever type we want (int, float, double, Vector3, DWORD, etc. )

As you can see this one is really easy: we use ReadProcessMemory to read and WriteProcessMemory to write (aka RPM & WPM). If you aren’t really sure about what the WPM/RPM functions do, you can check them out on the MSDN (Microsoft Documentation), so you also get used on checking a lot the documentation, when you aren’t sure.

I said earlier that we’re gonna make getters from both dwPID and hProcess, so here we go, pretty straight forward.

Before we finish, we also need to setup a constructor and a destructor for this class. In the constructor, we’re gonna use both AttachProcess and GetModule functions to assign values to ClientDLL and EngineDLL moduleentry structs.

As you can see I use the try/catch syntax to handle the different errors that we can get. In the destructor, we simply close the handle of hProcess. We don’t want it to lie in memory anymore.

Really simple, huh? We’ve now got our first, fresh memory class, written «from scratch». We can now use this class to have some actual fun withing the CS:GO memory, so create a main.cpp file, that will contain the cheat code and the main entry point for the exe.

Offsets!? What they are? What I’m doing with my life? Why am I writing an useless cheat? These questions can come into your mind probably, but I can answer only to the first one.
An offset is an hex value representing an area of memory, I know that I’m not explaining it properly, because you need a really good understanding of reversing/using CE, but that’s my «for dummies» explanation.
For example, our player is stored in client.dll + local player offset, because the local player memory storage is x bytes far away from the client.dll base address.
Then, once we’ve got the local player position in memory, we can use localplayer + team number offset to retrieve, for example ofc, the team number of the local player. But where can we find these offsets? I already told you where to find them earlier.

Now, we want to, for example, make a triggerbot using the MemoryClass previously created. So, what are we gonna use?
We need, of course, the local player base, to retrieve all the useful values, like the crosshair id or the team number.
So we update the offsets list:

We don’t need only these offsets, of course. We also need to retrieve which entity is currently in the crosshair, to do so we need the Entity List, which offset is 0x4A5C9C4

If we’ll need more offsets later on, we’ll update this list. However, if CS:GO gets updated the offsets like m_dwLocalPlayer or m_dwEntityList will change (iTeamNum is static), so you’ll need to retrieve them again and update the list. However, if you are lazy you can do pattern scanning method to find your offsets dinamically, but I won’t make this «tutorial» even more heavy, you can find a really good tutorial made by Zat about this here on UC.
From now, let’s start coding the triggerbot function

As you can see, we retrieve, using the LocalPlayer_Base, all the infos that we need for the player. We now need to get the entity and all the infos about it.

We now need to check if the entity found in the crosshair is valid, in order to do so, we also need to check for dormant status of the entity. An entity is dormant when it’s «inactive». With inactive I mean also dead, so we can skip dead enemies, otherwise we would shoot at enemy dead bodies, that wouldn’t be useful.

Then we can check:

As you can see I’m using WinAPI function mouse_event to emulate shooting. The other way is more «internal-like»:

This is the end of this tutorial, but is this really an end? Imho it’s more like a start for you, from here go check out many other tutorials, learn more and more, try to figure out problems on your own, and if you’ve got doubts we are here to exactly help you!
I hope you found this really noobish tutorial helpful, and I hope to find you helping other people on this forum!