Greetings, Bishop here with another installment of the "Hacking Obstacles" guides. In today's guide, we will be examining the most basic kind of anti hacking utility, a check bot. Now this is NOT the way that Hackshield works. This is however 1 of the features implemented by the product, and that is why it's a valid topic for this guide. Once again, all following information is simplified. It is far more complicated in the actual way it runs, but the point is not to bore you with all that technical mumbo jumbo, it's to educate you in a simple, fun, accessible manner. On that note, let us begin ^^.
First, let's put our critical thinking skills to the test. What the heck is this article about? What's a check bot? Does it farm gold? Does it run dungeons? Does it check my inventory, or check for item drops? No. A check bot is not something we as the user do not create or run. It is an automated process put in place by a game developer or a third party programmer to run through and check given data points within the game to assure that it has not be altered in any way, hence the name, check bot. Let's break down the processes that a simple check bot will execute.
Primary check: File Sizes.
After you click the executable to start the game, or program that's protected by a check bot, it begins to make its first round. In this step, nothing is written to or read from the files to be checked. The bot simply accesses and reads the file sizes of the files it needs to "protect". If the file sizes match the stock file size, the bot sends a message to the program and allows it to continue executing.
The cool thing about a simple check like this is that the bot will rarely check the file size to an exact byte. This is where we as the hacker have an edge over this aspect of the bot. As long as we keep our modified files within 100-200kb of the stock file size, the bot will usually pass over the file and say "yes, this file is at the proper size", since it's only checking within a range.
Another way that we can fool this part of the bot is to simply include our modifications in an outside file or bit of code that's not part of the stock install.
For our advanced coders out there, another way to bypass this check is to modify either what files the bot is to check, or what it returns. The simplest bypass involves changing where the bot jumps to if it finds an irregularity, to the address of a clean scans outcome. A more time consuming method involves redirecting what files are scanned, and creating proxy files that share the same file size as the stock files.
Difficulty of a bypass *.
Pretty easy right? We start the program, the program signals the bot and freezes, the bot checks file sizes, tells the program to continue (or stop), and the program continues to execute.
Secondary Check: Execution Codes
This is where the bot really starts to get in our way. At fixed or variable intervals, the bot will check a random segment of code, and compare it to a list of values that can be returned by that segment of code, that are expected for that line of code, or that exactly match that line of code. There are many bypasses for this kind of check, but as with anything, as the hacking technology and the modders evolve, so does the preventative technology. I'm going to list 3 versions of this check, and a way to bypass each type of check. But these are by no means the only types.
1. Simple, client executed/stored addresses.
This is the most basic form of an execution code check. The bot has within it a list of addresses to check, and what values are to be located there and/or returned from there. It runs an internal timer, and randomly selects and address to compare. These are my favorite kind of bot check because it's so easy to bypass. You can either kill the internal timer, to make it stop checking your files, or you can delete the database of address so that it can't check anything. Difficulty of bypassing is about *.
2. Server enforced addresses/ timers.
These work the same as the simple bot, but the addresses that it pulls are taken from a server, as well as the tick count. This completely destroys our previous bypass method, since we cannot access the database of values or the timer. But don't fear, we have a way around this too =3. If the file itself isn't enforced by the server we can make some changes that will kill this check. The easiest method is to kill the call to the server to get the values. If no values are loaded, it has nothing to compare and... it will always return an error x.x. Bleh, this just means we have to change 1 more thing. We have to find the line that returns the value of a positive or negative comparison and switch what it returns. This will effectively make it always return a positive comparison, meaning the files match.
If that seems like too much work, you could always hard code the comparison line to return a positive compare value. That should work too. Difficulty of bypassing this **.
3. Fully enforced data, addresses, timers.
This is the most difficult process type to bypass. In this scenario, the bot gathers all of its information from a server. We cannot directly affect the running of the bot, we must be sneakier.
Method 1: Delete the bot. This seems stupid, but in some cases, the game or program doesn't require the check bot to run, since it's only communicating with the client. So we can just remove it, patch any calls that are made to it and there we go. A very advanced program has been defeated XD.
Method 2: Interception. More likely then not, if the time, money and effort was spent to develop this type of check bot, it will not be so easy to kill. So we take a stealthy approach to bypassing the check. We need to make sure that if an outside program is calling to an address that it returns the value that is meant to be there. We can do this by forcing entry points and populating a database of values. This is difficult to do, but it works. Allow me to clarify. Usually when a file wants access to a .dll or an executable, it declares an entry point, and if the address is able to be accessed and the code is not locked and the code contains not directions for how to handle programs that want access to it, it simple reads the data. So what we do is include a little order in the code that tells it "if the program Checkbot.dll wants access to this program, it must enter at address 00x00000 and navigate to its target, as to not interfere with the way it runs." After we make this little declaration we can include in the order of logical operations a jump to a stock file of address database that will always contain the proper values. Difficulty level *****.
Tertiary Check: Holistic Scanning/Higher Operations.
The final level of operations for a check bot is to make sure that files are not being modified as the program is running. This is a simple check and is just as easy to bypass. When the program is started, a log is made of the file sizes and whats in the folder, as well as the programs that are to be run. This helps prevent a few different types of modding.
Post Scan Modding- A method of modifying files to be run after they have been checked for size and validity. Because this check has a point of comparison, it can terminate the program if any changes are made.
To bypass this, use blank-spacing or adjust the file sizes that are held within the primary check log.
Injecting Files- If another file is attempted to be injected or worked into the programs execution, it will terminate the program since that added file was not on the list of accepted programs to be executed.
To bypass, add the program you wish to inject to the accepted programs log.
Redirection of Outstream- This check is a quick check to make sure that the program is not being hooked or having its packets intercepted and manipulated in any way. This aspect of the bot simply monitors the time that it takes for a sending file and a receiving file to communicate. It assumes that if the data being sent takes longer then expected to transfer that it is being changed in some way. This is not widely used due to the large number of false positives that it generates, since it does not account for latency and connection speeds.
To bypass, you need some research to find the amount of time your programs need to run properly, then simply adjust the acceptable latency table to accommodate your value.
The files you need to look in should be contained in the check bots native folder, they are usually hidden. If not it means that the logs are being stored server side and will require other means, such as packet editing, to adjust the values.
And there you have it, the most basic functions of a check bot anti hacking system. Like I said before, this is not how Hackshield works, it is only a feature used by it to help deter hackers and modders, after all, they are all evil scumbags who know nothing and deserve to be punished right? As always, I hope you learned something.
Questions, comments, criticism? You know how to reach me. Until then peace.
~Bishop
First, let's put our critical thinking skills to the test. What the heck is this article about? What's a check bot? Does it farm gold? Does it run dungeons? Does it check my inventory, or check for item drops? No. A check bot is not something we as the user do not create or run. It is an automated process put in place by a game developer or a third party programmer to run through and check given data points within the game to assure that it has not be altered in any way, hence the name, check bot. Let's break down the processes that a simple check bot will execute.
Primary check: File Sizes.
After you click the executable to start the game, or program that's protected by a check bot, it begins to make its first round. In this step, nothing is written to or read from the files to be checked. The bot simply accesses and reads the file sizes of the files it needs to "protect". If the file sizes match the stock file size, the bot sends a message to the program and allows it to continue executing.
The cool thing about a simple check like this is that the bot will rarely check the file size to an exact byte. This is where we as the hacker have an edge over this aspect of the bot. As long as we keep our modified files within 100-200kb of the stock file size, the bot will usually pass over the file and say "yes, this file is at the proper size", since it's only checking within a range.
Another way that we can fool this part of the bot is to simply include our modifications in an outside file or bit of code that's not part of the stock install.
For our advanced coders out there, another way to bypass this check is to modify either what files the bot is to check, or what it returns. The simplest bypass involves changing where the bot jumps to if it finds an irregularity, to the address of a clean scans outcome. A more time consuming method involves redirecting what files are scanned, and creating proxy files that share the same file size as the stock files.
Difficulty of a bypass *.
Pretty easy right? We start the program, the program signals the bot and freezes, the bot checks file sizes, tells the program to continue (or stop), and the program continues to execute.
Secondary Check: Execution Codes
This is where the bot really starts to get in our way. At fixed or variable intervals, the bot will check a random segment of code, and compare it to a list of values that can be returned by that segment of code, that are expected for that line of code, or that exactly match that line of code. There are many bypasses for this kind of check, but as with anything, as the hacking technology and the modders evolve, so does the preventative technology. I'm going to list 3 versions of this check, and a way to bypass each type of check. But these are by no means the only types.
1. Simple, client executed/stored addresses.
This is the most basic form of an execution code check. The bot has within it a list of addresses to check, and what values are to be located there and/or returned from there. It runs an internal timer, and randomly selects and address to compare. These are my favorite kind of bot check because it's so easy to bypass. You can either kill the internal timer, to make it stop checking your files, or you can delete the database of address so that it can't check anything. Difficulty of bypassing is about *.
2. Server enforced addresses/ timers.
These work the same as the simple bot, but the addresses that it pulls are taken from a server, as well as the tick count. This completely destroys our previous bypass method, since we cannot access the database of values or the timer. But don't fear, we have a way around this too =3. If the file itself isn't enforced by the server we can make some changes that will kill this check. The easiest method is to kill the call to the server to get the values. If no values are loaded, it has nothing to compare and... it will always return an error x.x. Bleh, this just means we have to change 1 more thing. We have to find the line that returns the value of a positive or negative comparison and switch what it returns. This will effectively make it always return a positive comparison, meaning the files match.
If that seems like too much work, you could always hard code the comparison line to return a positive compare value. That should work too. Difficulty of bypassing this **.
3. Fully enforced data, addresses, timers.
This is the most difficult process type to bypass. In this scenario, the bot gathers all of its information from a server. We cannot directly affect the running of the bot, we must be sneakier.
Method 1: Delete the bot. This seems stupid, but in some cases, the game or program doesn't require the check bot to run, since it's only communicating with the client. So we can just remove it, patch any calls that are made to it and there we go. A very advanced program has been defeated XD.
Method 2: Interception. More likely then not, if the time, money and effort was spent to develop this type of check bot, it will not be so easy to kill. So we take a stealthy approach to bypassing the check. We need to make sure that if an outside program is calling to an address that it returns the value that is meant to be there. We can do this by forcing entry points and populating a database of values. This is difficult to do, but it works. Allow me to clarify. Usually when a file wants access to a .dll or an executable, it declares an entry point, and if the address is able to be accessed and the code is not locked and the code contains not directions for how to handle programs that want access to it, it simple reads the data. So what we do is include a little order in the code that tells it "if the program Checkbot.dll wants access to this program, it must enter at address 00x00000 and navigate to its target, as to not interfere with the way it runs." After we make this little declaration we can include in the order of logical operations a jump to a stock file of address database that will always contain the proper values. Difficulty level *****.
Tertiary Check: Holistic Scanning/Higher Operations.
The final level of operations for a check bot is to make sure that files are not being modified as the program is running. This is a simple check and is just as easy to bypass. When the program is started, a log is made of the file sizes and whats in the folder, as well as the programs that are to be run. This helps prevent a few different types of modding.
Post Scan Modding- A method of modifying files to be run after they have been checked for size and validity. Because this check has a point of comparison, it can terminate the program if any changes are made.
To bypass this, use blank-spacing or adjust the file sizes that are held within the primary check log.
Injecting Files- If another file is attempted to be injected or worked into the programs execution, it will terminate the program since that added file was not on the list of accepted programs to be executed.
To bypass, add the program you wish to inject to the accepted programs log.
Redirection of Outstream- This check is a quick check to make sure that the program is not being hooked or having its packets intercepted and manipulated in any way. This aspect of the bot simply monitors the time that it takes for a sending file and a receiving file to communicate. It assumes that if the data being sent takes longer then expected to transfer that it is being changed in some way. This is not widely used due to the large number of false positives that it generates, since it does not account for latency and connection speeds.
To bypass, you need some research to find the amount of time your programs need to run properly, then simply adjust the acceptable latency table to accommodate your value.
The files you need to look in should be contained in the check bots native folder, they are usually hidden. If not it means that the logs are being stored server side and will require other means, such as packet editing, to adjust the values.
And there you have it, the most basic functions of a check bot anti hacking system. Like I said before, this is not how Hackshield works, it is only a feature used by it to help deter hackers and modders, after all, they are all evil scumbags who know nothing and deserve to be punished right? As always, I hope you learned something.
Questions, comments, criticism? You know how to reach me. Until then peace.
~Bishop