I Reverse Engineered, CRACKED and CLONED a PAID CHEAT transcript

This is a paid cheat that is being sold for $25 every month for a well-known game. In today's video, I'm going to be reverse engineering it, but not just that. I'm even going to crack it and remove its key system. On top of that, I will also clone this cheat. That means I will make it use my key system instead of the original so I can generate keys for this cheat myself. And if you're someone who wants to learn how cheats are cracked or if you are a software developer of any kind, you need to watch this video as I'm also going to tell you how you can prevent your own software from being cracked and reverse engineered by hackers.

Or if you are a normal gamer who just wants to understand what's behind a cheating software, you should still watch it. Disclaimer, this video is strictly for educational purposes. The only motive of this video is to teach and show you ethical reverse engineering. I do not condone any kind of software cracking or piracy. I have proper permission from the developers of this software to test their security, so I'm not doing anything unethical.

Before we start cracking, we need to understand how license verification actually works inside cheating software, regardless of what game it's for. How does the software know if your key is valid? Why won't it just let you log in with a random string of text? When you enter a key, the cheating software sends a request to a central server. That server runs three quick checks. Does this key exist in our database? Is the subscription still active?

Is it running on the authorized device? If any check fails, the server rejects access. If everything checks out, the server sends back a success order along with your subscription expiration date. Almost every paid cheat uses this exact flow. It sounds foolproof, right? So, how do these cheats still get cracked? It comes down to one fundamental flaw, a trust problem between the client and the server. Think of the server as the boss and the cheating software on your PC as the employee.

The boss issues an order, allow this user to log in or block this user. The software on your PC is simply programmed to follow that order. But here's the flaw. The server has no control over what happens on your local machine. Once the response reaches your computer, the client software is completely at the mercy of whatever memory modifications we make to it. That's where reverse engineering comes in. Here is our plan.

Step one, locate the specific piece of code inside the cheating software that processes the server's order. Step two, use function hooks to intercept and rewrite that code, forcing it to always treat the response as a successful login, no matter what key we enter. So, to locate the code, I needed to reverse engineer the cheat using a well-known reverse engineering software called IDA Pro. It's paid, but if you need a free alternative, you can also use Ghidra.

So, I dragged the executable file of the cheat into IDA. Then, to locate the login code we've been talking about, what I did was go to the imports tab and find the WinHTTP send request function. This function is basically used for sending requests to the server in any Windows application. By cross-referencing this function inside IDA, I was able to locate all the functions that communicate with the cheat software server.

After that, I decompiled all of these functions by pressing F5 in IDA Pro and started reading through them to try and understand how the login code actually works. After reading and understanding all the logic for a few hours, I was finally able to locate the login function. Here's what I found. So, this function right here is inside a class. When we reverse engineer functions of classes, the first NT64 or pointer variable is usually the object of the class.

The second argument was actually our license key, and the third argument takes the address of a string variable. Inside that string, the response from the server will actually get stored, which our cheating software will then follow and make a decision on whether to allow us to log in or not. Next, I'm going to hook this function to dump the successful login response using a library called MinHook, which makes hooking functions straightforward.

But before we do that, if you want to learn reverse engineering and game hacking from start to finish, check out my premium course on Patreon. I put everything I have learned over the last 8 years into structured, step-by-step videos. You'll learn how to reverse engineer, build cheats for modern multiplayer games, and even protect your own games against hackers. Best of all, it's just $25 a month, less than what most people spend each week on junk food that hurts their health.

Invest that money into your skills instead. Join today and start learning. The link is in the description and the pinned comment below. So, I created a new empty DLL project in Visual Studio, set up the MinHook library, and wrote the code to hook the login function we found in IDA. If that sounds a bit too technical, let me explain it in simple terms. Whenever the cheating software tries to run its login code for a license key, my hook intercepts it.

Instead of running the original code, it runs my code instead. From there, I can do whatever I want, like faking the server's response order or redirecting the request to my own server, so keys which I will generate myself work. And by the way, I'm not gatekeeping any of this code from you. All the code I wrote for this project is available on my Discord server and Telegram channel for 100% free. So, you can study and learn from it yourself.

The links for them are in the description of this video. Next, I built my Visual Studio project into a DLL file and got ready to inject it into the cheating software. DLL injection allows our custom code to run inside the target application's process as if it were its own code. To load our DLL, we need an injector. I'm using Xenos, a well-known open-source injector that's perfect for simple tasks like this. So, I injected my DLL using Xenos.

Let's try to log in with any random key, and as you can see, our hook code is correctly working. Whatever key that I'm trying to enter here is being exactly displayed on the console window. Next, what I'm going to do is I'm going to enter a valid paid key, which the developers of this cheat have offered to. The reason for that is because I want to see exactly what order or response the server returns when we successfully log in.

As you can see, when we successfully log in, it returns us this nice JSON response, which contains the order of the server stating that the login was a success along with the expiry date of our key. This response of the server is initially encrypted, so if you tried capturing its network packets and dumping it, you wouldn't have anything useful. But, since I am directly hooking their login function, I am able to dump the decrypted response.

