DEV Community: Igor Segalla

Avoiding the use of “Auto Clicker/Keyboard” tools

Igor Segalla — Tue, 23 Feb 2021 15:42:30 +0000

Still on the topic of cheating and as a follow up on my last post in this community, I will try to explain one of the alternatives I used, and that you can also try, to avoid using tools that simulate mouse clicks or keyboard keystrokes.

What is it?

These tools that simulate Input events are usually used to create Bots, where the tool will repeat a user-defined input pattern (mouse or keyboard) without having a "real" interaction with the application, e.g., the tool will simulate behavior as if a person is in charge.

Alright, but where does the user use this type of tool? It is very common to use it in games such as RPG, where the player needs to use a skill every time, a potion to recover its life or even click on a certain position on the screen to attack a monster. All of this can be done by simulating clicks or keystrokes.

Auto clickers can be as simple as a program that simulates mouse clicking. This type of auto-clicker is fairly generic and will often work alongside any other computer program running at the time and acting as though a physical mouse button is pressed. (Source: Wikipedia)

This kind of “cheating” can be very harmful to your application, since the user is having an advantage over other players and he can set the “Bot” playing for him 24 hours non-stop (which would be very difficult for us humans).

How does it work?

Usually, the operation of these tools is quite simple. The most common method is to send an Input message to the HANDLE of the window that we want to simulate the click or keystroke. This can be done using the Win32 API's SendMessage function:

LRESULT SendMessage(
  HWND   hWnd,
  UINT   Msg,
  WPARAM wParam,
  LPARAM lParam
);

In the first parameter we specify the HANDLE of the target window. In uMsg we specify the identifier of the message we are sending (Eg WM_KEYDOWN), and the other parameters are additional information related to that type of message. For example:

SendMessage(hTargetWindow, WM_KEYDOWN, VK_RETURN, 0);

In the case above, we are sending a WM_KEYDOWN message, e.g., a key is being pressed and with the WPARAM being VK_RETURN, means that we are simulating the pressing of the Enter key.

As explained, you can replicate this operation for other types of events and build your own logic, like building a Bot to automatically use skills in a game.

Problem

The problem we have when trying to avoid this type of cheating in a "native" way, is that we were unable to identify the source of a message using the Win32 API. That is, all messages are valid regardless of where they are coming from for our application.

With that in mind, what we should do is filter out these Input messages received in our application, limiting them to only reliable devices and that they originate from hardware, and not virtual messages (which are sent by software).

Implementation

The implementation of the proposed solution is quite simple. We will change the way we handle the Input messages received in our application, starting to use the concept of Raw Input (Win32 API).

The raw input API provides a stable and robust way for applications to accept raw input from any HID, including the keyboard and mouse.

To use Raw Input, first of all we need to register the devices that we want to receive the inputs. Thus, we can choose whether to receive data from a Joystick, a Mouse, keyboard, gamepad etc. No input will be detected if we don't have a registered device.

In the code above, we are registering only two devices: mouse and keyboard. You can check the RAWINPUTDEVICE documentation for more information.

With the devices already registered, our application will start receiving Input events through the WM_INPUT message. What we need to do now is to simply handle these messages, and identify whether we are dealing with a keyboard, mouse event, etc. I am showing the way I used it in my Gist application below, where I am handling messages from keystrokes and mouse clicks.

The operation of the code above is quite simple. We are retrieving the input data with the function GetRawInput, and with the output of this function we can handle the events according to our application. In my specific example, I check if the input message is of the keyboard or mouse type, and if it is valid, the application processes normally. Otherwise, the message will be discarded.

Although the solution is quite simple, this type of content (about cheating) is a quite difficult to find on the Internet, so the programmer's creativity is of great importance. It should also be borne in mind that for any solution, there will always be a possible gap (it is up to you to make it difficult to access the gap).

With the proposed solution, we will avoid the vast majority of Auto Click tools, as they all follow the same operation. The only case that our solution cannot avoid is when the Input is simulated by some type of hardware, because if the event is emitted by a hardware, we consider the event to be reliable and process the Input normally.

Just a reminder, architect your server properly!🤗

Tips for writing an Anti-Cheat