And next, I'll just copy this response of the server and make our hooking code return this response anytime we press login with any given key. So, what will happen is even if we enter an incorrect or random key like 1 2 3 4 or Branchlink or our literal name, the cheating software will still think that its server ordered it to let that key log in successfully. All right, so let's build our DLL again, inject it, and try to log in with any random key like 1 2 3 4, and boom.

We are still able to log in. Let's ensure if the features work or not, so let's hop into a custom game with bots. Here's another disclaimer. I respect the fairness and competitive aspects of multiplayer games. I am not testing these cheats with real players. All the players here are just offline bots. With that said, let's jump into the game. As you can see, the ESP is perfectly drawing, and I'm able to enable all the features there are in the menu.

Enjoy this short gameplay with offline bots. >> Yeah. >> [screaming] >> Oh. >> [groaning] [screaming] >> Yeah. >> [screaming] >> Ah. >> [groaning] >> Ah. >> [screaming] [screaming] >> All right. So, next what I am going to be doing is I'll clone this cheat. So, instead of using its original developers and servers keys, it uses my custom server. I will also make an admin panel so I can generate and manage the keys myself.

To do this job, I simply asked Google Gemini to build an admin panel with a simple key generation and login system for me and Go. Go is a programming language which is primarily used for making web servers and web apps, and it is also the language that I mostly code in all the time. I even used to make cheats in Go. And don't worry, even the admin panel and login system source code will be available to you all for free on my Telegram and Discord server.

So, Gemini coded all the stuff that I told it to do. And here's how the panel looks. We can generate a day, week, or a month key ourselves, but they are kind of useless right now because we haven't programmed our crack to use this server and panel we have made. So, the next thing I did was quickly code a login class using AI again and integrated it inside our hook code. So, what would happen now is when the cheating software tries to log in, instead of it connecting to its original server, it would be redirected to our server.

If the key exists in our server database, it would allow us to log in. If that key is expired or does not exist, it won't let us log in. Let's build and inject our DLL again and try entering a random key like before. As you can see, this time it denies the login. Now, let's try to enter the key that we generated inside our custom admin panel. And as you can see, we are able to log in and use the cracked cheat exactly the same as before.

And this shows how easy it is to crack your cheating software or any software you make if you're a software developer. Now, let's talk about the mistakes the developers of this cheating software made that allowed me to crack and reverse engineer it this fast and how we can make it as difficult as possible for reverse engineers and crackers to break our software. First mistake, they did not virtualize their code. The absolute first mistake they made and one you as a developer must never make is skipping virtualization. virtualize the byte codes of your compiled binary using a custom obfuscation LLVM-based compiler.

What this means is don't just use normal compilers. Use a compiler specifically meant for virtualizing your code by obfuscating your entire binary. Doing this makes the logic of your code extremely confusing if someone is trying to statically reverse engineer it. Doing this alone will throw off tons of beginner to intermediate reverse engineers and script kiddies, so you must always obfuscate and virtualize your code.

Second mistake, not relying on the server after the login is successful. Most software stops communicating with the server once the login is done and the key is verified. You must implement a heartbeat system using web sockets that periodically pings the server. Try to offload as much logic as you can to your server. Whatever can be done on the server, do it there instead of letting the client handle it. Third point, encrypting network traffic.

This cheat actually did a really good job of encrypting its network packets and your software must do that as well. Do not pass sensitive requests in plain text. Always make sure to encrypt your network traffic with an encryption or obfuscation system like AES, which is one of the most secure encryption standards out there. Fourth mistake, static server responses. Make sure your server responses are always unique each time.

This was the biggest flaw here. This software returns the exact same response format every time. You should use a nonce to randomize responses so that even if someone dumps your successful login response and tries to replay it, your software will still deny access. Fifth point, low-level anti-tamper checks. This one is a bit more advanced and requires knowledge about low-level code, debuggers, and how injectors work internally.

You should add anti-debugging checks. So, if someone tries to debug your code, your app doesn't run. Add checks for injected DLLs. If any unrecognized DLL appears in your program's memory mapping, immediately block execution. Another thing you must do is check for hooks. You can detect hooks by generating a hash of the .text segment of your binary's code, the memory segment where all machine instructions reside, which remains static unless you update your code.

When hooking libraries hook a function, they modify a few bytes to redirect execution to their custom code. To detect this, hash the .text segment and compare it with an expected hash sent securely from your server. If you do all of these things, it's enough to throw off 99% of crackers. Most crackers aren't high-level reverse engineers. They rely on common automated techniques, and these defenses will stop them in their tracks.

However, if someone is highly experienced and truly determined, they can still crack your software given enough time. But, most pro reverse engineers simply won't be interested in cracking your software unless you have serious rival, in which case your best move is taking legal action against them. And that's it for today's video. Join my premium course to learn reverse engineering and ethical game hacking yourself. Watch the video on your left to learn how to make your first cheat or the video on your right to understand how kernel anti-cheats are bypassed.