Igor Segalla — Fri, 09 Oct 2020 02:25:23 +0000

If you have ever been curious about how an anti-cheat works or if you plan to write your own, then in this post I'm going to give you a few tips on how to detect and protect your application from these well-known cheaters.

It is worth noting that in this post I'm going to emphasize the client-side part, and not the server. To avoid future problems and have a totally secure application, the best you can do is to have a well written program that doesn't allow the exploitation of faults by third parties in any way.

Anti-Debugging

One of the best known and most used methods to protect a program from an intruder is to prevent users from debugging it and thus reverse engineer it.

Reverse engineering is the process of discovering the technological principles and functioning of a device, object or system, through the analysis of its structure, function and operation.

I made a collection of 12 different anti-debugging methods while working on my anti-cheat. All the ones I found are efficient and fully functional. Below you can check out these methods and use them as you like. Just keep in mind that the code with all the methods is in a separate Gist so as not to pollute this post.

Find Window

It is a very common method among the existing anti-cheats, which consists of searching for a process that is running by the name of the window. As an example, it is to make that whenever there is a window with the word hacker, the anti-cheat detects this process as malicious software (is quite common for this method to detect false positive).

I use two possible ways of Find Window: one of them is to check if there is a window with the keyword chosen by me; and the other one is to analyze all HANDLES made so far and check if it could be a malicious software.

Find by Window name

As previously said, this method is nothing more than using the FindWindow function of the Windows API and check if it has any window with the chosen words. If it returns a valid HANDLE, it means that the window has been found.

if( FindWindow( "hacker", NULL ) != NULL )
     HackerDetected();

Deep search for a Window

This method does a deeper search for each opened process, trying to search for some pattern that identifies that program as malicious software.

We used the EnumWindows and EnumChildWindows function to iterate through the existing HANDLEs recursively.

EnumWindows( (WNDENUMPROC)EnumWindowsProc, ( LPARAM )nullptr );
void EnumWindowsProc( HWND hWnd, LPARAM lParam ) {
    EnumChildWindows(...);
}

If we have the HANDLE of each window, and of each element within the window (every UI object in Win32 is a HANDLE), we can make some observations and an analysis together to check whether that is or isn't a malicious program. Observations such as:

Having a specfic text anywhere inside the window
Having an UI element with a specific Window Style (size, color)
Keyword is found in any Win32 UI element

You can take a cheat tool and identify the pattern of its UI, such as the size of the buttons, the style, the text etc, and so have our anti-cheat whenever it encounters these patterns, already identify it as a malicious program, for example.

Avoiding injected modules

Obviously, we don't want any DLL to be injected into our process and so it has access to our code while executing, memory etc.

To avoid this kind of problem, the solution is quite simple: we check all the modules present within our application, and if there is any unknown module in the middle, we detect it as an intruder and we expel it from our execution.

Duplicated process instance

A very common method that people use for handling a process's memory is using ReadProcessMemory and WriteProcessMemory. You must first perform an OpenProcess, to assure all the necessary privileges for improper memory manipulation in oder to use these two functions.

The OpenProcess function works by creating a new instance of our process, making it as if two distinct HANDLEs point to the same running process.

We check all instances related to the running process in order to avoid this, and if that instance is from an unknown process, we close the HANDLE of it, not allowing any more memory manipulation (either writing or reading).

Hooking Function

This protection is quite simple, but it can be pretty effective against cheaters who do not have as much knowledge in reverse engineering. This protection can also be added to the others mentioned in this post, therefore, getting even better.

The protection consists of simply checking if a function has been hooked, checking if the memory of the function we want to protect is using Assembly statements of type JMP.

bool __forceinline IsHookAPI( BYTE* pbFunction )
{
  //JMP
  if( pbFunction[0] == 0xE9 )
     return true;
  //JMP DWORD PTR DS:[...]
  if( pbFunction[0] == 0xFF && pbFunction[1] == 0x25 )
     return true;
   return false;
}

To use the IsHookAPI function, we just call it by giving the memory address of the function we want to check. Example:

if( IsHookAPI( (BYTE*)&GetTickCount ) )
  //Do something...

In the example above we are checking if the GetTickCount function was hooked to another place, and if it was, the check will return positive and so we can detect a cheater.

Checksum

This is one of the most used methods when it comes to protection, and it can be used in several places. What we do with this method, is basically to check the integrity of our file or memory, hoping that it matches the original. If this integrity check doesn't match the expected, we can conclude that there has been a change in the file/memory and identify the user as a cheater.

A checksum is a small-sized datum derived from a block of digital data for the purpose of detecting errors that may have been introduced during its transmission or storage. By themselves, checksums are often used to verify data integrity but are not relied upon to verify data authenticity. Source: Wikipedia

You can use this method in important files of your program, the executable file itself or even the section .text from your executable.

The .text section of the executable is where the program code is located. In it we have the permission to read and execute. Therefore, if any user makes any changes in this section, we know that the code has been tampered with.

Calculating the Checksum

The one I choose to use was CRC32, although, there are several ways to calculate the checksum of something. This kind of verification is widely used for error detection in network protocols and storage devices.

This kind of algorithm may not be the best choice for our case, but I chose it because it is relatively simple and very easy to implement.

int VerifyChecksum::GetChecksum( void* pBuffer, DWORD dwSize )
{
   //Calculate the checksum of .text section
   boost::crc_32_type result;
   result.process_bytes( pBuffer, dwSize );
   return result.checksum();
}

If you do not want to implement it on your own, you can use the boost library, where we already have a function made for this.

Protecting function calls

As I mentioned at the beginning of this post, the best way not to need to protect the client side of your program, is to do as much as you can on the server side. However, there are still those things that we have to leave on the client side and we would not like in any way that the user could use.

What we do in this function is to check if the return address of the function we are protecting is within the scope of the program, and also, if it is being executed by a known thread. If any of these checks return negative, we know that the function may be being called by some external program, such as one .dll injected, and thus detect as an improper call.

You can avoid future headaches and be able to protect your project from cheaters with those simple tips. Although some of these methods are quite simple, the cheater must have a considerable level of reverse engineering, and be able to get through all the existing protections (which will be scattered throughout your program).

I emphasize once again, that the best way to protect your program, is to leave delicate workings to the server side, preventing your users from having access to resources that they should not have.

So, architect your server properly!🤗

Rewriting a 2000s graphics engine

Igor Segalla — Wed, 07 Oct 2020 02:34:18 +0000

I have always been interested and curious about the computer graphics area, trying to understand the whole process involved in rendering a simple 3D object. How could millions of meaningless numbers be drawn on the screen, with animations, lighting, textures and everything?

To start getting a little more aware of the subject, I started reading the book Introduction To 3D Game Programming With Directx 9.0C: A Shader Approach. This book covers from basic concepts (example of what a 3D object is) to even more advanced concepts, such as the use of Shaders (reason for my choice).

Oh, and yes, I know that the concept of fixed-function rendering pipeline is already obsolete, but I chose Directx 9 because the implementation is simpler.

Introduction To 3D Game Programming With Directx 9.0C: A Shader Approach (Wordware Game and Graphics Library) (Frank Luna)

Today, I'm going to tell you a little bit about my experience to rewrite a very old graphics engine and optimize it using more modern concepts.

The work involved in this whole project was very complex and quite extensive. As I don't want to go into too much technical detail in this publication and end up making it very tedious, I'll focus on the main parties involved and summarize what my solution was.

Application

This project was carried out in a game (nothing better to have feasible results) from the 2000s.

My target in this project was to optimize this game as much as I could in comparison to the old design. At the same time, acquire experience and more understanding on the subject of computer graphics.

Problems

Before starting the project, I had to take into account some existing problems that should be dealt with in some way during the execution of the project. Problems such as:

Fixed Point: as the game is from the 2000s, float operations were still very costly and so the entire graphical part of the game was done using variables of the whole type. Believe me, I never want to do a matrix operation using integers, without even being able to think about SSE.
Directx 6: for a decent optimization, it was necessary to upgrade to Directx 9 (the most similar to Directx 6) to have access to more advanced rendering features.
Hard-coding: the entire graphic part of the game was done on its own, without using high-level graphic libraries. The only functions used in the Directx API were DrawPrimitiveUP, Clear and SetTexture. In other words, all the vertex transformation, shading and skinning parts were done "by hand".
Compatibility: as I didn't want to lose compatibility, I decided to choose to use Directx 9 (which supports Windows XP), focusing on the minimum support of Shader Model 2.0 (SM2) and processors with SSE2 technology.

SSE (Streaming SIMD Extensions) is a set of SIMD type instructions designed by Intel. They are additional instructions that can increase performance when the same operations are performed on multiple data entries.

Removing use of already transformed vertices (RHW)

The first thing to be done and one of the key parts of all the work was to remove the use of the transformed vertices. Without this, it would be impossible to use more modern concepts such as vertex buffering, indexing, hardware skinning , etc.

Transformed Vertices means that the game performed all the transformations involved in a rendering process on its own, without any help from a graphic library.

In short, what needed to be done was:

Remove the transformation of the vertices for Projection
Remove the vertex transformation for View Space (Camera)

To remove these two transformations, it was necessary to pass the vertices in World Space to the rendering buffer , and not the transformed ones anymore.

In this way, it was possible to make the transformation by the Directx API itself, using the function SetTransform (D3DTS_View | Projection, &m), which is much more performative than the one then hard-coded by the game.

Render using DrawPrimitive

Another issue present in the rendering of the game, was that it drew all vertices using DrawPrimitiveUP.

The DrawPrimitiveUP function is used when you pass a vertex buffer created and transformed on your own. It is generally used for dynamic objects (which was not our case).

This caused a tremendous cost to the CPU, since many memory operations were carried out (memcpy mainly). The main idea in this part of the project was to start using Vertex Buffers and thus be able to draw everything using the DrawPrimitive function.

To start using Vertex Buffer I had to remove the transformation of Local Space into World Space by the game itself, and also start using the function provided by the Directx API, SetTransform (D3DTS_World, &m).

This Vertex Buffer is built during the loading of the 3D file, thus, we have a buffer that is assembled only once and remains static throughout the execution of the game, avoiding all those memory operations (if you know how much these operations cost, already can imagine the relief that the CPU gave this part of the project).

Process involved during the transformation of the 3D object to 2D rendering on the screen. Source: http://www.shangdixinxi.com/detail-1085554.html

Vertex Indexing

Having all the 3D objects already using Vertex Buffers, we have already taken a lot of weight out of the way, but we can still improve performance.

A 3D object is formed by a list of triangles and these triangles are formed by a list of vertices. At the intersection of two triangles, some vertices are used for both triangles, and what is the problem with this? The problem is that in Vertex Buffer, these vertices that are common between the two triangles are treated as if they were different. Therefore, when the vertices are passed to the GPU, thousands of them will be passed unnecessarily.

To optimize this, in addition to the Vertex Buffer, we must now create an Index Buffer, which is a list that points to the position (index) of the vertex within the Vertex Buffer.

Source: OpenGL Tutorial

To build this Index Buffer, it is necessary to consider the vertex position (XYZ) and also the UV texture coordinates when processing the triangles of that Mesh. When a vertex coincides with another that has been read before, it takes its index and places it in the list of indexes.

Skeletal Animation

One of the most crucial parts of the entire project in terms of performance, is the skinning of Meshes.Skinning can be summarized as the process responsible for the deformation of the 3D object in relation to its skeleton.

The process is summarized in going through all the vertices of that object and multiplying each one of these vertices by the local matrix resulting from the skeleton to which the vertex is linked. As you can imagine, this process on the CPU, with variables of the whole type, matrix operations, and to make matters worse, performed with each frame of the game, is very expensive and one of the weakest points of all rendering.

To optimize skinning, we must pass this process to be performed within the GPU. How can you do it? We use shaders!

Shaders is like a small program used for processing the vertices and pixels of a 3D model, which is executed by the GPU. I used the HLSL (High-Level Shading Language), developed by Microsoft.

Example above of how the Skinning done in HLSL would be. GetSkinMatrix () is the function in charge of getting the local Matrix of the skeleton to which that vertex is linked.

Culling

Culling is the rendering step responsible for “selecting” the objects visible by the camera and determining whether they should be rendered or not. For this, each 3D object in the game must contain a kind of delimiter that represents the useful area of that object. I used bounding sphere for Models (set of Meshes) and bounding box for Meshes.

Comparison between Bounding Sphere, Bounding Box and Quadtree

Having these delimiters, we can perform the culling steps, which will determine whether the object should be rendered or not. For this project, I used Frustum Culling for all 3D objects (if there is no “inside” the camera area, the object is cut) and Quadtree Node Culling for terrain objects (maps).

A Survey of Visibility for Walkthrough Applications — Scientific Figure on ResearchGate. Source: https://www.researchgate.net/figure/Three-types-of-visibility-culling-techniques-1-View-Frustum-Culling-2-back-face_fig1_2440562

Outcomes

With the end of the project, there was an improvement in FPS (frames per second), however, a little discreet on certain occasions. In certain cases, the FPS improved up to 3x over the previous graphics engine.

As this project took a few months to complete, there was no test environment prepared to make the comparison between before and after, so I chose to select some common scenarios and see how many FPS the current graphics engine was reaching.

Upgraded graphics engine rendering 45 monsters

Upgraded graphics engine rendering 300 and 600 characters (body model, head model and items)

The biggest noticeable difference in FPS between the old graphics engine and the new one, occurs when characters are being rendered on the screen. For characters, the Skinning of the head, body and also the equipped items should be considered. As in the old graphics engine Skinning was performed on the CPU, the FPS was much lower than the current one (performed on the GPU).

In addition to the considerable improvement in the game’s FPS , with the new graphics engine it was possible to add several new graphic features, such as:

Dynamic Shadows: With the new graphics engine, it was possible to implement dynamic shadows on the characters, with the minimum requirement of Shader Model 3.0. Before, it was completely impossible to have a feature like this.

For the case of maps, dynamic shadows were not used for visual and performance reasons. To get around this, the Lightning Map technique was used to produce the shadow effect. Image for post

Ocean Effect: This effect was done as an experiment but the result was very nice. It was implemented a refraction system, reflection and some material effects (scrolling).

Intersection of objects: Effect widely used in water shaders and lately in games in the style of Battle Royale, used to represent the safe zone of the game.

Inner Glow: internal glow effect for any 3D model. You can control color, brightness intensity, distance, etc.

Dissolve effect: when a monster dies, instead of it staying on the ground and disappearing from nowhere, there is a specific effect for that.

Conclusions

Although the performance of a graphics engine is quite relative, depending on hardware, enabled features, resolution, game settings etc., I expected a more significant improvement in FPS, mainly due to the time dedicated and complexity of the project as a whole.

In contrast, the new graphics engine allowed the development of several new features that would have been impossible previously, in addition to all the knowledge acquired with the project.

There are still a lot of things that can be optimized in the future and bring even higher performance, such as:

Build a State Manager (a kind of cache of Directx states)
Use a circular buffer as a cache for animation arrays
Grouping frames by type of animations
Refactor some Shaders
Avoid division and multiplication operations by 256.f
Improve Culling with new techniques (Back-Face Culling and Occlusion)

The entire project is available in a public repository on GitHub, licensed under the MIT license.

igorsegallafa / delta3d

Simple rendering engine made for Priston Tale game.

Delta3D

Project of a basic Game Engine that I created for learn 3D stuff. The library was made using Directx9 with Shaders and C++ 17.

License

Licensed under the MIT License.

Features

Support for Pixel Shader 2.0 and 3.0.
Support for Hardware and Software Skinning.
Support for Lightning Map (Self Illumination map).
Support for old devices.
Support for material overlay.
Support for Vertex Color.
Supports up to 128 bones in Skinning.
Support for SMD File Format from Priston Tale game.
Use of SSE2 for floating optimization.
Static Quad Tree for Terrain rendering.
Particle Engine.
Mesh Rendering Sort (transparent meshes renders last).
Distance Fade at Pixel Shader.
Initial implementation of reflection plane.
Dynamic Lightning.
Material Transformation (Scroll).
Material with Animated Texture (sequence of frames).
Camera implementation.
Dynamic Event and Timer implementation.
Frustum Culling.
Value Animation with Easing.
Debug Renderer.
Good performance for scene with a lot of Skinned Meshes and big…

View on GitHub